In the Age of Mass Production, which began at the turn of the 20th century, we witnessed engineering organizations master complex product delivery. Since that time, product complexity has continued to grow, fueled recently by an ever-growing number of electronic and software components. For example, in the 2000s, approximately 40 percent of a car’s cost was in its electronic systems. As the electronic components become more core to the automotive experience, the software in those systems also became more complicated. We are now getting to the point where a modern car can have dozens of electronic control units and over 200M lines of code, with the cost of building that code exceeding the cost of the engine itself.
The problem is that most large organizations outside of the tech giants are much better at managing physical and electronic product delivery than they are at managing large codebases of software. An example of this is the dramatic rise in software-related recalls rates for cars, which has been rising steadily. In 2016, for the first time software flaws were responsible for nearly as many recalls as electronic components.
As software complexity grows, the rate of software-related recalls is likely to continue climbing at a disturbing pace. The irony is that the very same methods that the automotive industry applied to master the quality and consistency of car production in the last century, such as lean manufacturing, have not been adequately applied to the software that is running in the cars. Meanwhile, cars are turning into computers on wheels.
Many organizations whose DNA comes from physical product delivery treat software and IT systems differently because the features and flaws of software are not delivered through a physical manufacturing process. But what if we applied product development and lean manufacturing principles to software products? What if we stopped treating software as projects that have one or two-year timeframes and budgets before moving into maintenance mode, and instead focused on metrics such as lifecycle cost and profitability? What if we organized our software organizations in the same way a car manufacturer arranges and optimizes its assembly lines? And what if we measured customer-centric product metrics such as lead time instead of the multitude of Agile and DevOps metrics that are utilized today? As it turns out, these are the kinds of practices that the most innovative software companies already have in place today. And it is time for the rest of the world’s organizations to catch up.
The challenge then is in applying the key learnings of physical product development to software delivery. In his seminal book, The Principles of Product Development Flow, Donald Reinertsen outlines some of these key lessons. He also outlines the pitfalls of only considering the manufacturing process instead of understanding the end-to-end process of product development. If we look at software delivery, or mixed software and hardware delivery, in an end-to-end fashion, we will see some common principles apply. For example, delivery needs to be organized into product value streams that align with the value that the customer is pulling. And that the whole endeavour of scaling delivery is all about ensuring that value can flow without interruptions.
It is only with this mindset that we start seeing software delivery for what it is—a complex collaboration network that produces intangible assets through conversation, coding and cooperation between numerous specialists. These lines of collaboration form a complex network which needs to provide flow, feedback and traceability. This work manifests major differences from physical production. For example, there is no linear or batch-based assembly line process, as all steps that correspond to production can now be automated through DevOps approaches. What we have left is similar to the art for product delivery that Reinertsen envisions: a connected value stream network. It is this way of thinking that scaled how products are made, and that will soon define the future of software delivery.
An abridged version of this article was originally published in the EE Times on January 30, 2019.
Further reading
https://blog.tasktop.com/blog/end-manufacturing-line-analogy/
For a deeper dive into Value Stream Networks to optimize the way you plan, build and deliver software products at scale, grab a copy of Project to Product by clicking on the front cover:
