27 Dec 13 Challenges When Applying Scrum to Hardware Design
Scrum has become a popular method for developing and designing software. And why not? There’s clear evidence it improves the resulting software’s quality, shortens time to market, and even increases team members’ job satisfaction.
The obvious question, then, is why isn’t Scrum used more widely for designing hardware? It can and should be, and is having success similar to what it has earned developing software. But, Scrum for hardware design—designing mechanical devices, PC boards, and everything else that is not software—is more challenging than designing software.
This article lists 13 challenges that make it more difficult to use Scrum for hardware development and suggests ways to overcome them.
Making Hardware Modular
Software teams have long understood that modular architectures limit the ripple effect of changes. In software, modular architectures allow an application to be broken into chunks of code, each of which provides a small set of functions. Changes in one module rarely effect another module. Therefore, modules can be developed as practically independent design tasks.
In hardware, form and function overlap, making modularization more challenging. When one module is changed, other modules that work with the changed module to create a function might also have to be updated. These effects can largely be controlled by designing around known, stable interfaces between modules. As the design matures from constraints to configurations, to connections, and finally to components, interfaces can be designed that separate, as best as possible, the form-function interrelationships. This design philosophy forces product configuration or architecture to be established early, effectively defining functional modules. To accomplish this, connections or interfaces between modules need to be designed first. These become the known, stable interfaces between modules.
For example, Saab, during the design of its JAS 39 Gripen E fighter aircraft, used Scrum for hardware design. They overcame the modularity difficulties by focusing on the interfaces early in the process. The aircraft design effort was divided into teams aligned with the project organization. As the design progressed from concept to detailed design, teams worked almost autonomously within known, stable interfaces.
The trick is to define interfaces and make them as simple and stable (i.e., unchanging) as possible. This lets the design efforts proceed independently on both sides of the interface. Later, the interface can be redesigned if needed as a separate project or as part of the ongoing Scrum activities. Making modules plug-and-play with known stable interfaces is a goal encouraged by the Scrum framework.
Difficult to Develop Hardware in Short Sprints
The ideal goal of each two- to three-week sprint in the Scrum method is “a potentially shippable increment of product functionality.” This goal is difficult to achieve in software and even more challenging in hardware. In fact, many software groups set more modest-yet-demonstrable acceptance criteria for each sprint that are not actually shippable. Setting realistic acceptance criteria for each sprint task is key to using Scrum to design hardware design.
Software development grows by combining small functional sections over time. Hardware often cannot follow this path. It is more commonly built out of components and assemblies that address specific features and functions. Thus, the goal of a hardware sprint may not be a functional but may focus on designing a component or assembly.
Scrum success depends on setting realistic sprint goals. Where the goal is a shippable increment, the reality may be the team demonstrating that “we understand the question,” “we have a demo of this function,” or “we have a working prototype of this feature.” The challenge is to write sprint goals with acceptance criteria that say “We have done enough for now.” In other words, the goals should describe small bites that lead toward “a potentially shippable increment of product function” that can be completed during the sprint. One approach is to identify the minimal viable product (MVP) for the current stage of development and work toward getting that product completed in the current sprint cycle.
For example, a sequence of three-week sprints for a specific module might show the task goals for each sprint, as shown below.
Hard to Add Features to Finished Hardware
Software products evolve through a series of releases, each adding new features. The functional independence of software modules makes it relatively easy to add and subtract features to meet changing requirements. This is seldom possible during hardware design because adding functions may can cause unintended consequences due to the interactions between form and function. In fact, “feature creep” (adding new features during the design process) can be fatal during hardware development due to this interaction and cause costs and delivery dates to spin out of control.
If a team tries to design hardware simply by adding features, it can end up with nail clippers such as those shown below. Clearly, adding ever more functions will only result in a worse mess.
The Mechanical Design Process, 6th Ed.
Hardware is More Difficult to Simplify
If a particular algorithm used for a software function is inefficient, it is not expensive to rewrite and update the…