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 want 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.
Differences Between the Physical World and the Software World
- 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). In other words, just to get feedback about how things are going requires an extra step in the virtual world.
- 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 world is more apparent than in the software world.
- Changing the foundation of something in the physical world often has a significant impact on whatever was depending upon it. In the software world, however, decoupling a foundation from an implementation using it is not costly.
- 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.
Delays or too much work in process (too much WIP causes delays)
- Delays in workflow are more readily apparent in the physical world.
- You don’t need to move anything (but your fingers) to shift what you are working on in the virtual world. This obscures the real cost of task switching and leads to too many things going on at one time.
- Fixes to an error discovered must be done at the location where the error occurred, but in the virtual world fixes can often be made remotely.
The implications of the above
- 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.
- Errors can replicate quickly in software if dependencies are not attended to.
Opportunities in the Virtual World
It’s not all bad, however. In the virtual world there are several opportunities possible that can’t be replicated in the physical world without significant cost.
Incremental Design, Construction and Delivery
A certain degree of incremental development and delivery is possible in the physical world. For example, housing complexes are built one house at a time. But the increment of value in the physical world is usually greater than in the virtual world. For example, while you can’t move into the second floor of a house until the first one is built. However, in the virtual world it is often possible to do the equivalent of this.
Building part of the functionality and using it is not only of value for quick delivery. 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.
While set based development is often required to try out different options in the physical world, the equivalent of it can often be done by combining working software with prototypes and mocking is possible.
The cost of replicating software (such as software as a service) is significantly lower than in the physical world.
You can track how software is used for virtually no cost.
Remote service, error tracking and updates is possible.
People can team in the software world much easier than in the physical product development world.
Learning Lean for Software Development and Knowledge Work
May approaches promoting Lean in software development build directly on Lean as it applies to software development or scoff at Lean for software development. The first misses opportunities while the second demonstrates a lack of understanding Lean.
Lean is an approach and attitude integrated with an understanding of some key, universal truths, that apply differently in different situations. This is not unlike how gravity applies under, on and above water, but in different ways.