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:

1. The essential paradigm shift of lean and why it applies even more to software
2. How the physical world is different from the software world during implementation

The Essential Lean Paradigm Shift.

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.

How the physical world is different from the software world during implementation,

A Lean mantra is “eliminate waste.” In the physical world, one can see waste in many forms:

• Materials left over on the shop floor
• Inventory on-hand that isn’t needed yet
• Improperly made items that are hanging around, waiting to be fixed
• The amount of work that is taking place

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:

1. Delay from getting information until using it (e.g., old requirements)
2. Delay from making an error until detecting it (e.g., long time between code and test)
3. detecting an error until fixing it (actually a variant of #1)
4. waiting on someone for information
5. waiting on the next person to hand the work off to
6. workflow interruption due to something else receiving our attention

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.”

For a seven minute expose on how delays cause a lot of extra work, watch: How Delays Cause Waste, A Main Tenet of Lean one of our Lightning Webinars.

A few things int he physical world that don't exactly migrate to the software world

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.

Summary

While Lean springs from manufacturing, the insights that were so relevant there are even more critical in software.  The main lessons are:

1. We must eliminate delays in our workflow
2. We must make our work visible
3. Work in software development is not visible, but delays, which can be seen via queues, are
4. Detecting errors quickly is essential
5. Large queues are detrimental
6. We must recognize the difference in how variation should be managed in the physical and software worlds

Al Shalloway
CEO, Net Objectives