Agile Hardware DevelopmentCan 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 StudyKevin 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.
- 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 RecommendationsIt’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