What is Agile Hardware?
The phenomenal success of the Scrum framework, as an approach to organizing and conducting software-product development, is now well known. Many words have been written on the topic (some of them by me), and many more doubtless will be written in the future.
Among those “words” that I have read are numerous statements that Agile techniques, and the Scrum framework in particular, could be used outside the world of software development. While I always found this argument believable, I saw very few references to attempts to employ Scrum anywhere but in software development. I’ve encountered a few one-off references to using Scrum for Marketing, or other areas, but none of these represented any kind of systematic application to a new domain. To me, this omission was disappointing.
The Origin of Agile Hardware
In October 2013, I spoke at the annual Symposium of the Silicon Valley chapter of the Project Management Institute. My topic was Cprime’s new RAGE framework for large-Scale Agile development, which I’d created to support the needs of Cprime’s larger clients. The single most important principle of RAGE, which I borrowed quite explicitly from Scrum, was the notion that the framework should not focus on software development specifically, but provide generic capabilities for organizing product-development work that were applicable for organizations of any size.
In other words, RAGE was perfectly positioned for use in domains outside software development—domains such as hardware development.
The Symposium turned out to be the perfect place to begin the effort to bring Agile approaches to hardware-product development. I met John Carter, of TCGen, and was intrigued by his presentation on Agile techniques he had observed in use at hardware-product companies. I met John, and suggested that we launch a research project into developing holistic Agile solutions for the hardware-product world. John liked the idea, and looped in his colleague, Dr. Scott Elliott, and the three of us began the research.
How we conducted the Agile Hardware research is detailed in my paper, “Agile Processes for Hardware Development,” and my webinars on this topic. The single most important finding from our research is that the Scrum framework applies directly to the development of hardware products, although the nuts-and-bolts of what development-team members do on a daily basis is obviously quite different in a hardware context, compared to the familiar software context.
In 2015, while wrapping up the white paper, I had an opportunity to employ our discoveries at Cprime’s first Agile Hardware Client: Thermo Fisher Scientific, a leading maker of devices used for the analysis of chemical samples (e.g., Mass Spectrometry, Gas Chromatography, and related devices). To my surprise, our predictions were born out in every respect, and the applications of the Scrum framework to develop new Mass Spectrometry equipment proceeded with truly eerie smoothness. (See our papers and presentations on the Thermo Fisher experience here.)
Experience with introducing Scrum for Hardware at Thermo Fisher and other Cprime clients has now confirmed that Agile Hardware development is real, and works well. In this and subsequent posts, I am going to describe some of the “hard” practical skills required to develop physical devices in an Agile way. Before we go any further, though, we need to know just what is meant by “hardware.”
By “hardware,” I refer to mechanical, electro-mechanical, and electronic devices, which are produced in volume from a detailed manufacturing specification. These devices may contain software, be associated with external software, or have nothing to do with software, but all of them are made out of matter. These were the kinds of products on which our research focused, and which were of primary interest to Cprime clients. These physical products are first designed, and then mass-produced, in volumes ranging from hundreds to hundreds of thousands.
I specifically do not refer to physical artifacts such as bridges, houses, pipelines, ditches. Nor am I addressing the development of custom, one-off devices. The techniques we describe may be useful in such areas, but that is not my focus.
So much for hardware. Now, what is “Agile Hardware development?” I can think of a few definitions:
The construction of physical devices in an Agile way. This means using the planning and tracking techniques of (say) Scrum to construct a single device. This is a custom-manufacturing model, where design and construction are intertwined, and yield a single custom device at the end.
Techniques or practices that shorten turnaround time for physical components. I’m thinking of 3d printing (additive manufacturing),or selection of vendors who can turn designs (such as this week’s prototype circuit board) into components swiftly.
An Agile approach to developing the design of a device to be manufactured. This concept is about the process of organizing and conducting the work of creating the design and manufacturing specifications of a physical product. The Scrum framework, applied in a hardware context, would be a major element of this picture, as would Agile techniques for Program and Portfolio management.
The first two items describe useful capabilities, but the third is my focus.
This post is the first of a series, which together dive deeply into the practicalities of Agile hardware development, and clarity on how Agile hardware development differs from Agile software development. All of those posts require some common background, so now we’ll look at more background information.
The Reality of Agile Hardware Development
We need to answer a basic question: If a develop Team is using Scrum (and hereafter referred to as a “Scrum Team”), what exactly do they develop? What kind of deliverables (things to be made) do they create? And how do these deliverables relate to the products we can purchase?
In a software context, the answer has long been known. Here, I will phrase the answer a bit differently than is commonly the case, to better clarify the similarities and differences with respect to hardware development.
A Scrum Team’s deliverables are primarily parts of a software product. The aggregation of deliverables over time yields a product that has more useful capabilities over time. For example, a product in development at the end of June can do more things than it could at the end of January.
A useful byproduct of this kind of product evolution is that it enables frequent stakeholder-review opportunities, e.g. monthly, at which we can demonstrate the current state of the product and get useful feedback on the direction we are taking with the product. This feedback loop is a key mechanism for enabling us to tune the product direction over time, to reduce waste and increase value by discovering and shutting down unprofitable directions to focus on directions that provide better value.
A Scrum Team focused entirely on creating a physical product also creates deliverables over time, but these deliverables are primarily about components of a design to be manufactured at a later date. Thus the aggregation of deliverables yields a design that can be built at the end of the development work. While the team will doubtless create physical prototypes along the way, as the design accumulates more components, the product as such does not meaningfully exist even, in prototype form, until late in the product-development lifecycle.
This reality means that we cannot conduct frequent stakeholder reviews of new functionality in a hardware context, the way we can in a software context. This is unfortunate, but also unavoidable. This does not mean that we should conduct no stakeholder reviews, but does mean that they will be generally less frequent, and more focused on mockups and concepts, than is the case for software products.
One of the most commonly-praised aspects of Agile development for software is that it enables exactly the kind of frequent reviews and adjustments to product direction that I’ve just said are not possible for hardware products. If that is the case, is an Agile approach useless? Might we not be at least as well off with the Waterfall approach that has traditionally been used for hardware, much as it was once used for software?
The answer is, “No.” Aside from this one difference, most of the benefits of an Agile approach to software development apply to hardware development in much the same way as they do to software development. For example, Waterfall-style processes are prone to experiencing the drawbacks listed below, each of which is sharply reduced by an effective Agile approach:
Unrealistic schedules
Late discovery of schedule slips
Silo-ed working groups lead to late integration problems, focus on engineering issues versus customer needs
Poor visibility into plans, status of work
Great difficulty associated with attempts to change direction
Levels of Governance
Our Agile Hardware research project predicted that the Scrum framework would be effective for organization and conduct of work at a small-team level (three to nine people), must as it would be for software teams. Our research also clarified that the number of people involved in development of hardware products would be substantially larger, on average, than is the case for software products. This is partly due to the need for more specialties, and partly due to incorporation of software developers into the larger picture of product development for physical products.
The larger population of development personnel in hardware-product development means that Scrum, alone, is insufficient to organize the required work. We must divide a population of tens to hundreds of people into Scrum Teams, and use the techniques of Agile Program Management to ensure that we can plan and execute work in a synchronized and collaborative fashion across all of these Teams. Agile Program Management is inherently linked to Agile Portfolio Management as well, and the importance of the latter likewise grows as the “head count,” and dollar values, grow. Thus we will need to generate this classic three-tier structure in our product-development organization:
At the bottom level, denoted as the “Project” or “Team” level, we describe how a single Scrum Team organizes, plans, executes, and tracks its work. This work is accomplished via the Scrum framework.
At the top (Portfolio Management) level, the organization as a whole must make strategic investment decisions about product development, involving funding levels from tens of thousands, to millions, of dollars. It is critical that the organization be able to align these Portfolio decisions and the day-to-day work carried out by the Scrum Teams.
The Program-Management level provides the alignment between the Portfolio and Project levels, and ensures synchronized planning and coordination across Scrum Teams.
When properly devised, with the appropriate set of Agile techniques, these three layers work together as an organic whole to manage product development. The Agile approach simultaneously maximizes autonomy at each level, while ensuring alignment with the other levels.
Results
The subsequent articles in this series will describe how various aspects of Agile Hardware development are done, in very concrete ways. For now, I will conclude this article with a quote from Dr. Michael Bedford, Senior Scientist at Thermo Fisher Scientific. I worked with Dr. Bedford and others to create the first Agile hardware team, in what proved to be a very successful transformation.
Five months after we began the transformation, I contacted Dr. Bedford to get his thoughts on how this new approach was working. What he had to say was so positive, that I will leave the last word of this article to him:
“First and foremost, running this project with Scrum is an ongoing success. The team has formed nicely and we have proper buy-in from each team member. I make technical decisions with more input from the team than any other project that I have worked on. Grooming is a hassle because it takes so much time and requires us to stop doing and think, but the drawbacks I mention are also the clear benefits. We take time to plan. And we plan together.
“The daily standup is a life saver. As is the board. I can quickly understand where we are and what needs to be done. Release planning has been beneficial because it really focused the team onto what our big goals are as opposed to smaller engineering goals. I feel that management here in San Jose is excited about Scrum. I have had many of the bosses and decision makers stop by and ask about the process.”
