Din väg till smidighet i affärsverksamheten

DevOps Teams, Agil planering för företag, Skift från projekt till produkt, Hantering av värdeströmmar

What Software Needs to Learn from Physical Product Delivery

Publicerad By Mik Kersten
What Software Needs to Learn from Physical Product Delivery

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.

Figure Source: Project to Product.

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.

Figure Source: Project to Product.

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 i EE Times den 30, 2019 januari.

Further reading

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 Projekt till produkt by clicking on the front cover:

Click image to pre-order a copy of the book.

Relaterade inlägg

Skrivet av Mik Kersten

Mik Kersten började sin karriär som forskare på Xerox PARC där han skapade den första aspektorienterade utvecklingsmiljön. Han var sedan pionjär i integrationen av utvecklingsverktyg med Agile och DevOps som en del av sin doktorsexamen i datavetenskap vid University of British Columbia. Mik grundade Tasktop utifrån den forskningen och har skrivit över en miljon rader öppen källkod som fortfarande används idag, och han har tagit sju framgångsrika produkter med öppen källkod och kommersiella produkter till marknaden. Miks erfarenheter av att arbeta med några av de största digitala omvandlingarna i världen har fått honom att identifiera den kritiska bristen på kontakt mellan företagsledare och tekniker. Sedan dess har Mik arbetat med att skapa nya verktyg och ett nytt ramverk - Flow Framework™ - för att koppla samman nätverk för värdeskapande av programvara och möjliggöra övergången från projekt till produkt. Mik bor med sin familj i Vancouver, Kanada, och reser världen över för att dela med sig av sin vision om att förändra hur programvara byggs. Han är författare till Project To Product, en bok som hjälper IT-organisationer att överleva och blomstra i programvarans tidsålder.