When ToDo, In-Progress, and Done Aren’t Good Enough

January 4, 2010

On a task board there are two places that we can capture additional detail regarding the tasks we are working on:

  1. In the tasks and stories
  2. In the categories that we use to organize the tasks and stories

The common starting point for categories on a task board are: ToDo, In-Progress, and Done. Obviously this works for the great majority of cases because the categories are so vague. It’s the starting point for most teams that are using a task board for the first time. However it isn’t long before we discover that some things don’t fit this model well. For instance many tasks commonly take place in multiple ordered steps. Look around you, it happens all the time. Trying to capture tasks that have more than three steps to them on a task board starts to feel awkward. People start to ask if there should be another column on the board. The answer is probably yes.

You see, if you resist and decide not to track additional legitimate state for a task, then in essence you are keeping that information invisible. State is important. Hidden state violates the principle of transparency that we are trying to promote on agile projects. So you need to find a way to represent it on your board. There are lots of mechanisms to reflect additional state on a task board:

  1. Add new swim lanes
  2. Use color on the task/story cards
  3. Use labels or stickies on the task/story cards
  4. Additional text on the card
  5. Additional task cards

All of these techniques will provide additional state information to your task board. A common symptom of a board that isn’t conveying enough state information is when the stories tend to get “stuck” under the In-Progress category for long periods of time. Now there are lots of reasons this can happen, but one reason the task/story may not be moving is because you don’t have an adequate way to express the state of the progress being made on the work. The developer may be making lots of progress, but none of it is reflected in the task board. When this happens, you need to consider that perhaps the board is not displaying information that would make the progress visible.

I was reminded of this today when looking at a team’s task board. Stuff was sitting in the In-Progress” category for too long. However I knew that the team was making great progress. So they weren’t lazy. And they were keeping the board up to date. So what was the problem? There wasn’t enough information on the board to properly reflect the work that the team was doing. As a result, there were impediments that we couldn’t even recognize because we didn’t have any way of showing progress on the hidden states. Being blocked on “In-Progress” is not very informative. Being blocked on the “certification request” is much more explicit.

So the next time that the team seems like they are stalled with their task board, consider changing the way the information is presented. Adding a few new categories could help the team identify some of the hidden issues that are currently blocking them.


What’s a Waterfall?

December 12, 2007

As an Agile coach and a trainer I often compare Agile methods to “Waterfall”. Waterfall is a bad thing. We all do it. When we are assessing a team, sometimes I hear people say in a desultory tone, “They’re just doing mini-waterfalls.” Typically when I think of waterfall processes I think of a project that is organized as follows:

Analysis ->Design->Implementation->Test->Release

Or something close to this (you may use different terms). Basically, we do this, then this, then this… and repeat. Typically this method is criticized as creating too much specialization, not enough collaboration, too many hand-offs, and so on. So far, none of this should be  a surprise to anybody. I can slap this sort of project together in MS Project in my sleep.

Now, let’s take a look at our Scrum task board. Here we see something similar to the following:

ToDo, Test Complete, In Progress, In review, Done

Interesting. In a typical case, can we do any of these steps out of order? No.  Can we skip steps? No. Hmmm…let me show you those terms one more time:

ToDo->Test Complete->In Progress->In review->Done

Oh, now that’s kind of interesting. It seems that the Agile process that we are using to track our tasks looks remarkably similar to the Waterfall process. But that can’t be right! Let’s put them side by side and see if we can find a difference:

AGILE:                 ToDo->Test Complete->In Progress->In review->Done

WATERFALL:    Analysis ->Design->Implementation->Test->Release

Oh nuts! Now I’ve really done it. Perhaps its a matter of scale. Perhaps its a matter of the order of magnitude difference in the activities. Or…perhaps using the “Waterfall process” is a straw man that we shouldn’t really be using when we talk about the benefits of Agile. Perhaps the greatest difference between how things are done on an Agile project, and whatever folks have done in the past is not in the order that the tasks are completed in. You can rename the tasks, reorder them all you want. But you still end up with the same thing. Call it something different, “a mini Waterfall.” If it makes you feel better, great. But my argument is that this is not the key difference between Agile and other methods. The difference lies someplace else, not in the ordering of the tasks – because, if we just compare the ordering of the tasks, guess what? Agile and Waterfall look the same.

Maybe I’ll sleep on this tonight and look back on this tomorrow and regret it. After all, I’m a good little ‘Agilista’ and I don’t want somebody to stamp my meal card “No desert”.  Perhaps I’ll go back on my medication tomorrow and realize that this was all a hallucination. But somehow I doubt it. If we are looking to explain to others how doing an Agile project is different than others, perhaps we should avoid this comparison and focus on other differences.