The big problem with hardware going agile is that the risks in hardware are not homogeneous. Hardware and mechanical engineering are on different cycles from each other, and they are each different from software. Even with each discipline, the risks are different when the teams collaborate together on one deliverable and when the entire program has to collaborate to create a product.
The engineering teams simulate to see problems in their own work and solve those problems. Each team is ready for integration at a different time. They can’t integrate until they go to fabrication. That changes the feedback cycle(s) for the entire program.
Questions you can ask are:
- Is there an interim physical form that would provide us value?
- How much does that form cost us to create?
- How long is it that prototype good for?
- If there is not an interim physical form that would provide us value, how can we obtain value and reduce risks with what kind of form or demonstration?
Here are some sample problems you could test for and avoid with early prototypes:
- The footprint is too large/too small.
- The design by contract work you thought was good turns out to be wrong.
- You have a design that works but doesn’t produce the product you want.
You may have other problems.
Because the hardware parts run on different cycles than the software parts, we have at least two ways to manage these risks: set-based design and landing zones.
In set-based design, the designers iterate on the design, they rule in or out designs that do not intersect with the rest of the design components. In landing zones, the designers discuss the parameters of what makes a successful design and then converge on that success.
Either of these looks much more like “implement several features and see what architecture emerges, rather than design up front.” It’s also about using the intelligence of an entire team.
There’s a third option: is there a cost-effective way to make a prototype that can provide you feedback without having all the properties? For example, can you use a 3D printer to check the physical footprint, even if you can’t check heat dissipation? I don’t know if that would work for your program or would be a waste of time. I do know that 3D printing is much faster than going to fab for many parts of your product.
I used a fourth option some years ago. We wanted to simulate the traffic on an internal network to see if the design we had would work. I asked about 20 people to meet the architect and me (I was the program manager) in a large conference room. We organized the people according to the types of traffic. We had a metronome to help people walk on time. We simulated the network traffic—what was going where and when—with people. It wasn’t a perfect test, and it told the architect a ton of information about how the software would work with the current hardware. I’m not sure we would do that now—we did not have adequate simulators back then. At the time, it was a cheap and useful approach to help the architect realize that the hardware would not integrate with the software as he desired.
These methods are not infallible. However, they both provide feedback faster and better than waiting until the end of the project/program, when you have spent all the money and time—and you still don’t have hardware that works.
Hardware can be agile. In Helping Hardware Be More Agile, Part 1, the product owner defines when she wants to see what with a roadmap. That helps the team determine their interdependencies and make the interdependencies visible. In Helping Hardware Be More Agile, Part 2, I showed potential kanbans and how the teams might use them. In this post, I suggested you might gain value from early integration and ways you might do that.
I have more discussion in Agile and Lean Program Management. I started the hardware chapter in the beta that is available now, and expect to complete it “shortly.”
