Is Improvement really Continuous?

September 4, 2014

DT-09-final-infinity

 

 

 

 

 

 

I don’t want to get on a rant here, but…In the Agile community and perhaps in the IT community in general there is a tendency to use the term “Continuous Improvement” to describe some sort of mythical state where teams are constantly evolving toward some state of perfection. At least that’s what I think of when I hear the term. Now I don’t know about you, but I don’t think I’ve ever seen such a creature in the wild (or even anything close to it). Furthermore, I’m concerned that using such terminology sets an unrealistic expectation for performance with our customers and stakeholders.

As an example, I’ll use myself. Right now, despite a host of good intentions on my part, I am not continuously improving. I’m typing – my spelling and grammar are showing no discernible sign of improvement (as I’m quite sure you, dear reader, are all too painfully aware of). Honestly, I’m just not improving right now. In fact, I haven’t done anything to improve my blog writing since the last time I wrote one a week ago…a month ago…6 months ago…

“But Tom don’t be so hard on yourself!” You say, “Just by writing more you are improving your writing skill and the content of the blog.” To this my answer would be, “So just writing more code is improving too?” We all know the answer to that question. So no, the only thing writing does by itself, is make the number of words on the page grow.

In fact, I have a confession to make. Nothing I plan to do in the next 24 hours has anything with improvement. Not even:

  • Attending meetings (generally the opposite of improvement)
  • Writing status reports (ditto)
  • Cleaning the house (status quo – just fighting entropy is not improvement)
  • Commuting (status quo)
  • Watching TV (gently sliding toward entropic oblivion)
  • Sleeping (mandatory, but not improvement, at best it’s re-establishing the status quo)

You see, true improvement is really hard work, therefore I don’t do it very often. I certainly have never been able to do it “continuously”. Hah! What a ridiculous notion that is! Nobody can improve continuously. We all need to take a break. Taking a break is actually necessary in order to improve! So the very term “continuous improvement” is at best misleading and at worst an idiotic notion. It can’t be done! Combining the terms continuous and improvement is like the old joke about the term military intelligence – it just doesn’t exist!

Up to this point I’ve just been ranting about continuous improvement, but in the Agile community we use the “continuous” word everywhere. There’s continuous integration, continuous delivery, and I’m sure there are a few more I haven’t even thought of. Take any one of those continuous activities and look at it closely enough, and guess what? Not much is happening. I’m willing to bet that your continuous integration server isn’t constantly running builds all the time (at least I hope not). I’m sure the average integration server spends a lot of time just waiting for the next build request. I hope by now it is pretty apparent that very few things are really continuous. I think we need a better term to describe these processes. I would propose: Periodic, Frequent, Event-driven or my personal favorite – on demand.

I know, I really do get it – continuous sounds just better. Continuous has an aspirational sort of quality to it which you can’t help but admire. I think that it’s just a little disingenuous to use that term for things that may not even take place for an hour or even a day at a time. If improvement is really continuous in nature, I want to see evidence of improvement taking place as I’m watching, when my back is turned, on weekends, and perhaps even when visiting the bathroom. Is that too high a bar to set? I don’t think so. I make that demand of my lowly alarm clock. I’m not saying improvement doesn’t take place. It happens – for some of us it happens pretty frequently. For others, it happens on demand at the end of the sprint.

Improvement may be a never-ending quest, but it is rarely, if ever, continuous.

Advertisements

Culture Eats Impediments Too

March 3, 2014

hippo

I stumbled across Pawel Brodzinski’s blog on Software Project management. In “Why Kaizen Boards (Typically) Don’t Work” he talks about the importance of having the right culture that will support using and taking full advantage of the tools (Agile, Lean or otherwise) that people try to introduce to organizations. He notes that when the culture doesn’t permit experimentation without permission, introducing any kind of continuous improvement effort is almost always doomed to fail. He makes a good point. I’ve seen this pattern myself and it applies just as much to managing impediments as it does for any other kind of improvement.

Some signs you may have a problem introducing a change:

  • Taking action requires getting permission (this is straight from Pawel)
  • Action can’t be taken because projects are too important to risk
  • Only certain people can take action

I have a great example of this happening recently: The group I was with raised an impediment. I had a nifty new impediment display that I wanted to try out (impediments displayed on a big monitor that everyone in the company could see). I sat down to add the impediment to the list, and then I had to pause…because the impediment called out something that might upset some folks. It might REALLY upset some people. I ended up not displaying that impediment. Why not? Was I just a chump? Was I too scared to make an impediment visible? Maybe…

Or perhaps I understood the culture well enough to know that certain things were acceptable to display as impediments, and others weren’t. That’s just the way it works at some places.

The take home message for anyone who is interested in initiating this kind of change: Make sure that you have the buy-in from your organization. Talk about these sorts of examples and discuss how you might deal with them. Use the feedback from that dialog to inform what changes you try to make.

 


Punctuated Disequilibrium

August 22, 2011

I’ve heard people talk about the gradual gains that agile teams make over time as they engage with continuous improvement, but I’m here to tell you that isn’t what I see in the real world. I guess the expectation (perhaps my own included) is that when teams start to improve they will make many small changes over time and reap corresponding gains in performance. You know, a little change here, a little gain there. I guess I envision it looking a little like this:

However, I see something different. What I’m witnessing with the teams that I work with appears nothing like that. Instead the teams seem go for long periods with no evident change in performance or productivity. They just seem to trundle right along and then BANG! You see a dramatic improvement. It sort of looks like this:

The team is trying out different things the whole time. They’re failing at some things and succeeding at others. They are continuously playing with the chemistry set we call Agile Development. From the outside you don’t see much happening. Sometimes for long stretches of time – we’re talking years here. The point is that my experience is that often, it’s a combination of many things that leads to significant performance gains by a team. Finding that combination of what works can take a while. But when it does happen, it is reflected in a rather dramatic improvement in performance. It’s not a slow gradual change.

Of course there is a flip side to this change. Here’s another example:

Some teams that I’ve worked with have made great gains and then “jumped off the cliff.” What goes up can come down. I call this “Tom’s First Law of Team Performance”. Just as there is sudden improvement, there can be an equally sudden decrease in performance. Team’s can make a change that kills performance just as easily as they make a change that improves it. I’ve seen it work both ways. Sometimes it is change outside the team, within the corporate culture at large that causes these radical swings in performance. Software teams work in a complex ecosystem. When change happens, I think it tends to either be suppressed by the system or, when the conditions are just right, lead to dramatic changes in performance.


Exploring The Project Jungle

January 14, 2010

Grab your pith helmet and join me for a little journey. Shhhh! Be vawy, vawy quiiiet, we’re hunting for projects! We move through the jungle with exaggerated stealth, placing each booted foot with care. We stop before a bank of thick fronds and I gently part them. On the other side lurks a horrifying creature: a man sitting alone at his desk staring intently at a monitor. I stifle a scream.

Our programmer (Mr. Livingstone I presume?) is obviously engrossed in something interesting. Every once in a while he starts typing furiously, keys clattering at an astounding rate – and then he stops. This pattern repeats itself over and over. You look around at his environment: his desk is clean, his walls have a few quick reference cards taped to them. Maybe a picture of the kids. Just your standard programmer – usually found in isolation, seldom socializing, and rarely breeding.

But wait! If we look a little closer some interesting details are revealed: it turns out that he has an IM client open on the monitor. He’s actually collaborating with someone! Furthermore there is a row of telltale lights in his task bar that keep him informed of the status of all of his continuous integration builds. Wow! This guy has a lot more going on than is revealed at first blush. I wonder what else is going on here…This is obviously a workspace that is oriented around the electronic screen. That’s natural enough in the software business. What about the wall space, why isn’t that space being used more?

I love sneaking about the office and looking at what other teams are doing.  You can find the most amazing things. Teams using different techniques, alternate presentation of the same material, etc. There is a rich supply of ideas lurking in those other teams. Go ahead, steal one of their trash cans and rifle through it. What are they doing that you might benefit from trying out? I’m not talking about espionage here…OK, maybe I am. The point is, there are a lot of things we can learn from the other teams that we work with.

What can be a lot of fun is to take others along on the hunt with you. Get the team together as a group and act as their guide. Don’t forget to get them hats too.  Sneak up on other teams and observe where they live and how they behave. When I do this, we debrief together after observing each group. The debrief is an opportunity to ask some great questions:

  1. What did you see?
  2. What did you hear?
  3. How is it different from where we work?
  4. What do you like/dislike?
  5. What can we steal?

Each of these questions can serve to bring up some great conversations about how you work together as a team. Then you can follow up by returning to your own work area at the end. Don’t just pile back into the office though – take a moment to observe your own work area. What does it say about you as a team? Usually at this point the team is primed to re-evaluate the way they work, the way their area is organized, etc.

So have a little fun and try out becoming a Project Anthropologist. It’s a fun and gentle way to open up the conversation regarding how the team works and how it is organized. And you get to spy on your co-workers. What could be better?


Standard Work for Personal Improvement

August 16, 2009

checklistStandard work is a notion from the lean manufacturing world that refers to having some sort of pre-defined standard way of doing things for a given activity or process. Actually, in the lean lexicon there is an awful lot related to standard work. Perhaps the most concise definition I’ve seen is this:

“Standardized Work is an agreed upon set of work procedures that establish the best method and sequences for each process. It defines the interaction of people using processes to produce a product. It is centered around human movements, it outlines efficient, safe work methods and helps eliminatemuda/waste.”

– cited from The no-nonsense guide to Standard Work

It can be as simple as simply documenting the work that is already done. It can also be used as part of a continuous improvement effort (you have to have a standard process so that you can measure the impact of changes). In much of the literature that I have read, the typical examples of standard work are taken from processes from the floor of a manufacturing plant. It seems pretty easy to define all the steps in a process when all you are doing is processing widgets. Compare that sort of work to the kind of work that is typically done by your average knowledge worker. Naively, they seem as though the two contexts are worlds apart.

For example a worker in a factory may do the same thing over and over again all day long. On the other hand, a knowledge worker never does the same thing twice – and certainly never the same way. Consider also that a typical factory worker works on a fairly rigid schedule that does not admit to many interruptions. The knowledge worker by comparison is sometimes referred to as “interrupt driven”, often suffering a non-stop stream of interruptions and changes in focus (depending on your situation of course). So how is it that we can apply the same sort of techniques for standard work to the knowledge worker that we would apply to the factory worker?

There was an interesting article over on InfoQ, Lean ‘Standard Work’ Applied to Software Development, that outlined some of the issues in trying to understand what it really means to apply the concept of standard work to knowledge work (or more specifically to software development). A few things become clear from this discussion:

  1. There are different ways or levels of understanding how standard work can be applied to knowledge work. For example: scheduling, task completion, process performance, coding standards, etc.
  2. Some would even assert (I believe incorrectly) that standard work does not exist in Agile software development.

I might even argue that in order to really understand how standard work can be applied to software development we have to take it down to the individual level. The question becomes: Where can each of us find standard work in our everyday lives? Here are some ideas:

  1. The daily schedule – imagine standardizing your daily calendar in outlook. I saw an amazing version of this in a presentation done at the LEI lean conference by the folks at Group Health.
  2. Meeting management – a well run meeting can be run according to a standardized structure. In fact that’s what a lot of management books are all about.
  3. Quality checklists/templates – what are the criteria that we use to assess the quality of the work we have done?
  4. To do lists/chores – what are the things I need to accomplish each day?

As you can see there are an awful lot of opportunities for standardization in a person’s day. Right now I’m playing with these ideas. This standard work stuff seems to border on time management (Stephen Covey, David Allen) as well as with Lean, and other process management methodologies. Exploring this sort of thing, especially at the individual level is a form of self-experimentation that can be very valuable. It can help reveal the principles behind these concepts in ways that our deeply meaningful to us in personal ways. It is through discovering that deeper meaning behind many of these principles that makes each of us better at bringing these concepts to bear in a work context. So I’m going to continue to play with this stuff, and if it interests you I would encourage you to do the same thing. You might find a lot of standard work lurking in your life.


Continuous Improvement & Risk

July 1, 2009

I witnessed an interesting pattern today while running Boris Gloger’s “The Ball Game” exercise with a team. The basic idea is to iterate a team activity, stopping to make improvements each iteration. The idea is to practice and measure the impact of continuous improvement on team performance of a task. In general, the team did as you might expect: the first iteration things were pretty rough and their performance wasn’t very good. In subsequent iterations, their performance continued to steadily improve until they were nearly perfect at peforming the task.

Here is what I think I saw happening: with each iteration the group became more stable. They eliminated variation until they reached a plateau in their performance. They found stability, but they also reached a plateau where they were not making significant additional gains with each iteration. It felt very much like they were playing it safe. They didn’t want to do anyting to risk their “score” each iteration of the game.

Now I knew something that they didn’t – as facilitator I knew about other rather creative ways of configuring the group that would have given them a quantum leap in performance. There was an opportunity to take a chance and rethink the problem and make some stunning gains in performance – but at a very real risk to their short term performance. What I saw was a group that was tweaking the small stuff and missing the opportunity to change the big things that would make dramatic differences performance. It felt like there were competing pressures that were impeding the teams ability to see opportunities for performance improvements. Now of course this was just an exercise, so there really was no risk if they didn’t perform well – so any pressure they were putting on themselves was basically self imposed. And that may have been enough to blind them from seeing the opportunity for greater change.

How often do we do this on our own teams? We make improvements that fine tune the status-quo until it feels reasonably stable – and then we stop. I know it happens to me. Add a little pressure from management, and I very quickly can’t discern the forest from the trees any longer. There may be opportunities for change that offer dramatic improvements, but I will very likely not even consider them if it means potentially risking my team’s established performance.

I think this is all the more reason to focus on making the team feel “safe”. As managers we sometimes need to protect our teams external pressures so that they can keep relaxed and flexible – open minded enough to see all the possible alternatives.

Or I could be nuts. You decide.


Managing Impediments

March 4, 2009

 

ruler

 

 

 

 

As many have already pointed out, identifying, tracking, and resolving impediments are some of the most important things you can do for your team. The question that naturally arises is, “How?” In my experience both observing and working with teams, often impediments are jotted down during the daily stand up on a post-it note or listed on a whiteboard. There is nothing wrong with those techniques if the impediments are addressed in a timely fashion. However, if we really have our act together we can do a lot better than these relatively crude techniques. Impediments play an important role throughout the entire scrum process and I think this is under appreciated by many practitioners. 

I would break down impediment management into the following areas: Process, Tracking, Scaling, and Roles. In each case we can explore how impediments are managed and examine how this benefits the team.

In most texts that describe how scrum works impediments are given pretty short shrift. Impements are described as being captured during the daily standup and then they are to be resolved by the scrum master. There really isn’t much additional attention given to the topic: identify the problem and then magically resolve it. End of story. However in practice, impediments play a much more pervasive role in the development lifecycle and they need to be managed accordingly at different stages in the process.

It turns out that impediments have different lifespans. Some impediments are very transitory and are dealt with or resolve themselves very rapidly. Other impediments, especially those that are related to the culture of an organization are much more persistent and can require substancial time and effort to resolve. It would be convenient if impediments were all resolved the same day that they were found – and that is certainly the goal to strive for (as suggested by Jeff Sutherland). However, my experience is that in practice impediments can take some time to resolve, no matter how dedicated the scrum master may be. This is especially the case in organizations that are just adopting Agile.

Process

So given that impediments are in different stages of resolution (and different severities) it makes sense that we track them throughout the scrum sprint cycle. Let’s start in the middle where we are most accustomed to finding impediments – the daily standup.

Every day the team is required to get together for 15 minutes and answer three key questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. What is holding you up?

Of course it is the third question that leads us to the impediments. We need to make a note of these impediments as the team does the standup. Then after the standup we can get together with the affected parties and gather more details about the impediment. Hopefully your team will provide you with impediments. The standup is the primary source of new impediments in the process. However this is just the beginning as far as tracking is concerned.

So we go through our sprint, and we get to our review with the product owner. We can demonstrate our small unit of “potentially shippable product” and gather their feedback. However there is an additional opportunity in this meeting to share the impediments that the team overcame in delivering that product (or realistically, in perhaps not delivering that product). Sometimes the team has to jump through some pretty amazing flaming hoops to deliver the product – the product owner might want to know about these things. Why? First, it will help to set their expectations in the future if they understand the kinds of challenges that the team faces. Second, the product owner is an important ally of the team and may be able to help the team out with resolving those impediments. We should take advantage of that potential. Being transparent means sharing all of the struggles that the team encountered in delivering the product.

Next we go into the retrospective as a team and review our own performance over the previous sprint. What went well, what needs improvement, kudos, and so forth. This is an opportunity to review the list of impediments and the progress that the team made in resolving those impediments – I see this as an important measure of the teams ability to overcome challenges. The retrospective is an ideal place to check in on this performance. Are there impediments that are consistently not getting addressed? Why not? What can the team do about it? We can use the lessons learned from the impediments that we encountered in this sprint to modify the way we act in the next sprint.

So we wrap up the sprint and we take the weekend off. We come back on Monday ready and fired up to start a new sprint and we go into the sprint planning meeting. Impediments can play an important role in the planning meeting too. When the team is reviewing the stories in the product backlog, they will find impediments that prevent a story from being worked on in the current sprint (often the impediment is that the story is not well understood yet). These impediments are important for the team to track as well. The other opportunity we have in the planning meeting is to put in place plans for actions that we believe will help us address or avoid impediments in the upcoming sprint. Sometimes simply avoiding impediments is just as important as recording them after they have hit.

So as you can see, impediment tracking really is pervasive throughout all of the scrum lifecycle. There is real value in making sure that impediments are considered along every step of the process, not just the daily standup.