In Project to Product, Mik Kersten introduces us to the concept of the Flow Framework, a new way of mapping the delivery of value through an organisation. It is proposed that we are now in the Turning Point of the Age of Software.
[The Turning Point] is when businesses either master the new means of production or decline and become relics of the last age
Throughout Project to Product, we’re presented with the narrative of a gemba walk around BMWs Leipzig plant. We are specifically looking at a company that has mastered the Age of Mass Production and use it as a platform to compare the two ages and what may come to pass following the Turning Point of the Age of Software. Kersten also introduces a number of personal experiences, his three epiphanies, that led to the development of the Flow Framework.
Kersten argues that the traditional comparison of software delivery to a linear manufacturing process that resembles an automotive production line is wrong. We’re introduced to the notion that historical management techniques are not adequate to succeed in the Age of Software. The ultimate aim of the book is to introduce the Flow Framework as a way to connect the business to the delivery of software in the IT value stream.
BMW Leipzig plant
I found the description of the gemba walks through BMW Leipzig plant compelling. Here is an example of a company that appears to have truly mastered the techniques of the Age of Mass Production. The product that is being sold and the value stream that drives it is visible to all. The whole building is even designed around it.
The continual telling of this story provides a fascinating backdrop to the arguments being presented throughout the book. Here we see a manufacturing line that evolves as the needs of the customers change, and it is built into the very building that produces these products. It struck me that the process of delivering the product was the most important aspect of the delivery of these products. In comparison with software delivery, where so much of this is hidden, it’s hard to argue with the fact that we should definitely be doing so much better.
Ultimate accountability
It’s hard not to be drawn into the story about how the heads of software engineering at Boeing were all on board the test flight. As a software engineer, it can be very easy to find yourself disconnected from those who use the very software you are developing. Whilst the story itself certainly draws you in, it was where the narrative led struck a cord, that traceability of the software was so important. In a world of increasingly distributed software architectures, including MicroServices and Serverless, observability of software systems becomes more and more important. This passage helps to highlight how the instrumenting software can help tie up the business goals the software has been built to fulfil and ultimately how IT and the business must be connected.
Value Stream Metrics
I am a big fan of Value Stream Mapping, so I was especially excited to get to this part of the book. It didn’t disappoint. Particularly interesting was the discussion on flow distribution, being explicit between the types of work being undertaken and the impact making the trade-off between incurring technical debt and delivering new features for the business.
Thinking in terms of flow distribution trade-offs elevates the understanding of software-delivery trade-offs to the business.
If pressure from the business to deliver new features while fixing defects does not abate for several quarters, debt backlogs could get to the point where new-feature delivery will no longer be feasible.
Of course, the main driver for the book is to talk about how we relate all of this back to business results. To do that we need to look at how we measure value. Kersten calls out value, cost, quality and happiness as key business result metrics. The main message I took from this is that it should be the same message coming out of each team, a common language that the business as a whole can rally around and understand. Of further importance is making all of this visible.
Value Stream Networks
All of this was obviously leading somewhere, that somewhere is what Kersten refers to as Value Stream Networks. It is here we get to the crux of the problem we have in software delivery today. Kersten states we have two options:
Either we undertake the kind of billion-dollar investments that the tech giants have undertaken into creating a unified tool suite or we need to connect off-the-shelf tools produced by vendors and open-source projects into a Value Stream Network.
It is here that the aforementioned three epiphanies really come to the fore and frame the need for the Value Stream Networks. Namely that software productivity declines and thrashing increases as software scales and disconnected software value streams are the bottlenecks to productivity at scale. This is tied into the title of the book and asserts that application of the project management model is counter to the product-oriented software value streams.
The challenge
Once we acknowledge that software delivery exists in a Value Stream Network, we can begin to elevate our thinking and really begin to optimise delivery of software products. Our biggest challenge looking forward is how can we take these viewpoints and look inwardly as an industry. Kersten states that as with any new concept, there are further things to consider in its implementation that will be specific to your organization.
We’re are in the Turning Point of the Age of Software, this book just might provide the framework for helping ensure our businesses survive and ultimately thrives.
Having read Project to Product, I would absolutely recommend this is on the reading list for anyone involved in software delivery and organisational leadership positions. Go read it!
