Thermo Fisher Scientific: Introduction
Many Agile practices that work well in software development break down when applied directly to hardware engineering.
This should not be surprising. Hardware development is not simply “software development with longer lead times.” The two disciplines operate under fundamentally different constraints involving dependencies, specialization, prototyping, integration, manufacturing, and the cost of change.
Over the years, I have worked with organizations developing products such as mass spectrometers, telecommunications equipment, and aircraft systems. One of the recurring themes across these engagements has been the need to adapt Agile practices to fit the realities of hardware development rather than attempting to apply software-oriented practices without modification.
The benefits of doing so can be substantial. Organizations that successfully adapt Agile methods to hardware development often experience improvements in schedule reliability, earlier identification of critical risks, better cross-functional coordination, and reduced confusion about priorities and deliverables.
In mid-2013, I was working at Cprime and had just finished a massive research project that produced an equally massive white paper, titled Recipes for Agile Governance in the Enterprise. The goal of this project was to lay out an entire universe of Agile development that spanned all scales from the individual team to the entire enterprise, from side to side and top to bottom. That paper essentially answered every question I had in that space, and its completion left me wondering what to work on next.
The answer came quickly. I had long heard that Scrum could be used outside the world of software development, but examples on the ground were few. Thinking about this led me to wonder if it could be used in hardware development. More specifically, it led me to wonder what kind of Agile process would be useful for developing hardware products.
I could find no articles on the subject, so I decided to conduct my own research. I spent 18 months on a research project focused on answering the question, whose conclusions I summarized in mid-2015 in another white paper, Agile Processes for Hardware Development.
The most important conclusions were quite different from my expectations, which were that Scrum would not be suitable for hardware engineering. To the contrary, Scrum emerged as the right Agile process for hardware development. All of the standard Scrum elements fit the hardware world without modification. What did not fit were the software-centric practices that grew up around Scrum, and which tend to get conflated with it.
Scrum turned out to be a viable process for hardware development, but only after several assumptions inherited from software development were reconsidered. Many concepts that seem obvious in software organizations either behave differently or become much less useful when applied to hardware engineering teams.
One of the most interesting opportunities to test these ideas came through my first Agile hardware transformation at Thermo Fisher Scientific.
Thermo Fisher develops sophisticated scientific instruments and laboratory equipment, including mass spectrometers. The engagement provided an opportunity to apply Scrum in a hardware-development environment and observe what worked, what failed, and what needed to be adapted.
The lessons learned during that effort shaped much of my subsequent work in Agile hardware development.
In this series of articles, I will describe the Thermo Fisher engagement and the insights that emerged from it. Many of the lessons directly contradicted conventional software-oriented Agile thinking, yet proved essential for success in a hardware environment.
The first surprise appeared before Release Planning had even begun. The team’s view of product ownership differed dramatically from what Scrum practitioners in software organizations typically expect.
For those who are interested, the complete Thermo Fisher Scientific case study is available on my website.
