I’ve only just started reading this book, but so far it has amazed me in pinpointing, and eloquently describing, some of the problems I’ve felt we have in my experience of Software Development and how Lean thinking (which comes from modern manufacturing) helps and can be applied.

For example:

Eliminating “wastes” of Software Development

The four which I found most relevant were:

• Partially done work
  • Which includes code which is not deployed in the hands of the users
• Extra features
  • Designing and building a fuller ‘solution’ up front without having any (or much) user feedback.
  • …because it’s not live, because it takes so long to build and go live, so the customer wants more features (or features which are richer) when they finally do get a release, which in turn means development takes longer and around we go…
• Task Switching
  • The cost of people on teams being interrupted, especially if they have large (multi-day long) tasks to complete, is very high and prevents working in “flow”
• Defects
  • waste = (impact of defect) x (time from creation to discovery)
  • e.g. a high impact defect discovered by unit tests run a few mins after writing the defect is much less waste than a lower impact defect e.g. performance defect, which isn’t detected until a few days after release to users

Also, some useful questions for discussion e.g. do you agree the “waste” is really waste, how much time does each consume in an average week, what can or should be done to reduce the time.

Value Stream Mapping

A simple technique but once which highlights the work and wait time for tasks i.e. delays in the system from user request to “thank you” (as Dan North puts it).

Amplify Learning

Software Development is largely about learning, i.e. it’s like creating a recipe, not following one, however it is often treated like a large baking project with the ‘requirements’ as the recipe.

Feedback

Feedback is highly important as there are many unforeseen events in developing software. However:

Traditional project management approaches often consider feedback loops to be threatening because there is concern that the learning involved in feedback might modify the predetermined plan. The conventional wisdom in project management values managing scope, cost, and schedule to the original plan. […] This mental model is so entrenched in project management thinking that its underlying assumptions are rarely questioned. This might explain why the waterfall model of software development is so difficult to abandon.

I see this a lot with projects trying to go “agile” but ending up with mini-waterfalls or “scrummerfall” – which is certainly better, but seems highly sub-optimal.

A great analogy they used was “Deterministic Cruise Control”:

Imagine driving a car in which the position of the accelerator was pre-programmed at the factory. If you want to go 60 mph, it moves the accelerator to position A; if you want to go 65 mph, it moves the accelerator to position B, and so on. This might work on flat terrain, but when it got to a steep hill, the car would slow to a crawl. Upon reaching the top, the car would careen dangerously fast down the other side.
Deterministic control simply does not work when there is variability in the terrain.

That’s it so far, I better carry on reading!