I had a conversation with a hardware engineer whose organization got the mandate, “Go agile or bust!”
They’re attempting to manage their technical and schedule risk with two-week iterations. And, they’re trying to show finished product, not simulations. And, even though they work independently, they’re supposed to have a standup every day.
None of that makes sense.
What’s the Cost of Change for Interim Deliveries?
If you have a software-only product, you can minimize the cost of delivery and change, once you create this environment:
- Short build times. You can build the product in minutes or less.
- Sufficient test automation to know the build works.
- The team does just enough to show progress.
That environment allows you to release as often as you want. Certainly daily or hourly.
And, software products require a team of people because they require people from the full stack.
Mechanical and hardware products have a different cost of change. And, the products are not “full stack” in the same way.
Consider the Various Hardware Deliveries
I know of at least these kinds of hardware deliveries:
- Simulation. Before hardware people move to physical form, the people use software to prototype. I always saw hardware people use simulations to reduce risk. (Think of simulations as tests.)
- Prototype: The mechanical and hardware prototype. Think breadboards, with wires protruding.
- Pilot: What we worked with, as software people. I never saw more than three rounds of pilot hardware. More often, two rounds.
- Final hardware for customer release.
We can see the product progress through these deliverables. What does each deliverable cost?
What’s the Cost of Interim Hardware Deliverables?
We can assess or somehow predict the relative cost of each of these deliverables:
- Simulations: You pay for the simulation software once per engineer. Now, this part of the project looks like software. The hardware person creates the code to create the product and then creates tests in the simulator. This looks a lot like a software build and smoke test. Maybe more tests.
- Prototype: Now we’re into capital expenses. We need to buy enough parts to create a prototype. And, because we are now in physical form, we learn what we missed. We have hours of work and some wires to fix what we missed. My experience is that even if the simulator requires overnight to finish the tests, the prototypes take a week at a time to settle down. Maybe you’re able to create a prototype in one day. (I’ve never seen that.)
- Pilot hardware: Capital expenses for more parts. And, because you’re not into manufacturing, you’re buying ones or twos or threes. (Even if you buy 47, you’re not buying thousands.) And, the time to create a prototype that works. At least one day. In my experience, weeks.
- Final hardware: Some form of transition to manufacturing. Any changes after this point tend to be crazy-expensive. Especially if you find problems in the field that software can’t fix.
When you move from simulation to any physical form, you create substantial cost. Hardware deliveries—except for simulations—are nothing like software deliveries.
In software, we can build a product and test in minutes to an hour. (If you can’t, look at your cycle time for your builds and see what you can do to make the cost in minutes, not longer.
In hardware, once we go to physical form, we have both capital and operational expenses. And, maybe my information is old, and a great hardware engineer can get a prototype working in one day.
Compare that software build time of minutes to an hour to a minimum of a day for a hardware prototype.
That’s why two-week iterations don’t make sense for hardware if you’re supposed to show a product.
What Makes Sense for Hardware?
A strictly agile approach based on Scrum doesn’t work for hardware. It’s too expensive. And, hardware teams tend to be different than software teams. (I’ll talk about that more in Part 2.)
A waterfall approach doesn’t work for too many hardware products, either. That’s because we learn as we proceed.
How can we learn when we have a hardware product?
In the past, the hardware people I worked with used this approach:
- Create an overall design they hoped would work.
- Loop until release criteria (possibly landing zones) or physical limits or run out of time:
- Test the design in various ways via simulation, often one feature at a time.
- Redesign that piece
- Assess that piece in the context of the larger whole. Decide what to do for the architecture and the product.
- At the end, tell the software people what they couldn’t include in the hardware. We would laugh like hyenas and then redesign the software.
That’s an iterative approach, iterating over the feature set and the architecture. There’s a name for that life cycle: Evolutionary Prototyping.
Agile approaches work when the cost of change is low. While an iteration-based approach might not work, you have lifecycle choices for hardware. I’ll address that in Part 2, specifically to keep the product development costs as low as possible.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Costs of an Agile Approach for Hardware Products Opinions expressed by Java Code Geeks contributors are their own. |
I want to learn programming, which language will I start with