Can agile be used for hardware?

You probably already know that the answer to this question is “Yes, but…”

After all, software and hardware development are not the same. So it’s not surprising that agile approaches for software teams have never mapped perfectly to the needs of hardware teams. Even still, mechanical design teams have been increasingly borrowing from agile principles and techniques for many years.

Right now there’s more momentum and urgency than ever for hardware teams to move toward more agile ways of working.

At PTC’s LiveWorx 2023 event, MIT Professor Steven Eppinger delivered a timely keynote on Embracing Agile Product Development. Eppinger’s research is about improving engineering and product development processes. In recent years, that’s led him to focus on agile approaches in technical fields outside of software development. As he puts it, agile is “not just for software anymore.”

Drawing on Eppinger’s findings and CoLab’s experience partnering with industry leaders like Ford and Komatsu, this article explores modified agile approaches for hardware teams.

Keep reading for a breakdown on what modified agile means, three types of adjustments you can make, and concrete examples of modified agile in action.

‍

Agile: a brief overview

Ever since the Manifesto for Agile Software Development was first signed in 2001, agile has revolutionized the way software teams build products.

“I believe it’s about to do the same for the rest of engineering,” says Eppinger. “If you’re using agile methods in hardware development, then you’re really at the leading edge of agile beyond software.”

The Manifesto defines a set of four values and twelve principles meant to guide effective and efficient software development. It has spawned numerous specific methodologies, frameworks, terms, and techniques including such familiar concepts as Scrum, Kanban, and Lean. (There’s also a whole industry of agile coaches, consultants, tools, resources, training programs, certifications, and so on.)

‍

‍

Here’s a basic, non-exhaustive description of a typical agile approach:

Work happens in increments, using fixed development periods called time-boxed sprints
Each sprint cycle is 1-3 weeks long and involves a set of repeatable events (daily scrum, sprint review, retrospective, etc)
All work is planned through the backlog, a prioritized list of jobs to do
A product owner manages the backlog and a scrum master facilitates the team and sprint events

Agile’s been so revolutionary, in fact, that the agile philosophy is spreading to nearly every industry and field. In 2021, agile adoption in non-IT lines of business doubled compared to 2020 (Digital.ai). Finance, marketing, HR, operations — everyone is going agile.

Engineering is no exception.

“If you’re using agile methods in hardware development, then you’re really at the leading edge of agile beyond software.”

Despite the complications involved in translating agile approaches from software to hardware development, engineering leaders and researchers have spent years working on how to do just that. As a result, more and more hardware teams have been steadily incorporating an agile mindset into their processes — developing hybrid agile-waterfall frameworks, adopting agile tools, implementing modified agile approaches, and more.

But before we dig into anything tactical: let’s recap the key reasons why engineering teams bother with agile at all, and the key challenges that arise when trying to adopt agile for hardware.

Advantages of agile for hardware

Agile’s overall advantage is that it prioritizes speed-to-value. It gives teams a systematic, repeatable way to break down large development goals into smaller, strategic milestones. Essentially, it helps you strike the elusive balance between enough planning and enough doing.

There are plenty of interrelated benefits that stem from agile practices. Eppinger summarizes these benefits with four adjectives: fast, friendly, flexible, and familiar.

Source: *Embracing Agile Product Development* *(LiveWorx 2023)*

Fast: Because each sprint results in incremental valuable progress, agile delivers value more quickly and consistently over the course of a project. Cloud-native tools have made this even easier and faster with fully digital workflows. As Eppinger points out, “Workflows today are readily supported by tools that just were not available ten years ago.”

Friendly: Agile makes planning practical. Rather than sinking time into extensive detailed planning upfront, agile combines long-term planning with short-term goal setting. From the long-term plan, high-level milestones get decomposed into sprint goals. That way, detailed planning is only required in manageable, short-term bursts for each sprint.

Flexible: Evolving specifications? Disrupted supply chains? Unexpected technical debt? Whatever the situation, agile’s sprint structure creates a development process that’s inherently responsive to constant change, feedback, and uncertainty — which means teams can identify and address issues much more quickly.

Familiar: Your team likely already uses (or knows about) many agile terms and workflows, especially if your company develops both hardware and software. Plus, digital natives make up most of today’s workforce. Remote work and online collaboration are natural for digital natives, but they’re also built-in aspects of agile workflows.

Why designing hardware using scrum is difficult

Of course, even with the clear benefits of agile, it’s not as straightforward as copy-and-pasting agile approaches from software development.

To be blunt: agile development is simply more challenging for hardware teams than it is for software teams. David Ullman, an internationally recognized expert on product design and decision-making best practices in engineering,outlines 13 challenges that arise when applying scrum to hardware design:

Modularization is more challenging for physical products
Difficult to develop hardware in short sprints
Hard to add features to finished hardware
Hardware is more difficult to simplify
Hardware needs more specialization
Demonstrating function takes longer for hardware
Changing hardware costs more
Hardware must work over a range of time and environmental conditions
Software testing differs from hardware testing
Developing hardware requires ancillary systems not needed for software
Software and hardware requirements differ
Demonstrating, prototyping, and testing are often more difficult for hardware
Scrum encourages a build-measure-learn process, which is poor hardware design practice

‍

Despite the challenges, there’s a reason hardware development is still trending steadily toward agile methods. Through ongoing research and real-world applications of agile in hardware, solutions to these challenges are emerging all the time. And as cloud-native software continues to evolve, it’s pushing the shift to agile into high gear with more and more tools designed explicitly to align with agile workflows.

So let’s dig into some of the specific ways hardware design teams have adapted agile to work for them.

‍Modified agile for hardware

The shift to agile is inevitable at this point. Since we know it’s happening, and we know agile doesn’t quite work “as is” for hardware development — modified agile is the natural solution.

“There are no agile police.”

“We don’t need to apply agile all in the same standard way,” emphasizes Eppinger. “There are no agile police telling us, well you have to do it this way because that’s the way it works in software. Instead, there are many ways to apply agile, because your process and your challenges may be quite unique.”

In fact, you can already find information out there about modified agile for hardware. For example, product development consultants Dorian Simpson and Gary Hinkle created a Modified Agile for Hardware Development (MAHD) Framework to apply agile principles to hardware projects. The more you look, the more you’ll discover other hybrid and modified approaches, as well as research into their effectiveness.

But just like there’s no one, single way to apply agile — there’s no one, single way to apply modified agile.

For some teams, the best way to start implementing modified agile is by applying it to Stage Gate product development. While still using Stage Gate to reduce risk, you can introduce agile ways of working within each Stage. (Keep reading for examples of this.)

‍

*Source:* *Agile vs Waterfall: Which Method is More Successful?*

No matter how you decide to be more agile in your hardware design processes, it’s all about finding an adjusted approach that works for your team. As long as you have a strong understanding of agile’s core principles and values, you can use these adjustments to calibrate an agile approach that supports your specific business goals and needs.

In fact, Eppinger stresses this finding above all others. Although some elements of agile are easy to apply without adjusting (e.g. daily meetings), others “can and should be” adjusted.

As he puts it, “People ask, what have you learned by studying all these different kinds of companies applying agile outside the software industry? What’s the key to success? Well I can answer in this one word: adjustment.”

So let’s look at three types of adjustments that Eppinger recommends for hardware teams.

Three ways to adjust agile for hardware

You may have your own specific adjustments in place or in mind to adapt agile to your team and processes. That’s good! As mentioned, there’s no right or wrong way to modify your agile approach.

But if you’re not sure how to go about making adjustments, these three broad types are a great starting point.

‍

1. Sprint cadence adjustments

Sprint cadence refers to the timing and pace of sprints. Classically, agile has been associated with 1-3 week sprints. While this works well for software development, the timeframe is less well-suited for hardware.

For agile hardware development, Eppinger recommends using longer sprints.

“Most software teams are actually fine with one-week sprints. But that’s just too fast for teams in other types of projects to make meaningful progress,” he points out. “Even if the software teams are using one-week sprints, the hardware teams can do something different.”

Another way to adjust sprint cadence for hardware is by using different types of sprints.

For instance: you may want to alternate between two sprint types, such as development sprints and operational sprints. The sprint types could rotate on an equal basis (like every other week), or you could allot different time periods for different sprint types.

Technology-based clothing company Ministry of Supply uses this strategy, rotating between development and operational sprints every other week. During the operational sprint, the team takes care of things like supplier visits, market launch support, and performance reviews. That way, there are no distractions while they’re focused on the development sprints.

‍

2. Sprint goal-setting adjustments

Agile was essentially born as a solution to the pitfalls of long-term planning, and it’s been quite successful in addressing those pitfalls. The trouble is — the long-term picture can’t just be ignored.

That goes double for hardware development.

So Eppinger suggests agile hardware teams do slightly more long-term planning than agile software teams.

In software, sprint goals are basically a set of features, functions, and bugs that get prioritized from the backlog for each sprint. In hardware, the sprint goals are progressive increments toward the final development goal or overall strategic goal. That means the sprint goals get mapped out upfront during long-term planning.

Once you identify the major, long-term milestone you’re trying to achieve in this development, you can work backward from there.

“Let’s say we want to have a product release in Q3 or we have a trade show in Q1, and we want to hit that milestone,” describes Eppinger. “Then they decompose the milestone into smaller ones, and then finally into a series of sprint goals. So they ask something like: in order to deliver this product release in Q3, what does it look like to be halfway there? And they have a date for that. And what does it look like to be 25% or 75% done? Then each of those goals is achieved as a series of several sprints.”

This type of systematic goal-setting is key to making agile work, especially for complex systems like robotics.

‍

3. Sprint outcome adjustments

Typically with agile for software, the ideal outcome of each sprint is a “releasable” increment of work.

“You’ve probably heard that software teams aim to deliver usable code in each sprint,” Eppinger explains. Although he says they “only sometimes do that,” frequent releases aren’t unrealistic for software. On the other hand, “Hardware development teams are not likely to be releasing a new hardware version into the field every couple of weeks.”

For hardware teams, Eppinger recommends aiming for a reviewable increment of work in each sprint.

Instead of expecting to produce something releasable within a short timeframe, think about what you’ll cover during the sprint review. (See examples below.)

What does the sprint outcome need to be, for it to be sufficiently “reviewable”? This is also a good chance to consider the type of design review you need at this stage, and the specific purpose for the review.

“This one’s more of a change of mindset,” says Eppinger, but one that’s “super helpful.”

Examples of modified agile

Okay, so what does modified agile look like in practice? What are some of the specific ways hardware teams are adjusting agile development to their needs?

Let’s look at a few examples.
‍

Different sprint cycles for hardware and software teams

Changing sprint length and cadence is one of the most straightforward ways companies can adapt agile for hardware. Just because the software team has a 1-week sprint cycle, doesn’t mean the hardware team has to conform to the same timeframe.

Eppinger gives the example of a Ford Motor Company project that had software teams stay on their 1-week cadence, while the hardware teams switched to 3-week sprints. Then software and hardware teams would come together every three weeks for a joint demo.

“One particular advantage for the hardware team: if they discover something in their sprint where they need something from the software team, they can ask them for it and maybe the software team adds it to their backlog for the next sprint,” remarks Eppinger. “Then before the hardware team is finished their sprint, they’ve got that useful input and they can actually use it right within their next 3-week sprint.”

‍

Breaking sprint goals into reviewable increments

Although it’s less straightforward than adjusting sprint cycles, getting comfortable with the concept of reviewable increments is a big power-up for engineering leaders.

That’s because this type of agile modification requires developing the right mindset. But once you get there, you can look at the product development process through a new lens — which means you can spot creative or innovative ways to break things down into highly effective sprint goals.

Bose uses prototypes in their product design process for consumer wearables. During a development sprint, the team will use a prototype to focus on a particular feature or aspect of the product. It won’t be released at the end of the sprint, but as Eppinger says, “It’s something we can review, we can test, we get feedback, and it leads to the next development sprint.”

Alternatively, global packaged foods company Sigma sets different functional goals for each development sprint. “These are things like extrusion tests, baking results, packaging design, reviews of taste and texture,” comments Eppinger. “So the reviewable increment is the sprint goal. This is what we would then demonstrate and assess in the sprint demo and in the sprint review at the end of each sprint.”

‍

Rethinking design freezes

Another way to think about modified agile is by adapting other methodologies and processes to become more agile.

In a waterfall methodology, Stage Gate processes typically have one design freeze at the end. However, shifting toward smaller freezes within each stage is better aligned with agile approaches.

Realistically, this is already common within new product development. Eger et al examined design freezes in NPD in a paper for the International Conference On Engineering Design. “Stage-gateway processes usually depict a single point for design freeze,” they write. Yet, “Product parts are rarely totally fluid until they are suddenly fixed at a freeze point.”

In fact, factors like lead times and part dependencies mean that some parts of a design need to be frozen before the final freeze.

‍

*Source:* *The Role Of Design Freeze In Product Development*

‍

“When key parameters are frozen, dependent design can be finalized. For long lead time items, the lead time governs the point of part freeze,” Eger et al explains. “The design process can be structured by the freeze order of the parts. A design order based on part freezes evolves. It can be used for planning the detailed design phase and reducing the risk of rework. If the design process consists of many phases and tasks that overlap, then freezes can set preliminary information as the basis for further work.“

In other words: thinking about “the freeze order of the parts” can help determine how you might break down your product development process into agile-friendly chunks.

How agile mechanical teams can use CoLab

Agile is tool-agnostic, and always has been. But certain cloud-native tools are closely aligned with agile development.

For example, many people associate Jira with agile in general. Since it’s popular with software teams, some teams also try using Jira for hardware development. While this can be a step in the right direction compared to Excel-centric workflows, mechanical teams don’t need to use Jira to be aligned with their agile counterparts on the software side of things.

Unlike Jira, CoLab is specifically built for mechanical design. It’s a cloud-native collaboration tool that lets engineers set up agile workflows for sharing and reviewing designs (even in 3D!) with any stakeholder, all within your web browser. It’s better-suited for hardware teams, yet still plays well with Jira — so that your software and hardware teams can collaborate seamlessly across systems.

Why is that so important for agile?

“Agile depends upon close collaboration within teams, and also across teams,” notes Eppinger. “Collaboration today is based on certain types of tools, largely cloud-native tools.” While Eppinger acknowledges that cloud and agile are “not directly linked,” he does view them as “highly complementary.”

“Frankly, this way of working was just not possible even 10 years ago.”

“The interesting thing is you can implement agile, without cloud. We’ve been doing that for a long time,” he continues. “But the reality is that teams today are working less in a co-located fashion and more in a distributed fashion. We’ve seen a big transformation in that, particularly over the last few years. And cloud-based tools are ideal for remote work, and for teams that are distributed across time and space.”

CoLab supports agile hardware development for a number of use cases, and in a number of ways:

Requesting a review is fast and simple, so designs can be reviewed early and often without any extra admin work (like building complex PowerPoints, scheduling meetings, endless email chains, etc)
Asynchronous collaboration is more effective because feedback and design files are centralized, with comments and revisions updating for everyone in real-time
Using CoLab lets you standardize collaborative workflows while providing novel data and insights you can use to continuously improve your design review process

‍

‍

“Frankly, this way of working was just not possible even 10 years ago. Even 5 years ago, the tools were just only starting to get really good,” Eppinger admits.

However, as cloud technology has quickly become the standard for effective collaboration, he points out that “many of the young folks you hire today are going to be agile-ready when they join your workforce.”

“I really believe that we’re on the cusp of this huge wave of agile adoption beyond software,” stresses Eppinger.

“Your first agile sprint will feel a little bit awkward. By the time you’ve done five sprints, or ten sprints, you actually get really good at it. It becomes normal. It becomes a process that you’ll like, you’ll use — and you’ll never go back.”

Survey of 250 engineering leaders

Agile for Hardware Development

How mechanical design teams can implement modified agile