About this White Paper
Agile Processes for Hardware Development presents a practical approach to applying Scrum to hardware and hardware-software product development. The paper begins with a fundamental question: Can an Agile process designed primarily for software development work effectively for hardware? Based on research involving fourteen companies developing hardware, software, and combined products, the paper concludes that Scrum is well suited to hardware development, although several aspects of the process require careful adaptation.
The paper examines the important similarities and differences between hardware and software development and their implications for Agile process design. Hardware has a higher cost of change, longer component lead times, architectural constraints, specialized testing requirements, and multiple parallel development activities involving the product, manufacturing, testing, and supply chain. These characteristics affect how teams plan and execute their work, but they do not prevent the use of an iterative Agile process.
The paper then defines a comprehensive Agile process for hardware development. It covers Product Backlog Items, User Stories, Technical Stories, Epics, Sprint Planning, Backlog Refinement, Sprint Reviews, Retrospectives, estimation, velocity, Release Planning, Scrum-of-Scrums meetings, Release Reviews, Release Retrospectives, and tracking and metrics. Particular attention is given to Release Planning, which the paper argues is essential for hardware because hardware development normally cannot be completed within a single Sprint and because the cost of changing hardware scope is substantially higher than for software.
A central distinction is that Agile hardware development does not necessarily produce a steadily increasing stream of usable product features in every Sprint. Instead, Sprints can produce and validate design deliverables, prototypes, and other increments of learning that contribute to the eventual product. The paper explains how Sprint focus can evolve during a Release cycle while retaining the iterative, testable nature of Agile development.
The final section provides a detailed worked example of an Agile hardware project: the development of a fictional cardiac monitor. It walks through product definition, team structure, high- and detailed-level specifications, Release Planning, regulatory considerations, and the evolution of scope and work during the Release cycle. The example illustrates how the process can be applied to a complex hardware product containing both hardware and software.
The paper concludes that an Agile process for hardware development can look remarkably similar to Scrum for software while accommodating the distinctive sequencing and physical constraints of hardware development. It has subsequently been updated to incorporate lessons learned from client engagements.