A typical remark (more like a complain) from people who don’t work in software is that Agile doesn’t work if you don’t build software. While the whole Agile community will scream “yes, it does!”, there aren’t too many pertinent explanations of what that would look like.
Without pretending to have solved the dilemma, here is a more visual explanation.
A typical software project has the benefit of being delivered either all at once or incrementally. The product is “sliced” into increments that are delivered every few weeks. That is the nature of the product. And here is what it looks like.
Hardware products (think physical products) however are not that easy to slice. And that has to do with many reasons: technology or technical architecture, not very modular building, monolithic entities, etc. But as always, “not that easy” doesn’t mean impossible.
Here are two options which, in many cases are actually very much possible.
Exhibit A: Slicing the product in bigger chunks
In this example, the increments are considerably larger than of a typical software project, ranging from 2-3 months to even something like 6 or 9 months. Doesn’t sound very Agile? Getting some feedback after 6 or 9 months is still better than no feedback at all. Discovering mistakes while still working on the product is still better than trying to fix them at the end. And if these blocks can actually be shipped, even better!
Exhibit B: Slicing the product after an initial big building block
Exhibit C: Slicing the product only after the biggest part of the product has already been built
A common problem with some hardware products is that they require a big initial block and then there might be some functionalities that could be added more incrementally. While not ideal, that still offers great opportunities for some feedback and improvements before shipping the end product. Some (agile) methodologies actually advocate that the best approach is to “build incrementally from firm foundations”.
As always the most important question is not how. Is why! And if the “why” is valid (frequent and early feedback, value discovery, fail fast, etc.), then the how becomes easier.