Blog Planview

Votre parcours vers l’agilité métier

DevOps Teams, Enterprise Agile Planning, Passage de projet à produit, Value Stream Management

What Software Needs to Learn from Physical Product Delivery

Publié le Par 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 dans le EE Times le 30, 2019 janvier.

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 Du projet au produit by clicking on the front cover:

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

Articles similaires

Rédaction du contenu Mik Kersten

Mik Kersten a commencé sa carrière en tant que chercheur scientifique chez Xerox PARC où il a créé le premier environnement de développement orienté aspect. Il a ensuite été le pionnier de l'intégration des outils de développement avec Agile et DevOps dans le cadre de son doctorat en informatique à l'Université de Colombie-Britannique. En fondant Tasktop à partir de cette recherche, Mik a écrit plus d'un million de lignes de code open source qui sont toujours utilisées aujourd'hui, et il a mis sur le marché sept produits open source et commerciaux réussis. L'expérience de Mik dans le cadre de certaines des plus grandes transformations numériques au monde l'a amené à identifier la déconnexion critique entre les chefs d'entreprise et les technologues. Depuis lors, Mik travaille à la création de nouveaux outils et d'un nouveau cadre - le Flow Framework™ - pour connecter les réseaux de flux de valeur des logiciels et permettre le passage du projet au produit. Mik vit avec sa famille à Vancouver, au Canada, et voyage dans le monde entier, partageant sa vision de la transformation de la façon dont les logiciels sont construits. Il est l'auteur de Project To Product, un livre qui aide les organisations informatiques à survivre et à prospérer dans l'ère du logiciel.