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.
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 code. Only coding time is lost. Redesigning physical features and functions is usually much more difficult and expensive than rewriting code.
In a sense, rewriting code is the software road to product maturity. Hardware matures from concept to product, and then from the product’s first version to later versions that have more performance, lower cost, longer life, and so on.
Hardware improvements are enhanced with careful definition of the product’s modules and interfaces. The more a product makes use of plug-and-play assemblies and components, the easier it is to improve individual modules, and the more the product can be redesigned.
Hardware Needs More Specialization
In Scrum, team members can “swarm” to resolve problems, keeping each sprint on schedule. For software, a person who codes Function A can probably code Function B and, if help is needed, to complete it. For hardware, expertise is not universal across functions. A person who designs a heat exchanger probably has no experience designing gear trains or printed circuit boards. Although software assignments can often be made daily, at Saab and other hardware companies, engineers are often assigned to tasks that match their expertise during sprint planning.
Hardware need specialization, which creates bottlenecks.
If only one person can do X, and three teams need X done, there may not be enough time for each to get finished, and the Scrum concept of stable teams falls apart. Additionally, specialization is fragile because, if experts quit or become ill, their capabilities are lost. To counter specialization, many companies that cannot afford to hire many people with deep expertise try to spread the knowledge by having experts train others to do much of the lighter work and only use experts for critical deep problems when necessary.
Demonstrating Function Takes Longer for Hardware
Code can be rapidly written and compiled. Designing and building hardware take more time. Additive manufacturing (aka, rapid prototyping or 3D printing), virtual reality (VR), augmented reality (AR), and computer modeling are reducing the time needed to manufacture functional hardware.
Changing Hardware Costs More
The costs for changing hardware climbs as the project progresses. As the hardware design progresses, costs are committed that cannot be recovered (see figure below). Not only is the cost of salaries and time lost, but tooling, inventory commitments, and other sunk costs are lost when changes are made after a certain point. The cost of changing software is only the cost of programmer time regardless of when it is done in the development process. This difference is hard to overcome and is a reality of life for hardware. The iterative nature of sprints with goals of “done enough for now” forces managers to consider the need for change early on and keeping it under control.
Hardware Must Work Over a Range of Time and Environmental Conditions
Software does not bend or fatigue, nor does it care if it is cold or hot. It does not care if the environment is clean or dirty. It does not care if the user is a small woman or an NFL lineman. Most hardware needs to work over a wide variety of environmental conditions. Software does not.
However, software cares what machine it runs on and what operating system is used, and often has difficult legacy issues (e.g., version 2 must process data from version 1 while adding new functionality). Thus, software and hardware both have “environmental” issues, just not the same ones. Software compensates for these variations with more code, whereas hardware may require significantly different systems.
Software Testing Differs from Hardware Testing
Testing is an effort to reduce risk by proactively finding and eliminating problems that can affect a product’s usability or reliability. Software testing usually includes thousands of test cases, so programmers write specialized code to root out potential problems. Software is tested by designing more software.
Hardware usually requires fewer test cases, but with more specialized and expensive equipment. This testing equipment itself may be designed and built as part of the project. For example, the test fixture for verifying the strength of the Boeing 787 wings was a major design project itself.
Regardless of whether designing software or hardware, Scrum encourages test-driven development (TDD). TDD forces the definition of the acceptance tests during the definition of each task. In other words, describing what is necessary to prove that a task is done, before the task is begun.
Developing Hardware Requires Ancillary Systems Not Needed for Software
Hardware design not only requires the design of the product, but also the design of the manufacturing process, the assembly process, the test equipment, the QA/QC procedures, the supply chain, and all the supporting documentation. For software, writing code is the manufacturing process that generates the product, there is no supply chain, and the documentation is generally simpler than for hardware systems.
One approach for managing the complexity, in either case, is to bring all these issues into the design team and have people who can design all the ancillary systems on it.
For physical products, it is well known that when manufacturing engineers are on the design team, the resulting product is easier and less expensive to manufacture. It is also well known that you can’t inspect quality into a product, so having the team design quality management into it is critically important. Finally, it is far easier to document a product as it is being designed than after it is finished. All these factors encourage having people on the design team who can address tasks focused not only on the product but also on manufacturing, testing, quality, procurement, and documentation.
Software and Hardware Requirements Differ
Developing and managing hardware design requirements is different from software requirements[i]. Software requirements are generally based on “user stories” that capture the voice of the customer. Hardware design requires refining the voice of the customer into measurable engineering requirements. Methods like Quality Function Deployment (QFD, or House of Quality) are specifically designed to support this translation.
Additionally, there is a tension between how much effort to expend developing the requirements upfront during product planning and how much should be on the fly, during product development. Those developed upfront are often changed during development as more is learned while those developed on the fly can lead to feature creep and a product out of control.
While QFD aids in developing needed engineering specifications, it is an upfront planning tool. User stories are helpful but not sufficient during the design process. The challenge is to find the balance and use both upfront planning and on-the-fly stories to capture and manage requirements.
To establish needed functionality and to counter feature creep, set both the software and hardware high-level requirements in advance. The Saab Gripen E fighter was well defined years before it was completed. In fact, the Gripen E fighter has only about 300 system-level requirements. Of these, for example, about fifteen apply to the oxygen system design team (shown below). The Oxygen system manager has seven teams with about 40 engineers under him working to meet these requirements. During their efforts, they develop many sprint and task level requirements (see Challenge 2).
Demonstrating, Prototyping, and Testing are Often More Difficult for Hardware
Working code is easily tested by customers, even globally, over the internet. Hardware is not. It is undoubtedly true that many hardware issues can be addressed quickly with CAD models and that rapid prototyping and printing (additive manufacturing) have significantly reduced the time it takes to produce a physical prototype. It is also true that virtual reality and augmented reality will further improve the ability to experience an evolving product. However, when these technologies are not sufficient, there may be lead times on materials, manufacturing, and test facilities that make product demonstration difficult. (See Challenge 2 for more on how to manage this difficulty.)
Scrum Encourages a Build-Measure-Learn Process, a Poor Hardware Design Practice
The build-measure-learn action sequence is what we naturally do when faced with a problem. Watch any child learn a new skill. They will try something, watch it fail, and through the failure, learn enough for the next cycle. The adage “fail early, fail often” has real truth to it. However, this process can lead to poor decisions and a premature commitment to a weak concept if not done carefully. History is littered with instances where early builds, with poor measurement, have led to erroneous learning and a lot of wasted time.
Although build-measure-learn is a good process, take care in the development of requirements and concepts. When designers build without understanding the high-level requirements or how they are going to measure and learn, they are hacking or, in software lingo, writing “cowboy code”, not doing engineering design. When designers commit too soon to a concept and start to build it, they are often wasting time and resources.
There is good reason why Scrum methods are so popular with software designers. However, there are challenges when applying these methods to hardware. They are challenges, not impossible hurdles. We will see increasing use of Scrum for hardware with specific attention to these 13 challenges.
Scrum 101
Scrum is an agile methodology based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project as done in the sequential waterfall method (aka stage-gate), the agile process is open to changing requirements over time and encourages constant feedback from customers. A Scrum project is broken into two- to three-week sprints of work followed by a design review and a team retrospective focused on improving the process. It is more fully described in a recent Machine Design article, “Scrum for Hardware and Systems Development”, May 29, 2019. For more book’s from Ullman on the design process, click here
David G. Ullman is a product designer who has taught, researched, and written about design for over 35 years. He is an emeritus professor of mechanical design at Oregon State University. He has also written The Mechanical Design Process and other design books. His website, with details on his research and publications, is at www.davidullman.com.