The Software World Is Not Like the Physical World and What That Means

When people study Lean for software development many make the observation that software development is not like manufacturing. People point out that in manufacturing you are building the same things (albeit with some variation) over and over again and try to cut down variation in the process. With product development you are creating something for the first time and can use variation to try new concepts.

However, software development is not like product development in the real world either. Even though both are about creating something of value that is new. It is important to understand these differences and both the risks and opportunities they create.


Relating to visibility

  • In the physical world you can often see mistakes while they happen. In the software world you have to take an extra step to determine if something is wrong (testing). Note this also relates to delays in feedback.
  • It is easy to see when there is too much work taking place in the physical world. This is not true in the software world.
  • The progress being made in the physical worls is more apparent than in the software world.

Relating to dependencies

  • Changing the foundation of something in the physical world often has a significant impact on whatever was depending upon it.
  • Dependencies in the physical world are often costly to change. And there is an additional cost if one tries to decouple them. In the software world dependencies can be decoupled at virtually no cost.

Relating to delays or too much work in process (too much WIP causes delays)

  • Delays in workflow are more readily apparent in the physical world (also relates to visibility)
  • You don’t need to move anything (but your fingers) to shift what you are working on in the physical world. This can easily lead to too many things going one.

Relating to fixing errors

  • Fixes to an error discovered must be done at thet location where the error occurred

Relating to where the product or people have to be

  • The product being used must be present where it is being used.
  • People can team in the software world much easier than in the physical product development world
  • In software it is easy to see track how it is being used and record that for later.

The implications of the above

Avoiding risks

  1. It is very important to create visibility on the work and workflow when creating software. In particular, attend to too much work in process and delays in workflow and feedback.
  2. Errors can replicate quickly in software if dependencies are not attended to.

New opportunities that software presents

  1. Building part of the functionality and using it is possible. This means that we can get quicker feedback on value, usability and design while creating value quickly. In the physical world you can’t move into the bedroom on the second floor before the first one is done. Agile suggests we build in small slices of real value.
  2. Set based development can be done in software without building as much as is needed in the physical world. Instead, working software combined with prototypes and mocking is possible.
  3. Software As a Service is possible.
  4. Tracking actual use of software can cost almost nothing.
  5. Remote service and updates is possible

Learning Lean for Software

Many books have been writing about Lean for software development that attempt to take Lean in the manufacturing world or even Lean product development (I am not referring to Don Reinertsen’s wonderful book here) from the physical world. Both connections that don’t apply and opportunities that do are missed when this happens.

Creating a model for Lean Software Development must go back to these the natural laws of Lean.

  • Take a systems-thinking approach.
  • Remove delays in workflow, feedback and value.
  • Build quality in.