Since the early 2000s, Agile Software Development has exponentially gained popularity—while hardware manufacturing has largely been left out of the party. But like any good party, word gets out. So, today, manufacturers are starting to ask, “How can Agile apply in hardware development?”
Although well-intentioned, that question assumes manufacturing should adapt Agile for hardware product development. But force-fitting software principles and practices into hardware could likely result in a mixed bag of impractical or awkward methodologies. A more useful question is: “Which drawbacks of hardware product development could be alleviated with practices inspired by Agile?”
What Is Agile With a Capital A?
According to the Agile Alliance: “Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto. Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context.”
These values and principles provide the philosophical framework for specific software-development methodologies, such as Scrum, the most popular Agile methodology. In Scrum, teams of five to nine people complete prioritized product-backlog items in iterations called “sprints.” These backlog items can be features, scenarios, stories, and so forth, and a sprint is typically two to three weeks. At the end of each sprint, the team has to release something, demonstrate the release to the customer, and gather feedback.
The Traditional Process
When considering Agile ideas for hardware, it’s helpful to start by looking at the traditional hardware-development process (also known as “waterfall”)—in this case, an example detailing the development of a package-delivery drone, inspired by the Amazon Prime Air Project.
The most basic requirements for this drone are: It should be able to deliver packages up to 5 pounds within a 10-mile radius in 30 minutes or less (from order to delivery); it should be safe and comply with government regulations; and it should notify both the seller and the customer of the delivery status.
For a team following the waterfall model, the drone-development process is largely linear. Each phase starts only when the previous one is completed: Design > Make > Use. The detailed product specifications—the requirements and regulations the product must meet—are defined at the beginning and fed into the Design phase, when alternatives are generated and analyzed. The selected design is input to the Make phase, in which product fabrication is planned and executed. Deploying the final drone to the customer initiates the Use phase, which includes drone operation and service.
In reality, this strictly linear process is rarely followed. Rather, teams often follow a more circuitous process, in which some iteration does occur—with opportunities for customer feedback, but only within a given phase. For example, the drone may go through several iterations during the Design phase, and various fabrication options may be considered during Make. This is an improvement to the linear model, but it’s still waterfall (or what some call “Scrumfall”).
In any case, the waterfall approach has three significant drawbacks:
1. It assumes that requirements don’t change. Waterfall relies on a predictable process that can be planned and executed without many adaptations or surprises; customer requirements are frozen at the beginning of the project. The assumption that requirements won’t change is, of course, almost never correct. New technologies, discoveries, and market fluctuations are bound to introduce changes.
2. It goes too long without customer feedback. Here, most of the customer interaction is front-loaded, when the team is capturing requirements. Once the product-specification document is completed (and frozen), the team gets to work. But customers rarely know exactly what they want at the beginning of a project, which is a recipe for building the wrong thing, at the wrong price, and at the wrong time—even if the original specs are met.
3. It requires too much thinking without building. A waterfall-driven design is pretty much locked when the project moves from Design into Make. This is problematic because the team will probably learn things during Make that may impact the design, and the customer hasn’t seen anything “real” before the design is locked. And changes on a locked design are difficult and costly to make.
Now, consider those drawbacks in the context of the drone example: A few weeks into the project, the customer learns that a competitor is developing a drone to deliver 10-pound packages in 20 minutes. By now, the customer’s design is “done,” and the team is in the middle of the Make phase. Changing the requirements to match the competitor’s would mean redesigning the drone’s structure, rerunning all the certification analyses, redoing the fabrication plans, and more. Yikes!
Also, the team assumed the drone should be able to deliver packages of various shapes. But when presented with five design alternatives—which had already been generated, simulated, and rendered—the customer revealed that it delivers packages inside waterproof containers of fixed size. That’s a lot of wasted time and resources due to lack of customer feedback.
And finally, during the Make phase, the designers realized that they could 3D print the structure by making some changes to its shape, potentially even using generative design. 3D printing the structure would reduce weight and assembly time, but it would also require lots of costly changes to locked design content. Strike three for waterfall.
An Agile-Inspired Process
Considering these drawbacks, it’s important to resist the temptation to “apply” Agile wholesale to hardware development. Instead, a few Agile practices and principles (mainly from Scrum), adjusted for hardware, could make a lot of sense:
1. Sprint iterations. Sprints could arguably have the most positive impact in hardware product development, as they force teams to go through Design-Make-Use cycles earlier, faster, and for smaller slices of the design. Progress is made left to right. Sprints address all three waterfall drawbacks: They prevent teams from going down the wrong path for too long; they shorten the time between “thinking” and “building”; and they provide opportunities to revise requirements based on learnings from each sprint.
Another advantage is the flexibility to schedule critical design decisions later in the project. In the waterfall model, all design decisions are made in the Design phase before moving on to manufacturing. In contrast, an Agile-based team can delay some decisions until after several sprints, when they’ve gathered significant information.
2. No static product-specification documents. Instead, requirements are captured in the prioritized product backlog items. They should be valuable, actionable, sized to be deliverable in one sprint, negotiable, and testable. They should also capture the who, what, and why. Instead of asking, “What do you want your product to do?” (resulting in a flat list of requirements), ask, “What do you want to do with your product?” (resulting in verifiable use cases).
3. Collaborative teams. Agile fundamentally redefines the structure and roles of the product-development team. Instead of teams organized by departments (design, analysis, production, and so on), Agile advocates for small teams that are cross-functional, self-organizing, self-managing, and collaborative. A team assumes the responsibility to complete a product backlog item in a given sprint. A Scrum team, for example, is only a Product Owner (owns the what); a Scrum Master (manages the process; and the Development Team (does the work).
4. Smaller deliverables throughout the process. Opponents of using Agile in hardware argue that, unlike software, it is not economically and practically feasible to build something for release at the end of every sprint. This misses the point: Physical deliverables are not the only way to make incremental progress. Computer simulations, virtual-reality demonstrations, digital twins, and conceptual prototypes are all valuable deliverables. The key is to slice the product-backlog items so that the teams can release something meaningful at the end of each sprint. Items could be sliced in many ways—for example, by level of fidelity (from rough to final), by level of virtual vs. physical content, or by user roles.
Agile in Practice
The drone team’s problems with the waterfall model could have been prevented with Agile-inspired practices: First, the design impact due to the change in the requirements could have been minimized with smart sprint planning, dealing with structure later in the project. Second, the (wrong) assumption that the drone handle packages of various shapes could have been discovered and corrected earlier. And third, the realization that the drone structure could be 3D printed would have come much earlier.
Sounds great, right? Yes—but Agile is not perfect. Its practices can go terribly wrong if not executed properly or applied where they don’t make sense. However, using sprints, following stories instead of specs, and empowering teams are great starting points toward making hardware product development more Agile.