An Agile Software Development team works iteratively — they write some code or make a UI design model, get fast feedback on it, improve it and add to it. Some people claim that 3D printing and other rapid prototyping methods allow hardware developers to work just as iteratively. But they are wrong, for two reasons.

First, most ineffective hardware teams already work iteratively, in a series of build-test-fix loops that burn up a lot of time and energy to get to a good result. When a team builds a system prototype too early, they run into all kinds of problems they could have found with much less effort at the subsystem level, or by exploring multiple alternatives sooner.

Rapid Prototyping Just Accelerates Build-Test-Fix Loops

Rapid prototyping can accelerate the process, but that doesn’t mean getting to a solution faster, or building something that is production-ready or platform-worthy in less time. In fact, if the team isn’t prepared for the differences between prototype production methods vs. mass production methods, they could be in for a long, slow slog to get a product they can ship.

Second, iterative prototypes don’t build the extensible knowledge a hardware team needs to make better decisions, for today’s products and tomorrow’s products. When teams work in build-test-fix loops, they eventually (hopefully) get to a working product, but they don’t know why it works, and they often can’t even replicate the path they took to arrive at a working solution. When things go wrong in later stages, they don’t know why because they don’t have a good working understanding of the whole system. If their system architecture is weak, random iterations won’t fix it.

Effective Hardware Teams Build Systematically

A systematic 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. Some Key Decisions are so critical to the success of the program that they are worth more investment to ensure that the decision does not have to be revisited later.

Converge On the Most Important Decisions

For extremely important decisions like these, we take this to extremes. We maximize learning early and delay decisions as late as possible by pursuing multiple alternatives at once. This may sound expensive and difficult, but the benefits far outweigh the costs, and a few simple rules keep the complexity from getting out of hand.

Convergence is a method for making a complex decision by investigating multiple alternatives and narrowing down to the final solution in a series of steps. First, you establish a set to explore. Then you define a series of tests to probe the set for weaknesses.  As you go through the series, each test will eliminate some options until you have found your final solution.

The Source of Convergence

Convergence arose from Allen Ward’s theoretical work to prove a method he called Set-Based Concurrent Engineering (SBCE). Ward demonstrated mathematically that a team is more likely to find a solution to an engineering challenge before it runs out of time if it pursues multiple alternatives at once (set-based). He envisioned that teams would use this process across multiple subsystems on overlapping problems to help them identify design conflicts earlier (concurrent engineering).

Ward’s approach to SBCE is complex and difficult to implement in a team of any size. But I have experienced a lot of success with convergence, which is a simplified version of SBCE. Convergence strips SBCE down to focus on one decision. That eliminates the need for a lot of the coordination work that makes SBCE unwieldy.

A Stepwise Approach to Major Decisions

We converge on a decision in a series of stages. In the early stages, we evaluate large sets of alternatives using simple filters. As the set narrows, the tests become more complex until we arrive at the final solution. Through convergence, we build our knowledge about the alternatives as we zoom in on the options that will work.

The stages have a simple structure: design the test, run the test, eliminate the weak. The process of running the test requires the team to refine the ideas, turning sketches into drawings and then simulations and prototypes. By sequencing these steps to accelerate the cheap and fast while delaying the expensive ones, we can avoid investing heavily in ideas that don’t work.

We Invest Only in Ideas That Work

With the teams I’ve coached, I’ve seen this scenario over and over again: the option that a team would have chosen at the beginning gets eliminated when a weakness is exposed. Another option emerges as the one that delivers the best performance with the fewest risks. Sometimes the results are even more surprising — an existing solution just needs some adjustment to outperform every new idea, or a far-out alternative with huge upside proves to be much more realistic than it appeared in the first round.

On the surface, convergence seems to require a lot of additional time and resources. If you think of it as being similar to parallel path development, you would be right. But that’s not what convergence is. The set of alternatives grows smaller until the Last Responsible Moment to make the final decision. Only the final concepts get full development.

Managers often balk at convergence because they see only the work that goes into the alternatives that do not get selected. It seems wasteful to them to do anything that doesn’t end up in the final product. However, they don’t see all the effort that teams have to spend fixing things when the first choice does not work, and they have no alternative. Convergence is the way out of build-test-fix cycles.

Use Rapid Prototyping for Convergence

This is how effective teams use their 3D printers — to evaluate multiple alternatives. They know they’ll still need to test out the final selection with prototype parts that look more like production-ready components. But before they invest in production-ready parts, they can use rapid prototyping to explore ranges of options first, learning everything they can that way before writing bigger checks for more sophisticated components.