Getting over "Task Obsession"

One of the things that I talked a lot about in some of my previous posts about how we run our agile process is tasks.  They have become a very central part of our process, and as such, have become our obsession.  You see, when doing estimation it is very important to break things down into manageable tasks, otherwise you end up with riskier (and less accurate) estimates.  It's well documented that developers are better at estimating smaller tasks than larger ones.  Thus, we break everything into nice small manageable units of work.  We then have our whiteboard full of each and every task that's necessary for building out the features for the current iteration.  Throughout the week we can look at the whiteboard and see all the remaining tasks.  When we finish one task we go to the board and find another.  By the end of the week we aim to get all the task cards to go green since that signifies the completion of all the work.

Not quite.  Unfortunately, our iterations aren't about getting our task cards to go green.  They're about working software.  By following our tasks we get a large portion of the way to our goal, however, it's my suspicion that they prevent us from getting as far as we need to.

You see, while task cards can help guide you along your way, they can also blind you.  Rather than deciding what the most important thing for you to do next is by thinking, you instead rely on your task cards.  Instead of seeing with your own eyes the software work, you instead rely on your task cards.  Rather than thinking about how best to design something, you instead rely on your task cards. 

Don't let your task cards control you.  If you need to use them as a guide, and use them as a barometer for where you are in the iteration, so be it.  However, do not obsess.  Do not live vicariously through a little white task card.  Instead think about what your building.  Think about what the software needs to do.  Think about the most important things to complete.  Think about your software, not your mother f'n task cards.

 

Technorati tags: , , ,

# re: Getting over "Task Obsession"

Tuesday, October 24, 2006 9:45 AM by Dave Nicolette    
What you describe is pretty normal. Often, it indicates people are trying to be too detailed about their estimates. All you really need to get going is a gut feel for the size of the work, maybe in terms or story points or in terms of ideal time. Estimates are not promises. If a story "feels" too big to complete in a couple of days, then it's time to think about decomposition. But I think that's about as far as we should take decomposition.

A secondary problem often comes up when this happens: People decompose the stories into finely-grained "tasks" that correspond with specific technical activities. At that level of detail, you lose the sense of how the piece of work fits into the bigger picture of the story as a whole. That may be how your team has been losing sight of the goal of building working software. You might consider trying to resist the temptation to identify every little bit of work that goes into completing a story. Most of those little tasks will fall into place anyway.

Another secondary problem that can occur is that the small errors in estimation that everyone makes will add up. The more little pieces you estimate separately, the more minor errors will accumulate. There's a point of diminishing returns in trying to be "accurate" with estimates. After that point, the harder you try to be accurate, the worse the estimate becomes. That's another reason to keep agile estimation at a general level only.

There's a cool game that helps team with this issue, called Planning Poker. It's described in Mike Cohn's book, Agile Estimating and Planning.

Post a Comment

 
 
Prove you're not a spammer: 
2 + 3 =