Getting Done the Lean Way

Something I’ve been thinking about lately, as I’ve been going through reams of paper on lean, kanban, kaizen and Toyota Production system concepts, is how the definition of done differs from that we are used to in Scrum.

In Scrum, the product owner gets with the rest of the team and the come up with a definition of done for the particular project.  What done means is essentially the responsibility of the product owner, but its an exercise done by the entire team.  What done means on one project might not be the same definition of done for another project you work on.  This is an allowance in Scrum.

In lean, I think I’ve decided that all lean projects have the same definition of done.  Lean is about value, flow and waste elimination, in that order.  With value being the primary focus of any lean organization, the word done must correlates to value.  Thus done can be defined partially as ROI if you want to look at it that way, but something is done the moment value is achieved.  This is the reason why waste elimination is such an important part of lean concepts: its a way to reduce the time it takes to get something done, thus reducing time it takes to provide value.

Naturally a product evolves over time, but in many cases, there is an immense amount of value in getting a product out to market, even though its not your final vision.  This is true for every product I can think of.  You think Toyota waited to put out the Camry until they thought it was perfect?  Of course not.  However, the value in getting the car to market given the state of everything, made sense and provided a lot of value.  We view things in software a bit differently, especially in non-Agile circles, but the same holds true.  Lean software’s doneness is the moment it can provide value to its customers/owners.

As the people who write software, we might not always be aware of the value a product provides to its company, thus we might not understand why certain feature sets are created before others and it might not make sense to us.  I’ve never been an end consumer of any software I’ve been a part of writing in 15 years.  HR, PR, marketing, accounting, etc.  These are the people who are most likely to understand the value to its highest degree.  Its our job to do work, evaluate cycles, make changes to eliminate waste and continuously improve our processes and reduce the time it takes to provide value.

This entry was posted in Agile, Alt.Net, Lean, Scrum. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Getting Done the Lean Way

  1. Jim Cooper says:


    “Most programmers are perfectionists”

    Ooooo, I wish I lived in that world! :-)

  2. @Kevin, its not just the idea of good enough. Many times it is the cost of delay because you don’t have a market presence. Reducing turnaround time in order to increase flow and provide value sooner is a major part of the whole game. Just think if Zune would have beat iPod to the market. Also, software that is drawn out over a year long release cycle versus a 3 month release cycle just has that much longer of a feedback loop and greater chance to experience failures, and more of them.

  3. This line of your post really hits home for me: “Naturally a product evolves over time, but in many cases, there is an immense amount of value in getting a product out to market, even though its not your final vision.”

    In my experience one of the hardest things for programmers is the trade-off between “Good Enough” (as in the Pragmatic Programmer) and “Perfect.” Most programmers are perfectionists, so the concept of “Good Enough” just doesn’t sit well with them. And the idea of value is even more foreign.

Leave a Reply