Hardware product development is different than software. Both types of products go through a build-test-learn cycle, but the most obvious difference is that hardware cannot be built or tested as quickly or inexpensively as software can. Part of the reason is that the “build” cycle in hardware often includes an “acquire” cycle as well.
While hardware and software have a few obvious differences, there are still things we can do in hardware development that enable us to remain very agile and shorten the development cycle.
Here are three tips for implementing Agile:
-
Consider the cost of change
When considering a change in hardware development, the cycle time necessary to implement that change (acquire/build-test-learn) is often long enough that the “Cost of Delay” is so high that the benefit of the change is never realized. In other words, it’s not worth doing.
For example, a new material might have a significant Cost of Goods Sold (COGS) savings, but because it will take three months to fully test it, the profit from the lost sales for being three months late, is greater than the savings from the new material. Since software can be built and tested much faster, software development is rarely affected by these tradeoffs. -
Learn earlier
The ultimate goal of the build-test-learn cycle is to learn whether or not your new design is going to work. However, the learning comes at the end of that cycle. So it’s a good idea to look for ways to learn earlier in the process. Thankfully, there are usually a lot of ways to do this. The obvious ways are things like FEA and Rapid Prototyping. But it’s also possible to learn in smaller batches. This means testing components instead of subsystems. As well as testing subsystems instead of systems or entire products. It’s sometimes possible that even single components can be tested faster by testing single elements of the component.
For example, the ergonomic requirements of a handle can be tested separately from the strength requirement. So a simple mockup of the handle can be tested for strength, while the ergonomic test is done with a separate prototype that takes longer to build. This also prevents a possible delay if the strength test breaks the handle that was needed for the ergonomic test in a few days. -
Learn in parallel
Because the Cost of Delay is usually quite large, it often makes sense to run multiple tests of the same thing in parallel.
For example, new prototypes in various materials might be expensive to build. In this case, you might be inclined to try the least expensive one first, and if that fails, try the next most expensive one, and keep doing that until you’ve finally arrived at the least expensive option that works. However, if you know your Cost of Delay, it might make more sense to buy all of the possible prototypes and test them at the same time. Even if the first option works, you can still prove that the “wasted” money on the extra ones that you never used was a good financial decision.
Yes, hardware and software have a few obvious differences, but we can still apply Agile principles and shorten the development cycle without cutting corners, taking risks, or wasting money!
---
You can download the complete Guide to Applying Agile to Hardware below.
Related Articles
Agile Development
Applying Agile Values to Hardware Development
Agile Principle 1: Early and Continuous Delivery of Value
Agile Principle 2: Welcoming changing requirements
Making Hardware Development More Agile
Early Learning in Hardware Development
Agile Principles 4 - 12 to Hardware Development
Guide to Kanban
Agile and Hardware Development
