Agile Hardware Development

Can an Agile process be used for hardware development? Would it bring to hardware development the same benefits it does to software development?

Suspecting that the answers to both questions were “Yes,” but unsure of the details, cPrime partnered with TCGen to investigate. We were confident that the combination of cPrime’s Agile expertise, and TCGen’s expertise in hardware product development, would enable us to answer these questions.

What we found was fascinating, and unexpected.

The Study

Kevin Thompson (cPrime), John Carter, and Scott Elliott (TCGen) began meeting in late 2013 to develop a questionnaire about the use of Agile practices in the development of electronic hardware such as networking devices, flash memory, semiconductor manufacturing and test equipment, and so forth. We conducted interviews with 14 people in mid-2014, and spent months analyzing the results and developing our conclusions.

We discovered that different companies were using different Agile techniques to some extent, although none of the companies had a formally-defined Agile process as such. For example, we discovered that companies engaged in rapid development of circuit boards through iterative prototyping, division of product-development cycles into time-boxed Sprints, tracking with Burndown charts, and frequent integration and integration testing of components.
We identified these key differences between hardware and software products:

• Software is more malleable (easier to change) than hardware. The cost of change is much higher for hardware than for software.
• Software products evolve through multiple releases by a process of accretion and refactoring (adding new features and re-writing existing logic to support the new features). Hardware products consist largely of physical components that cannot be “refactored” after manufacturing, and which cannot “accrete” new capabilities that require hardware changes. Designs for new hardware products are often based earlier-generation products of similar type, but commonly rely on next-generation components that were not present in earlier generations of the product.
• The design for a hardware product is driven in large part by architectural decisions. As the cost of change is high, more of the architectural must be done up front compared to software products.
• The cost of development for software products is relatively flat over time (aside from the usual hiring and attrition), but rises rapidly towards the end of the development cycle for hardware products.
• Due to many of the above factors, it is possible to make major changes in direction for a planned software-product upgrade in mid-development, without massive disruption and waste. Attempts to make such changes in hardware development come at a much higher cost, in terms of sunk costs wasted, and shipping schedules postponed. As a result, major changes must either be deferred to a future product upgrade, or are done when an assessment is made that the impact is justified by the magnitude of the benefits.

On the other hand, we also identified these similarities between hardware and software products:

• They have behavior: Users interact with the products in various ways, products interact with other products, and products produce outputs given inputs
• They have functional (user-facing) and non-functional (non-user-facing) requirements
• They are complex, and any representation of product specifications invariably leads to a tree structure as major features are decomposed into finer-grained features

 

The Recommendations

It’s no news that Agile software projects add usable functionality to a product in small increments over time, in order to create major new releases. It is probably not surprising that hardware projects generally cannot work in this mode, as the product is not usable in any meaningful fashion until its design is complete. This difference might seem to doom efforts to apply Agile concepts to hardware development, but the difference is less significant than it appears.
The key characteristic that both worlds share is more important than all of the differences:

• The work of the development cycle can be divided into a large number of small and testable deliverables

For software products, the flow of deliverables is such that new and usable features appear steadily over time, and these features are aggregated into a newly-released product. For hardware products, the flow of deliverables generally does not produce a steady flow of usable features over time, and the product features become usable late in the development cycle. However, the deliverables can still be developed and tested throughout the cycle, and this is the key point. This point enables the continuing scope adjustment and refinement needed to hit planned shipment dates with the best possible value. More specifically, it enables, and we recommend, a Scrum process.
An example of the overall flow of development, for hardware product that contains a software component, is illustrated in the figure:

 

The standard Scrum practices apply throughout. Each Team has a designated Scrum Master, Product Owner, and set of Team members. The usual “Scrum ceremonies” of Backlog Grooming, Sprint Planning, Daily Stand-Up, Review, and Retrospective are held.

The overall structure is that of a Release Cycle in Scrum, which is composed of a set of Sprints. The hardware Sprints are twice the length of the software Sprints (four weeks, versus two), because hardware deliverables generally cannot be decomposed into pieces as small as can software deliverables. Sprints boundaries are aligned to better enable collaboration across Teams.

The product is complete at the end of the Release cycle, which means that the software is ready for production, and the design of the physical hardware is ready for manufacturing. While integration and integration testing are done throughout, we reserve the last “Hardening” Sprint for final integration testing, and other activities, that cannot be done earlier. No product-development work is done during this time.

Hardware and software development both requires some design work, but the hardware work has both a higher cost of change, and less flexibility (due to the available pool of components), and so more of the design work is done up front, relative to the software-design work. The latter tends more towards a “Just in Time” model of small design increments, done only when needed.

While the day-to-day experience of software development is very similar from one Sprint to the next, this is not the case for hardware development. The hardware work progresses through qualitatively-distinct phases, as illustrated in the diagram. Thus while the hardware Teams continue to build and test deliverables in Sprints, the nature of those deliverables commonly changes over time.

Conclusion

Much more can be said about Agile hardware development—and will be—but the basic point is clear: The Scrum process fits hardware development well. For more details, keep an eye out for our forthcoming white paper on Agile hardware development, which will provide more extensive guidance on just how to develop hardware in an Agile way.

For more information on Agile Hardware, contact us , or download the full paper here: