Mik Kersten’s Project to Product is a must-read book for engineering leaders seeking to better understand, measure, and improve their overall software delivery flow.
Mik’s change in perspective and understanding about software delivery was triggered by a visit to the BMW Group’s Leipzig plant. This plant builds some of the most advanced cars on the planet. There are very tight per-stage completion windows so that completed cars are produced every 70 seconds. This was a real-world Gemba walk through a physical space. The space was designed to funnel blocking coordination to a single location while also providing physical architectural affordances for future flexibility. Mik describes this experience as transformative:
The visit involved a 10-km walk along the plant’s production lines, with plant leadership explaining each system, process, and tool involved in car production. That visit impacted my understanding of lean manufacturing more profoundly than all the books I’ve read on lean processes.
Like Mik’s own narrative, I won’t spoil the mystery of the one assembly line stage that introduces synchronous, blocking coordination. However, IT Revolution has already espoused the three epiphanies:
- Epiphany 1: Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream.
- Epiphany 2: Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project management model.
- Epiphany 3: Software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products.
Mik shares these epiphanies over several chapters and while listening to the audiobook, I had two thoughts that continually resurfaced.
Measuring the Invisible#
Mik’s journey to Value Stream Mapping and a common ontology for representing SDLC events across the entire organization is very similar to Dominica Degrandis’ Making Work Visible. In the absence of a shared, externalized representation, it’s challenging for organizations to discuss organizational-scale bottlenecks. Each functional handoff boundary presents friction for the affected individuals, but without a common representation across the entire organization, optimizing those interfaces may be overall wasted work.
Like the stories shared in Goldratt’s The Goal, per-stage processing backups and wasted work product are immediately visible in physical spaces. Walking the floor provides direct, sensory input. We can see rejected pieces piling off to the side, workers filling out redundant paperwork, how lighting conditions create shadows that impair execution, etc. Whether those observations are deemed important or actionable is another issue, but they are more difficult to ignore.
Contrast this to large-scale software delivery. Some CI/CD systems (go CI/CD) do offer Value Stream views. But even those are typically confined to the engineering silo, and even then typically scoped to even smaller sub-teams or domains (front-end, backend, mobile, etc.). As a crude analogy, it would be as if the BMW plant had a dedicated assembly line plant for wiring, another for body construction, another for interior assembly, etc. The bottleneck is a global constraint, not an arbitrary local one.
Misapplied Metaphors#
Another high level learning Mik draws from his experience is that the metaphor of industrialized, standardized factory assembly lines fundamentally misrepresents the nature of large scale software delivery and cognitive work in general. Software is not about the predictable delivery of units, the type of commodified “widgets” that are the province of microeconomic theory.
In the factory metaphor, commodified and fungible units are pushed down the assembly line. The assembly line speed itself is the ultimate constraint, as in Lucille Ball’s epic skit. The line waits for no one.
Independent stages are optimized, unit variance is reduced, yields are maximized, and overall end-to-end time is optimized.
Those practices stem from a fundamentally misleading metaphor. Delivering software has more structural similarities with dynamic flight routing. In response to weather or mechanical events, flights and connections can be rebalanced, layovers can be adjusted, passengers can switch routes to reach their final destination. Routing may need to take into account fuel levels, different plane sizes and runway availability, local time zones, etc. The system affords some flexibility, assuming there is slack.
The model of a dynamic, adaptive flight connections map has more structural similarities with software development than an (idealized) static factory line does. Code can ship with fewer tests, disaster recovery can be deferred, some code (schema changes) is “bigger” than others (CSS color tweaks), team members can route around internal dependencies, team members can shift between domains to load balance queued work.
This more dynamic model requires a significantly different management style than Taylorist industrial practices. It’s a management philosophy that according to Mik, is essential for companies to survive the ongoing software revolution. It’s also a style that, according to his experience, is frequently missing. This legacy conflates tool sprawl, activity metrics, and proxy metrics with success and adoption while concealing an impending software delivery failure.
Work to Make Work Visible#
BMW didn’t build a pipeline to produce an unbounded number of car assembly plants and measure each one’s effectiveness. They went through the messy process of creating a shared understanding of their assembly bottleneck invariants, built a single plant around that shared understanding, and included physical affordances to accommodate a reasonable set of likely yet ultimately unknowable future changes. That was a two billion dollar consensus-building exercise.
Mik doesn’t talk about that work, which seems completely reasonable as I’d imagine BMW would prefer that be private.
I think this story would have been even more compelling than the one he shares walking the factory floor. As in software development, there is no “pipeline for building pipelines”, only a messy process of alignment, consensus and disagreement regarding which bottleneck the organization is willing to tolerate. This is the hard, invisible Work required to Make Work Visible.