
Introduction
One of the killers on software development projects is Work-In-Progress. We have learned from the Lean experts and from the teachings on the Toyota Production System that too much work-in-progress is a liability. Just yesterday I was asked to spot the problem with a sister company's task board. Sure enough one developer had 5 or 6 "in-progress" tasks on the task board. It took me a split second to notice.
Productivity
The problem with this situation is that as a developer if you're working on more than two tasks, simultaneously your productivity takes a dive. Additionally you're going to end up with many unfinished tasks that never get completed. This is a classic problem in Waterfall where tasks have half-lives are in the order of man months. The more tasks in play at any given time, the more tasks that never get finished.
Lean
The most interesting quote from the Lean conference shared by Sterling Mortensen that really hit home for me:
"Stop Starting, Start Finishing" could not be more apt.
I believe this goes hand in hand with the definition of DONE that all the Agile thought leaders can't seem to stress enough. There is no more important aspect of Agile in my opinion. The definition of DONE defines up-front exactly what is required to TOTALLY complete a task. If you're minimizing work-in-progress and you complete this work in accordance with the popular definition of DONE, you're going to drastically improve your overall cycle time. i.e. concept to cash. The reason is that unfinished tasks seem to linger on forever, never get finished and continue to drain the teams resources.
Work-In_Progress
The other interesting quote which somewhat relates to the minimize work-in-progress theme:
“If you don’t know how to get the story out of the iteration – don’t let it in”
Living by this motto, ensures that you don't have queues of unfinished work that have to roll over from sprint to sprint. Everything that goes in to the Sprint must get finished during that Sprint. This takes careful planning, so as not to over burden the team with work they know they can't finish. It's very similar to the JIT production systems that minimize inventory queues, and optimize throughput thereby ensuring optimum team efficiency and reduced cycle time.
So, plan to finish one story before starting another and always plan on finishing a story in the same Sprint that you start it in. What this means is your stories can't be epics!
Comments
A Question about Stories
May 22, 2009 by Mark Stringer (not verified), 37 weeks 4 days ago
Comment id: 2602
Dear Jack,
Thank you for a very interesting post. I just have a question about your principle:
“If you don’t know how to get the story out of the iteration – don’t let it in”
Surely in a large number of cases, what's complicated about a story isn't obvious when it starts being worked on - and what needs to be done to execute it and get it finished isn't obvious either. Aren't you creeping back to a "Would it be better if we got everything right in the first place," kind of attitude?
Regards,
Mark.
http://www.agile-lab.co.uk
Question about stories
May 23, 2009 by jackMilunsky, 37 weeks 3 days ago
Comment id: 2603
Hi Mark
Thanks for your question ... an excellent one I might add and I am not sure I can even answer this effectively or not.
You're 100% right that in many scenarios you just don't know. So what you have to do is for those stories that you know are far reaching and unknown, plan a spike. This will allow you to do the research in a manner that produces enough knowledge so that it is obvious what's required. The comeback on this is well aren't we supposed to produce potentially shippable code after every Sprint. Again you'd be right but sometimes you just don't have options.
I think the point here is to work really really hard at minimizing the work-in-progress and then whatever is in progress to totally complete it, so that it's DONE DONE. That way you don't have dangling unfinished work littering your codebase, thereby increasing technical debt.
Hope this helps.
Thanks for your thanks!
Jack
Question about stories
August 20, 2009 by Anonymous (not verified), 24 weeks 5 days ago
Comment id: 2989
Surely in a large number of cases, what's complicated about a story isn't obvious when it starts being worked on - and what needs to be done to execute it and get it finished isn't obvious either. Aren't you creeping back to a "Would it be better if we got everything right in the first place," kind of attitude?
Decoration blog
Post new comment