The Lean Machine, part 1

This has been two very intense days full with Lean. First Mary Poppendieck held a Talk for NNUG about Waste and Thrashing then the day after I was lucky enough to join a whole day with her and Tom Poppendieck about “Leading Lean Software Development”. Their website is here

Lean Thinking

The idea for Lean comes originally from Toyota Motor Company where Taichii Ohno implemented a revised version of the production process that was used at Ford which was called “Toyota Production System” or “Just In Time”. One of the main differences was that the Just In Time process was much more flexible then the way Ford was producing cars. Just In Time evolved more and more into what we now call Lean.

The actual name Lean comes from a book called "The Machine That Changed The World" written my James Womack where he introduced the term “Lean Manufacturing”. Toyota remains the leading example used when people speak about Lean.

Lean Software Development

When we talk about Lean Software Development we are taking the Lean Manufacturing process and project that upon software development where most of the principles are a one to one match.

Eliminating Waste

We all know that we should eliminate waste as much as possible, but Waste in software development can be quite hidden if you don’t know what to look for. Mary showed us the definitions for Waste: “Anything that depletes resources of time, effort, space, or money without adding customer value”. Let’s take a more specific look at ‘the 7 Wastes of Software Development”:

- Extra Features
- Failure Demand
- Handovers
- Work In Process
- Task Switching
- Delays
- Defects

Extra Features

Research showed us that about 64% of features in typical systems are rarely to never used. Now if you think about the work needed to create these feature, and the work that is needed to maintain these features, and then think about the fact that they are never used. Would it not be much better if we would invest that huge effort in creating something that is actually useful and adds value to the business?

Failure Demand

This is demand that is placed on your resources directly caused because of your failures. Think about support calls, fixing problems in the system, but also extra courses to make the system understandable. These are all forms of waste that should be eliminated.

Handovers

This occurs when we don’t put the persons that; “know what to do” , “how to do it”, “actually do it” and “learn from the results”, in the same team. Knowledge gets lost in translation and you create the wrong thing, that means you have to go back and fix it. If all persons would be in the same team this is far less likely to happen.

Work In Process

It is a big risk to have work in process, think of; uncoded specifications, untested code, not integrated code and code that is not in production. Because as long as it is not done you don’t know for sure that it actually brings value to the business, in fact you are not even sure if it works at all. So you should test early, integrate often and fail fast.

Task Switching

Software development is an intellectual job, meaning your development team actually needs to think about what they should do. So switching between different tasks requires the developer to get back in to understanding the new task, this switching costs extra time. It is far better to complete the different tasks after each other then doing multiple tasks side by side.

Delays

The longer you have stuff that is not done the longer it takes before you get the value from it. So the faster you can go from demand to realization the faster you will receive and utilize the value that it provides.

Defects

Fixing defects later on takes much more time from the team then finding them early in the process, because if you find them early you still know what you where working on and how it worked. So the solution is to create software that has no defects, Mary says it is unacceptable that you would discover bugs during the integration tests. There are very good practices that can protect you from these things.

Process Capability

What is the reliable, repeatable cycle time to go from a customer demand to when the customer need is fulfilled? If you start mapping these processes using a Value Stream then you will be surprised at the low value your process actually offers. It will clearly indicate where you can optimize your process to quicker provide value to your customers.

Now this is enough for one blog post, I’ll write about the other parts of the talk on a later blog post. Also all specific information comes from the slides that Mary Poppendieck has provided to me. And the final disclaimer is that this is my first real introduction to Lean so I could be far of. But one thing is for sure, I’ll look more into it, it was very cool to see two people talk about something which they obviously enjoy very much.