Since lean comes from manufacturing, many question its validity for software developers. Our own experience is that Lean in software is very important. This blog covers three areas:
Lean builds on top of Deming’s systems thinking and management style. Taichii Ohno, the creator of Lean, says he added two concepts to Deming’s work: a focus on “just-in-time” and “autonomation”.
Just-In-Time basically means, do work just in time for the following step. In software it means don’t do the requirements too far before you are ready to design. Don’t do the design too far before you are ready to code. Don’t code until you are almost ready to test. Agile manifests this by having small batches or even, as in XP, doing these different tasks seemingly simultaneously. The essential shift here is to take our focus off of productivity and people or machines and put it towards time and the workflow. In other words, instead of attempting to have each stage of the work (or each person) be as productive as possible, we focus on eliminating the delays between the steps. Just-in-time can be implemented by having small batches of work and coordinating the flow via pull.
Autonomation means automation with a human touch. Essentially, things should flow until there is an error and then a person needs to step in, see what happened, and improve the system.
Both of these concepts apply to software development, even more so than in the physical world. The reason is that when one doesn’t do “just-in-time” work piles up and delays occur between work stages. This increases the amount of work to be done even when errors (e.g., bugs) don’t occur. When errors do occur, these delays dramatically causes extra work. Consider the time it takes to fix a bug when it is detected immediately. Detect it just a couple of weeks later, and even if it hasn’t escaped from the development team it will take many more hours to fix than when caught early. In other words, just-in-time in software saves more than it does in building physical world products.
A Lean mantra is “eliminate waste.” In the physical world, one can see waste in many forms:
Unfortunately, in the software world, none of these are visible, at least not directly. The mantra – “eliminate waste” is a sound good mantra that provides little guidance. However, these wastes can be made visible by focusing on tracking delays in the workflow. Virtually all wastes in software development come from one of the following types of delays:
The salient characteristic of delay is that it can be made easily visible by noting the relationship between queue size and delay. If we create a workflow board (Kanban board) that explicitly describes our work, then we can see delays in our workflow by having queue sizes being larger than they should be. Hence, while the mantra “eliminate waste” makes sense in the physical world, in the software development world it should be “eliminate delays.”
In my view, it's not that physical world Lean doesn't apply to the software world as much as it is far from comlete (as discussed in the earlier section). The paradigm shift of attending to time created from physical world Lean applies to the software 10 to 100 times over. However, there are a few things in the physical world that should not be copied outright. Perhaps the most significant is one-piece flow. In a fairly set, low variation manufacturing line, this can be accomplished. In the software world it is often a bad idea. Trying to achieve low variation in software is not bad after it hits the team and is actually being designed an dbuilt. But trying to have eliminate variation on what is being built has definitely bad business consequences of avoiding risk on new products that should be taken.
While Lean springs from manufacturing, the insights that were so relevant there are even more critical in software. The main lessons are:
CEO, Net Objectives