Lean Manufacturing and Software

Is writing software more like manufacturing cookies or more like designing cookie cutters? It’s easy to wish that we could develop software like a factory stamps out cookies, but software has a design or creation element that is missing in that analogy.

But there are similarities: software is developed in stages, it is created in a process amenable to change, and it’s developed in a team. Lean manufacturing is a different approach than a traditional assembly line, and offers some lessons for software development.

Value and Waste

A good starting point is to consider what value is, and what waste is.

What are things with value?

Raw materials
An end product that someone is willing to buy
Tools used by the team
The skills acquired by the team

What about intermediate products? They have some value in the sense that they give us the option to create the final product more cheaply than if we started from the beginning. They have no value if nobody is willing to buy the end result. And intermediate products clearly have a cost.

And what is waste?

If it doesn’t add value, it’s waste.
–Henry Ford

Waste – anything other than the minimum amount of equipment, materials, parts, space, and worker’s time, which are absolutely essential to add value to the product.
–Fuji Cho, chief engineer at Toyota

Taiichi Ohno is known as the father of lean manufacturing, and he identified seven types of waste. We’ll consider them and find an example of each applied to software:

Waste	Software Example
Overproduction	Features that nobody ever uses.
Waiting Time	QA waiting for a feature to be written so they can test it.
Transportation Waste	Time waiting for files to copy.
Processing Waste	Software written that doesn’t contribute to the final product.
Inventory Waste	A feature for which development has started, but nobody is currently working on it.
Wasted Motion	Doing a refactoring manually when the development environment can do it automatically.
Waste from Product Defects	Bugs.

Ohno talked about a diagram of a boat that represents the pipeline translating raw materials to a finished product, traveling across the sea of inventory. Every waste in the system is like a hidden rock at the bottom of this sea, which may be a hazard to travel over, and which raises the level of the water and makes the boat travel further.

To make these rocks visible, we will lower the inventory. Then we can work to remove the visible rock.

A Traditional Line

Before we move to solutions, let’s take a look at a traditional assembly line:

Visualize the first person as transforming raw materials (not shown) to A objects, which are passed down the line to someone who converts them to D’s, then C’s, then T’s.

Kent Beck has pointed out that we can think of “undeployed decisions” as the inventory in software. If we think of A/D/C/T as Analysis, Design, Code, and Test, we have here a situation where the analysts are a bit ahead, the programmers are stuck waiting for some design, and the testers (with that pile of Code sitting around) are working on a backlog. (And when they communicate with the programmers, it’s about something that was done a while ago.)

We speak of this as a push system: each worker produces their part, starting and finishing as soon as they can. Notice that the overall pace at which the system produces results is limited to the pace of the slowest worker.

We might try to balance the system: if everything is stable, and we get just the right proportion of workers, we might be able to create a balance. If there is any variability in the task size, this will be very tricky. Furthermore, in the software case, testing is often the part that’s hardest to estimate, and it’s the last step here.

The Solution

The lean approach has several techniques it uses to try to improve this overall system:

Radical Change (“kaikaku“), to get a factor of 10 improvement
- Pull and Flow
Visual Control
People and Training
Incremental Change (“kaizen”), to get a further factor of 2 improvement

Radical Change to Pull and Flow

In the push system above, recall that the pace of the line is limited to the pace of the slowest step. A lean line lives with the same constraint. But the push line adds another constraint: everybody should stay as busy as possible, and we value high utilization of the workers.

Suppose the worker just before the slowest step were to first make the next piece that the slow step needs, and then sit around until there’s just enough time to make the next piece ready when the slow step needs it. The overall pace of the line wouldn’t change, but there’d be a lot less inventory sitting around at that stage.

The radical change is to put this discipline in place for the whole line: steps before the slowest step sit idle until they’re asked for the next part. Steps after the slowest step will be idle when they’re waiting for the slowest step, and busy otherwise.

The new approach is known as the pull approach: instead of making things when you’re ready, you wait until the person after you requests it. When this discipline is in place, you have flow. To know when the person after you is making a request, many manufacturing lines use a card-based system of requests. You return the card along with the batch of items, so it can be reused.

Let’s revise the line above to demonstrate flow. Think of a card as representing a request for action by the following step, and the circle as having the item currently being worked on.

In a lean line, every part in the system is there because someone needs to work on it. In effect, there’s no other inventory.

Once flow is in effect, lean teams will continue to try to identify waste in the system, and try to improve the system further.

People

Nobody has incentives to make their own job go away. The lean approach recognizes this, and many teams will commit that nobody will lose their job because of future improvements.

To help people improve their own skills, some teams track via a job skill chart. It shows people’s names on one axis, and skills on another. When someone has mastered a skill, a mark is put in the intersection. Some teams provide bonuses to people as they are certified in new skills, to recognize their effort and their increased value to the organization.

Teams may use job rotation as well: explicitly making sure that people get to do different jobs over time, so they maintain their skill in a variety of areas. It’s easiest to balance work when people are able to be flexible about what they do.

Teams are given control over their process. They may work with management and experts to help revise and improve their process, but they have the responsibility for it.

A final approach lean teams may use is to develop smooth staffing, wherein the demand for products is managed to make the demand for people smooth. You can see signs of this in the software industry reflected in the attempts companies have made to move from a purchase model to a subscription model: a subscription must be paid when due, but a company may be able to avoid buying software by continuing to use an older version.

Visual Control

To make it easy for teams to know what is going on, lean lines use visual status indicators. (XP teams have an echo of this in their use of Big Visible Charts.) This way, everybody can see and agree on the data, and use their visual processing power to find trends and suggest ideas.

These charts may use color and position coding to provide information “at a glance.” There’s typically a wall or panel devoted to this information.

Another version of visual information is the use of lights on the top of equipment, indicating its status. When something goes wrong, someone can get there immediately and fix the problem.

Kaizen: Continuous Improvement

Once the radical changes have been made, a team will keep looking for improvements. (Agile teams using retrospectives are making a similar commitment.)

Teams will standardize their processes. They’re willing to change them if they find a better way to do them, but until then they’ll find the best way they can and apply it consistently. They’ll document the process (often in a card at the workstation). The team seeks a better way: a way to simplify, combine, or eliminate steps.

Where possible a team will install foolproof mechanisms (poka-yoke) that make a part automatically move to the right position, or easily reject wrong parts. I see an analog of this in the way software teams apply tools such as configuration management systems, automated builds, and refactoring support. Keith Ray points out (https://web.archive.org/web/20080724043854/http://homepage.mac.com/keithray/blog/2003/11/13/ [page no longer available] and https://web.archive.org/web/20110106171937/http://homepage.mac.com/keithray/blog/2003/11/15/ [page no longer available]) that test-driven development is a form of poka-yoke.

Another improvement tool has become known under the name SMED: Single Minute Exchange of Dies. In car manufacturing, changing from making one part to another can be a lot of work. The traditional solution has been, “make a long run of parts after a die change,” but this creates a lot of inventory. SMED encourages a team to be able to make a changeover quickly, so inventory is not necessary. For a software team, I wonder, “how quickly can you change direction?”

Even small things can help: teams focus on simple housekeeping. By keeping the area clean, it can be clear when tools or materials are out of place. Spending 5 minutes looking for a tool doesn’t sound like much, but when you do it many times and in many places it adds up.

The last tool I’ll mention is the ability of teams to “stop the line.” Whenever a problem occurs, anybody is empowered to stop the line. When the line stops, people investigate. They do a root cause analysis by asking “why?” five times. Software teams can adopt this tool as well: make it a rule that anybody can ask for help or for the team’s attention at any time, and don’t settle for fixing immediate causes when you address a problem.

Application

So, ask yourself these questions:

How much work, that nobody is working on right now, do you have in your pipeline?
When a new requirement goes into the pipeline, how long does it take before it reaches the end?
Do you have a process for continually improving your process?