Lean Software Musings

As many of you know, there has been a great deal of recent interest in applying lean manufacturing techniques to software, building on the ideas of Mary and Tom Poppendieck. I think there are various reasons for this, but chief among them is the industrialization of software in the enterprise. I also think it fair to say that many flavors of Agile and DevOps are instances of lean. For example Kanban is lean technique being increasing deployed by Agile teams.

Lean, with its roots in the Toyota manufacturing process revolution, has been around for a while.  But the standard lean literature does not easily apply to Software. Frode Odegard, founder of the Lean Systems Institute, and I have been thinking about the cause and solution to this. As many of you may know Frode is the author of the Lean Systems Framework, a holistic view of adopting lean that has evolved over a decade of client experience.

Our key insight is that software development process is best described not as a set of activities, but as the set of artifacts, their states, maturity, and evolution. In short software development is an artifact-centric process. Some of the reasons we have discussed:

• There is a wider range of uncertainty – Software often entails invention and discovery. The time and effort to complete this work is less certain than well-controlled manufacturing tasks.

• There is often a  indirect relationship between the effort expended and value created – Generally, if one spends 10 hours painting a wall, one can expect there will a lot of wall painted. One can spend 10 days doing requirements analysis on a green field project, and who knows if any value has been added.

• The order of execution is not determined in advance – For software development, the sequence of execution may be influenced by availability of staff, architectural dependencies and the outcome of testing/experiments.

• Software development  often consists of concurrent development of a set of related artifacts – Although we also find artifact dependencies in production and services, software is remarkable in the complexity these relationships, which are often layered, many-to-many and subject to considerable change over time.  Additionally, the relationships are often not entirely well-understood in advance, since they emerge as a result of the knowledge creation effort that yields the artifacts themselves.

In short, value accrues not so much with the carrying out of the activities, but with the maturing of the artifacts. For this reasons and others, Frode and I are exploring how to apply the Value Stream Mapping to software as an artifact-centric process. We hope to have a paper of the topic available soon.

So stay tuned.