Five Things That Drive Agility
for Hardware Teams — but Agile Software Methods Fail to Deliver

In this series so far, I’ve discussed the principles of Agile, and how they express fundamental truths about good process management that apply broadly: cut batch sizes, work in a cadence, focus on delivering value early, strive for technical excellence.

I’ve also discussed some things that hardware teams need to do differently in order to act in accordance with a principle that manifests differently in hardware than in software.

This week, I’ll share five things that are completely missing from Agile Software Development — but essential for Agile Hardware development.

Some of these, such as phase gates, have been rejected because they look a little like “waterfall” — and I agree that waterfall thinking is bad. But it’s more that waterfall thinking was infused in early implementations of these practices. When we approach them from an Agile perspective, we find that they help improve the flow of work through hardware development, mainly by eliminating potential sources of bottlenecks.

1. Healthy Phase Gates

A healthy phase-gate process is an escalating series of hurdles that a team has to go through in order to get a product from idea to launch.

The hurdles are low in the beginning, to foster lots of exploration, but get harder and harder as the investment increases.

This supports the business in making good decisions about whether and when to invest in the next phase of development. These decisions need a home, or they can easily bog down a team in either waiting for investment decisions from multiple stakeholders or being pushed ahead before the team is ready and the design is mature.

2. Systematic Knowledge Capitalization

Hardware teams need to know what the company already knows about a product’s technology, customer and business model. Anything that can be borrowed from another product is something the team doesn’t have to do on its own.

Yet unlike software, it’s probably not as easy as just reusing a code library. Key areas of the environment around a solution may be different.

Effective knowledge libraries pull an organization’s knowledge together so that it’s easy to find and provides enough context so the knowledge can be extended. This helps teams eliminate the waste of reinvention and frees up more time for knowledge creation on the aspects of the product that are truly new.

3. Dependency Management and Critical Path Optimization

To launch a hardware product, teams of Sourcing, Process Engineering, Production, Sales and Marketing have to coordinate many different activities in parallel. The design engineers upstream of them need to understand this flow well enough to see the consequences of revisited decisions and the true cost of change.

We typically visualize this flow in a Gantt chart that helps us analyze the dependencies and look for opportunities to work more concurrently or take action to get high uncertainty work out of the critical path.

Since these activities are repeatable, and since Agile Hardware Development seeks to eliminate the risk of change, it makes sense to use traditional project management tools to optimize the schedule. This also helps design engineers understand what they need to do so that their own work does not appear on the Critical Path.

4. Cross-Project Resource Management for Scarce Resources

Hardware development teams consist of engineers from several disciplines. Typically, MEs, EEs and IEs work side-by-side with industrial designers, production engineers and test engineers. Not all specialty areas need to be involved for the entire program.

Some experts, such as the regulatory affairs rep who knows the rules inside-and-out, will be assigned to almost every program. Others, such as the system architect, will need to feed individual product projects from platform projects to develop solutions that work for more than one product at a time.

Hardware development organizations need practices to manage these scarce resources to keep them from becoming the bottleneck.

5. Set-Based Development with Convergence

An Agile Software Development team works iteratively on one code base, integrating new features and functionality as it becomes available. Every iteration builds the product in some meaningful way, so that the development process resembles an outward or upward spiral.

An Agile Hardware Development team thinks in sets: what are the options for X? How do they interact with the options for Y?

Their development process provides a means for the team to converge on an answer over a series of decision steps. It resembles a science museum’s display of a funnel for rolling a coin. The coin moves closer and closer to the target, zeroing in until the coin finally drops into the hole in the center.

This is the design approach that keeps value flowing when cost-of-change is high — rather than choose early and iterate, converge and then choose late.

Improve the Flow Through Hardware Development

In the next series of articles, we’ll drill down into each of these five missing pieces in turn to show how they improve the flow of hardware development to build speed, flexibility and responsiveness.

Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like