Mayo Clinic Engineering

Mark Wehde

Last spring, we were faced with the immovable object of the impending global pandemic. Organizations, even those that hadn’t yet embraced business agility, were suddenly forced to adapt. As we move into year two of the pandemic, organizations that were agile and responsive or that learned quickly how to be agile and responsive have positioned themselves to succeed.

The agile movement grew out of the software development industry. Software developers have the advantage in that they can rapidly modify and test new ideas and make changes on the fly. This is why some of the best system engineers have software development backgrounds, and why many of the modern agile development methodologies grew out of the software industry.

Much has changed in recent years, and now, more than ever, hardware developers need to embrace the agile development of new products for both electronics and mechanical design. Electrical engineers find that much of their work can be done using microcontrollers or FPGAs (field-programmable gate arrays). There are even FPAAs (field-programmable analog arrays) available. This allows for easy changes to basic hardware topologies on the fly.

Mechanical engineers also have modern toolsets, such as the variety of 3D printers. This allows them to try ideas and create new parts daily or even more often if needed. Contract manufacturers also now have to ability to quickly create inexpensive molds to support prototyping. And, of course, both electrical and mechanical engineers now have sophisticated computer modeling tools available, and much of the early product discovery work can be done computationally.

What all this means in practice is that modern agile methodologies developed by software engineers to build better code can now be used by hardware developers as well. Agile methodologies are relatively mature and have been adopted by a significant majority of software engineers. Agile hardware methodologies are a much more recent advance, though not a new concept. Engineers had always tried to design prototypes that gave them flexibility when things didn’t work. But there are unavoidable challenges such as long procurement times for parts or circuit boards and the cost of specialized components that many software developers simply don’t have to address.

“Each sprint moves through a phase of build, design, and test that includes integration into previous iterations, validation that the parts work together, some sort of demonstrable output, and planning for the next iteration”

All of this means that while agile hardware development is possible, it won’t be sufficient to blindly copy existing agile methodologies without accommodating some unavoidable realities of hardware development. However, it is quite possible to develop a product as a series of product increments instead of the traditional waterfall approach. Rather than follow a linear series of events from stakeholder needs – requirements – system design – specification – hardware design – verification – validation, one can treat each of these as a living document and develop them in parallel as the product matures. This acknowledges the very real learning that occurs, especially when developing novel products. While the customer may always be right, the customer may not always know what they want—or at least they often don’t know what is possible, and sometimes the developers have to show them.

A key part of successfully executing an agile hardware development project is planning a series of iterations. Each iteration is designed to help you explore the stakeholder needs and requirements and the limitations of the technologies being applied. What this means in practice is that rather than specifying the final product, the focus is on first defining the problem to be solved and then identifying the first steps—what David Allen would call the next action—to advance towards a solution. This could mean that a computational model is quickly developed to answer some early questions. It could mean a non-functional prototype is made to evaluate concepts and look and feel. Software engineers have used these techniques for years, and there is absolutely no reason not to use them with hardware.

There are key differences that distinguish agile hardware from traditional agile projects. Most of these are due to the nature of the artifacts delivered by hardware projects. One simply can’t avoid the need to know some basic architectural details before getting started. Sometimes this is described as the agile on-ramp, and it acknowledges that software and hardware are fundamentally different in certain key respects.

Details that must be handled in the on-ramp include a merging of the concept of user stories—which are often problematic in hardware development—with product requirements. Some work also needs to be done to address iteration planning. It’s not sufficient to wait for Iteration Two to plan Iteration Two because the changes in hardware might make moving from Iteration One to Iteration Two prohibitively expensive. I like to think of this in terms of road mapping. You have a sense of where you are going, but you don’t know where the roadblocks are going to be.

Despite some differences, once a team moves into execution the agile nature of the hardware development becomes more apparent. Each sprint moves through a phase of build, design, and test that includes integration into previous iterations, validation that the parts work together, some sort of demonstrable output, and planning for the next iteration.

Companies that can quickly develop products that meet customer needs are always going to have an advantage over those that don’t. These changes have been coming for years, starting in the software development industry where more and more new products are being developed faster and faster. This same disruption is now moving into hardware product development, and companies that learn how to leverage a modified agile methodology to support hardware development will ultimately outperform those that don’t.