Skip to content

Why Agile methods don’t work for hardware projects

Agile methods have made significant improvements to the software development process over
the last two decades. And now, many companies have tried to apply the same methods to their
hardware development process but were unable to achieve the same benefits. That doesn’t
mean that none of the Agile methods work; it just means some of them need a bit of
modification. So first we’ll look at the differences and challenges, and then we’ll identify the
methods that do work and how to modify them.

A screenshot of a Playbook project management interface showing a weekly schedule for team members Bob, John, Mary, and Sue. The view displays tasks allocated across three days—September 3rd (Tuesday), 4th (Wednesday), and 5th (Thursday)—including colored task blocks with titles such as “Design Prototype PCBA,” “Document/Distribute FEA Results,” and “Define Housing/Faceplate/Cover Interfaces.” The schedule includes time estimates and task colors indicating different categories or priorities, with progress indicators and icons for each time block.

  • Longer cycle times

    Hardware development involves complexities that are fundamentally different from software development. Unlike software, where the build-measure-learn cycle can be executed relatively quickly, the same cycle often requires significant time and resources in hardware development.

    Each iteration can entail costly and time-consuming procurement of the materials, assembling the components, and conducting the tests. This makes the iterative approach less efficient and more burdensome in hardware contexts.

  • Complex dependency management

    Software architecture can be complicated, but the dependencies aren’t usually as complex as they are for hardware projects. Agile’s focus on flexibility and adaptability doesn’t align well with the interdependent nature of hardware development, where delays in one area can affect the entire project timeline.

  • Homogenous vs functional teams

    Software teams can have people with multiple skills, but they generally have similar backgrounds and work tasks when compared to hardware teams. Therefore, a software team often has more than one person who can complete a task. On the other hand, hardware teams usually consist of people with a wide variety of skills who are from multiple departments. So most of the work can only be done by one or two people on the team. This means delays may occur while one person has a lot of work to do and everyone else is caught up but unable to help the overloaded resource.

  • Planning isn’t necessary

    Agile methods were developed because the traditional methods of project management were not working—the time between customer feedback was too long. So detailed planning was replaced by frequent customer feedback in the form of two-week sprints that ended with a product demo to the customer. The frequent feedback ensured that very little time was wasted on developing features that were misunderstood or not wanted, and the amount of change resulting from this feedback made long-term planning unnecessary.
A thoughtful man wearing glasses and a mustard-colored shirt is working on a laptop. He has one hand on his chin and appears to be concentrating. The background includes abstract graphic elements such as overlapping document icons and checkmark symbols, suggesting decision-making or reviewing tasks.

Agile methods that do align

In spite of these challenges, some of the methods from Agile can be applied to
hardware development with the proper modification:

Rolling Wave Planning vs sprints
Two-week sprints are one of the most common Agile methods (from the sub-topic Scrum). For each sprint, the team selects what work they will complete, works on it for two weeks, and then ends with a demo. This rapid feedback is very valuable, but many of the tasks in hardware projects cannot be completed in less than two weeks. So it’s necessary to incorporate Rolling Wave Planning.

Rather than creating a detailed plan over a long duration, the overall project is outlined at a high level and the details are added to the near-term future on a regular cadence (usually bi- weekly). This gives the flexibility to make small changes frequently without wasting time planning things that have a high level of uncertainty, and it allows long-duration tasks to span multiple rolling wave sessions.
Standup meetings
Daily standup meetings, another cornerstone of Scrum, were developed to quickly identify blockers and keep everyone aligned toward the sprint goal. The normal process is for everyone to share what they did the day before, what they’re working on today, and if they’re blocked or need help. While this may work for a small team of people with similar tasks and skills, it’s not as useful for larger teams with diverse work.

It’s better if the same information can be visible and instantly read from a board (a picture is worth a thousand words, after all) so the conversation can get right to the point: Is the critical path task stalled, and if not, does anyone else need help? This saves a lot of time and still completes the primary goal of the standup—to prevent blockages from delaying the end date.
Kanban and pull

Kanban methods originated in manufacturing and were successfully adopted in software development as one of the Agile methods. The key principle behind Kanban is that it creates a “pull” system—meaning the work is not started until someone is available to work on it. The Kanban tool for software developers is a board with columns that the tasks flow through as they are worked on (e.g., backlog, ready, coding, testing, approval, done).

The benefits are that it limits WIP, reduces multitasking, and works great for tasks that all follow the same process. But the work in hardware development is highly varied, so we have to modify the tool a bit.

Playbook recognizes the necessity of planning and combines it with a unique pull system. This means that in addition to the benefits of limited WIP and no multitasking, every team member also has correct priorities, every day, for all their projects. This eliminates the biggest cause of delay for most projects and is the primary driver behind predictable end dates.

A woman and a man, both wearing ID badges and dressed in professional casual clothing, are looking at a laptop. The woman is holding and pointing at the laptop while the man smiles, suggesting a collaborative work discussion or review.

Change the way your team works

Agile methods, while immensely successful in software development, face significant challenges when applied to hardware projects. The unique demands of physical production, complex dependencies, and the need for detailed planning make Agile less effective for hardware development, necessitating alternative approaches tailored to the specific needs of hardware engineering.

Want to transform the way your team works?

To see a hybrid method and a tool designed to support it, watch the demo or schedule a call for a deeper dive and Q&A session.

 

Schedule a call Watch demo