This article presents a different way of looking at lean software development; one that is independent of lean’s manufacturing heritage. It begins by presenting lean as a collection of a body of knowledge applying lean principles to software development.
Many companies have heard that the concepts and methods of lean would be of use to their organization; however, they do not see how something that sprang from manufacturing practices could apply to software development. This article presents a different way of looking at lean software development; one that is independent of lean’s manufacturing heritage. It begins by presenting lean as a collection of a body of knowledge applying lean principles to software development. It then shows how this creates a new paradigm of management, one that does not inevitably lead to micro-management or chaos. Finally, it concludes with a discussion about how organizations can use Lean to improve their ability to learn.
The Lean Paradigm Shift – Lean Science
Lean represents a paradigm shift from focusing on increasing productivity to focusing on shortening the time from the beginning of work to the completion of it. While lean adopters are looking for higher productivity and lower cost, they have learned that going after these directly actually results in lower true productivity (value delivered per person) and higher costs. The reason is that productivity measures too often are geared toward how much work people are doing rather than how much true value is being delivered and cost, alone, is inadequate for deciding on process and/or product improvements. For example, measuring how much work people are doing leads to keeping people busy. Unfortunately, this leads to overworked analysts, developers and testers are incredibly busy while seemingly taking forever to deliver what the business stakeholders need. It does not translate into true added value.
Lean science could be said to be the set of testable knowledge based on the foundations of lean thinking. To summarize, these foundations are
- Attend to the system in which development takes place; that is where the bulk of errors are;
- Respect the people doing the work;
- Attend to the time from when work starts until it is consumed by the customer (“cycle time”);
- Get to the root cause of errors when they occur.
The foundational tenet of Lean is, “focus on shortening cycle time.” Productivity will follow. In other words, Lean is based on the hypothesis that shortening cycle time raises productivity by reducing the delays that make error detection more difficult and it lowers cost because this delay in error detection increases the amount of work needing to take place.
Consider the type of work we do in software development.
These items are not listed in any particular order; I am not implying any particular process. The activities on the left represent work that provides real value while those on the right represent work which we often must do but which don’t really add value. In the Lean world, these latter activities are called “waste.” And it is good to try to eliminate waste.
The problem with trying to eliminate the waste is it is often created by people who are not doing the work. Consider the problem of two ditch diggers. Both are working hard. One is digging away and throwing his dirt into the other guy’s hole. Stepping back, you can see the first guy is creating extra work – “waste” - but down in the trenches, the second guy just sees still more dirt that he has to remove. Sometimes waste can’t be seen until you look at the entire picture.
It is easier to say “eliminate waste” than it is to actually eliminate it. We can’t just stop doing wasteful things; we must stop the need for doing them. Let’s consider the wasteful activities on the right-hand side of Table 1 and what