Do Agile methods work for hardware projects?

Agile methods were developed to improve the outcomes of software development projects because they took too long, and the end product often didn’t meet the customer's needs very well. So out of frustration, developers started looking for ways to improve.

Hardware projects have the same need to reduce cycle time and improve customer expectations, but the two types of projects are very different. Hence, it’s likely that a solution that works for one will have to be modified to work for the other.

Here we will review the differences and explain how Agile can be modified to work for hardware projects.

The primary benefit of Agile methods

Initially, software development projects were managed with traditional project management methods. This meant a lot of work was done before the customer got to see the product and provide feedback. So when they did, there were usually a lot of changes.

The founders of Agile realized the primary need was the ability to deal with uncertainty and respond to change.

The best way to do this was to increase the rate of feedback from the customer, which meant that long detailed plans were unnecessary and the “build-measure-learn” cycle had to be shortened and repeated more frequently.

Why Agile works for software

To do this, software requirements are broken down into small pieces that can be developed and shown to the customer in a two-week cycle called sprints. That way, if the feature isn’t what the customer wants, not very much time has been wasted. And if it’s going in the right direction, it can be modified and improved in the next cycle.

This process works great but requires a few characteristics from the product. The two primary ones are that you have to be able to break the product into small chunks that can be done in a two-week cycle, and it has to be somewhat modular—meaning changes to new features don’t impact the work that has already been completed.

Why Agile doesn’t work for hardware

The problem with hardware projects is they have neither of those characteristics. In software, the build-measure-learn (BML) cycle consists of writing the code, running it through the test environment, showing it to the customer, and capturing the necessary changes. Every feature can be developed following this process and it can be completed in two weeks.

In hardware, the BML cycle consists of designing a component or sub-assembly, acquiring the material and components, making it in-house or having it made somewhere else, and then testing it or adding it to a subsystem and waiting to test that. Simply acquiring the material could take more than two weeks, and the test cycle could also be weeks long. So the entire build-measure-learn cycle could be weeks or months long, and if the component fails it has to be repeated.

This long-cycle problem is also compounded by a long and complicated dependency chain in most hardware projects. If a change is made to one component, the impact stream may flow through many subsequent parts. Where software is relatively easy (fast and inexpensive) to change, a change to a physical part could take weeks or months and cost thousands of dollars or more. They are completely different situations.

Cross-functional teams

Another important difference between hardware and software projects is the makeup of the teams. Software teams tend to have a more homogenous skillset—there are usually multiple team members who can complete a task.

Hardware teams are much more cross-functional. It takes people from several departments to complete the work, so there is often only one person who can work on a task. This means the work may have to sit idle while it is waiting for the resource to be available to work on it.

Key differences between hardware and software

In summary, hardware and software have similar needs in terms of fast and frequent customer feedback and predictable end dates. But the key differences have to be taken into account when you are designing a solution for this environment:

• Longer build-measure-learn cycle
• Complex dependencies
• Cross-functional teams

Fortunately, the two most common frameworks from Agile (Scrum and Kanban) can be modified to deliver significant benefits over the standard hardware project management process.

How to make sprints work in hardware projects

Because the long build-measure-learn cycle in hardware doesn’t fit in a two-week sprint, we have to replace it with rolling wave planning.

As the name implies, the entire project is not planned in detail at the beginning. Instead, it is outlined at a high level initially, and then details are added for the near term when there is more certainty. Like sprints, this cycle is repeated on a specific cadence—usually every two weeks but can be flexed based on how fast things are changing in the current phase of the project.

How to make standup meetings work in hardware projects

Standup meetings are another important part of the Agile sprint process. This meeting is typically held each morning, is intended to last less than fifteen minutes, and usually occurs in the presence of a kanban board that manages all the work tasks for the sprint.

There is a detailed explanation here, but the traditional process is to share what you worked on yesterday, what you’re doing now, and what you’ll work on next. This level of communication is useful for software standups because the traditional kanban board does not make these details visible.

But it can be modified to make it much more effective for hardware projects.

Because hardware projects need a plan that shows all the dependencies between the tasks, the traditional kanban board with columns for each feature phase does not work. So the kanban board for the standup meetings in Playbook is designed to show all of the traditional information at a glance: What was completed yesterday, what everyone is working on today, when it will be done, and what they will do next.

The “picture” (visual board) is worth a thousand words and saves a lot of time in the meeting, and it also has an additional benefit—it shows the relative priority of everyone’s tasks.

The importance of relative task priority

What makes one task “more important” than another task?

Since all of the tasks in a project have some amount of slack (ranging from zero to many days) the ones with the least slack are most likely to move the end date of the milestone. So it makes sense that you should pay the most attention to the tasks with the least amount of slack.

This is such an important feature that the standup meeting board in Playbook is sorted by default so the team members with the most important tasks are at the top. This ensures they are discussed every day so they don’t cause a delay.

Additional benefits when Agile is modified to work for hardware

There are times when the cumulative impact is greater than the sum of the parts and this is one of them.

• When plans have the right details and the right amount of detail, they provide better information and are easier to maintain.
• When standup meetings are shorter and more effective, it allows more time to collaborate on important details.
• When team members have correct priorities every day, for all their projects, they don’t have to multitask so they get more done and are happier.

Ultimately, these benefits enable you to respond to change and have predictable end dates in an environment of uncertainty.

In summary

Software and hardware projects have the same challenges (long durations and poor outcomes), so they also have the same primary need (the ability to deal with uncertainty and respond to change). However, the two project types have differences that require slightly different solutions.

By modifying the sprints, standup meetings, and kanban board, you can realize the above improvements that will make the Agile methods work for hardware projects:

• Replace sprints with rolling wave planning.
• Modify the kanban board so the low-value information is visible.
• Sort the kanban board so the resources with the most important tasks are at the top.
• Use the meeting to ensure the critical tasks aren’t blocked and team members are prepared for upcoming handoffs.

If you would like to improve your project outcomes or see these features in action, register to watch this demo, or schedule a call to discuss the challenges you are facing.