"Stop Starting and Start Finishing" - A successful Lean philosophy

May 15, 2009 by Jack Milunsky

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!

Permalink