Working Software. Done Increments. Two related concepts in the agile world that people trying to leverage Agile/Scrum’s empiricism outside of the software/technology space struggle with.
The intent behind these practices is to achieve transparency to validate/invalidate assumptions—you might call it managing based on evidence. The key idea is to get transparency as early and often as possible to minimize the risk of continuing down the wrong path.
The assumptions we’re making could be in areas such as desirability (will they want it?), viability (can we make money on it? ), feasibility (can we do this? Can we make this? ), or sustainability (can we do it in a way that is sustainable for our people, society, and world? ).
We’re making such assumptions that we would like to derisk whether we’re building a fully digital product based on software, a cyber-physical system involving software and hardware, consumer goods (think Laundry Care, Grooming, Beverage, and Food Products), or even when we’re not designing/building a product but tackling a complex problem (e.g. how to get from initial indication to FDA approval as quickly as possible while navigating unknown competitive threats, clinical trial results, and regulatory environment).
There’s still a need for transparency and derisking leap-of-faith assumptions, but accommodating the “transparency every couple of weeks” that agile ways of working suggest is a non-trivial challenge.
Some environments are easier to get working increments in – for example, If we’re developing a new laundry care formula or a new beverage of food formulation, it’s possible to tweak the formula pretty quickly, and if you have a good setup for testing with your customers like my clients in this space do, they can get this in front of customers soon thereafter. A “Test Kitchen” is an excellent example of this in action.
What if we’re making a physical product such as a Razor? Sometimes, it’s possible to test via 3D printing parts. This would be a compromise because they’re not the real thing, but in many cases, they’re good enough from a fidelity perspective, and the earlier feedback is worth it.
What if we’re working on that FDA Approval challenge? What is it that we’re seeking here? You could suggest, “Just put your submission package in front of the FDA every couple of weeks,” and brace for the mix of laughter and ridicule that will ensue.
So what instead? It won’t be full transparency, but you could have a “mock panel” every couple of weeks with people who have enough experience about what the real panel will be looking for. The work done towards an increment to bring before this panel will be structured to enable a holistic review of where we stand. Of course, it won’t be complete, but hopefully, one risky aspect could be developed holistically so we can get feedback on it.
This approach is also quite useful when designing consumer goods. Feedback from consumers is just one area of assumptions. In order to steer based on evidence, we need to look at the holistic proposition—not just desirability but also viability, feasibility, and sustainability. Most consumer goods companies have a gating mechanism; these are considered before greenlighting a production/commercialization phase.
If this is your context, you can try reviewing the next gate criteria and structuring a lightweight review that explores as many of these criteria as possible in a lower-fidelity manner. Why? Going for high fidelity will require much more time, and it’s better to have feedback along the way.
There’s no one answer here. What you want to do is to look at the tradeoff between delayed feedback on your decisions/assumptions, the risk of inaccurate feedback due to the fidelity of the increment, and the cost of creating each of these increments.
Remember where we started – we want early and frequent transparency that enables us to steer using evidence. Practices like Scrum’s Definition of a Done Increment should serve that intent in our context.
Also, remember that the Definition of Done can change over time. In this context, it might be useful to start with increments that eat into discovery, then validation (as we discuss in the Professional Product Discovery and Validation Workshop), and eventually readiness to execute the manufacturing/commercial motion.
Reflecting back on the Think It, Build It, Ship It, Tweak It model, the work described above is taking place in the Think It and Build It stages because moving from Build It to Ship is a considerable cliff in these environments.
The post Iterating Beyond Software appeared first on Yeret Agility.