Iterating Beyond Software - Applying Agile/Evidence-Based Management in Consumer Goods, Food & Beverage, Pharma/BioTech and Beyond

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 — 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.

What Is the Non-Software Equivalent of ‘Working Software’?

The assumptions we want to derisk 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?
• Sustainability — can we do it in a way that is sustainable for our people, society, and world?

We face these assumptions whether we’re building a fully digital product, a cyber-physical system, consumer goods (laundry care, grooming, beverages, food), or tackling a complex challenge — such as how to get from initial indication to FDA approval as quickly as possible while navigating unknown competitive threats, clinical trial results, and regulatory environment.

The need for transparency and derisking is universal. Accommodating “transparency every couple of weeks” is the non-trivial challenge.

How Do Done Increments Work in Consumer Goods?

Some environments make working increments easier than others.

Food and beverage formulations — tweaking a formula is relatively fast, and if you have a good setup for consumer testing (as many consumer goods clients do), you can get increments in front of customers quickly. A “Test Kitchen” is an excellent example of this model working in practice.

Razor design — physical products can sometimes be tested with 3D-printed parts. This is a compromise in fidelity, but the earlier feedback is worth the fidelity tradeoff. The key question is always: is this increment good enough to generate the feedback we need?

Gating mechanisms as increment checkpoints — most consumer goods companies have gating mechanisms before commercialization (desirability gate, viability gate, feasibility gate). You can use these gates as structured increment review moments — but make them more frequent and lower-fidelity. Rather than waiting for the full gate, run a lightweight multi-criteria review every few weeks. This gives you directional feedback much earlier.

How Do You Apply Agile Empiricism in Pharma and Biotech?

The FDA approval process is a good stress test for agile empiricism beyond software. Suggesting “put your submission package in front of the FDA every two weeks” is obviously unrealistic.

But the principle — frequent inspection of assumptions — can still apply:

Mock regulatory panels — a panel of people with deep experience in what the real FDA will be looking for, convened every few weeks to review where you stand. Not a complete submission, but a holistic review of one risky aspect developed as fully as possible. The purpose is the same: get feedback on your assumptions before you’ve committed fully.

Clinical hypothesis tracking — breaking the path to approval into explicit hypotheses (about safety, efficacy, competitive differentiation, regulatory pathway) and maintaining visible tracking of evidence for and against each one. This is Evidence-Based Management applied to R&D program management.

Discovery-to-validation cadence — the Think It, Build It, Ship It, Tweak It model is useful here. In regulated product development, moving from Build It to Ship It is a considerable cliff. The iterative work described above is taking place in Think It and Build It stages — building up enough evidence to clear the cliff confidently.

What Is the Core Principle for Iterating Beyond Software?

There’s no single answer — but there is a single principle: look at the tradeoff between delayed feedback, the risk of inaccurate feedback due to increment fidelity, and the cost of creating each increment.

• Delayed feedback = higher risk of discovering problems late
• Low fidelity feedback = risk of learning the wrong lesson
• High cost of increments = pressure to batch into fewer, larger iterations

The right balance is context-specific. In consumer goods formula development, the cost of a test kitchen batch is low and fidelity is high — so iterate fast. In razor manufacturing tooling, the cost of a full mold is high — so use 3D prints, accept lower fidelity, and iterate early and often on the design before committing to tooling.

Remember where we started: we want early and frequent transparency that enables us to steer using evidence. Practices like Scrum’s Definition of Done serve that intent — adapted to fit the context, not applied mechanically.

The Definition of Done itself can evolve over time. In non-software contexts, it often starts with increments that address discovery (are we solving the right problem?), moves to validation (does our solution actually work?), and eventually reaches readiness to execute the manufacturing/commercial motion.

Also see the Professional Product Discovery and Validation Workshop for how this discovery-to-validation journey is structured in practice.

What Agile Practices Translate Best Outside Software?

Practices that translate directly:

• Sprint cadence for regular stakeholder review (even if the increment is a prototype, a formulation, or a regulatory document section)
• Retrospectives — inspect and adapt the process, not just the product
• Product Goal and Product Backlog — a prioritized, ordered list of work organized around outcomes
• WIP limits — preventing too many parallel experiments from diluting focus

Practices that need adaptation:

• Daily Scrum — still useful, but may be weekly in slower-moving R&D environments
• Definition of Done — entirely context-specific; requires careful design per domain
• Sprint Review — the “shippable increment” becomes the appropriate fidelity increment for that domain

Practices to be cautious with:

• Story points and velocity — even more misleading outside software than inside it; prefer flow metrics
• Burn-down charts — useful if work is genuinely decomposable; often not the case in R&D

Frequently Asked Questions

Can Scrum be used outside of software development? Yes, but with deliberate adaptation. Scrum’s core value — empiricism through frequent inspection of working increments — applies in any domain with uncertainty. The key adaptation is defining what a ‘Done Increment’ means in your context: a tested formulation, a 3D-printed prototype, a mock regulatory review, a validated consumer test. The structure of Scrum (cadence, review, retrospection) transfers; the specific practices require domain-specific interpretation.

How do agile teams handle long-cycle domains like pharma R&D? By breaking the long cycle into shorter hypothesis-testing loops within it. A clinical trial cannot be shortened, but the work of preparing, designing, and de-risking a clinical trial can be managed iteratively. The principle is finding the smallest experiment that gives you meaningful evidence about your biggest assumption — at every stage of the development process.

What is Evidence-Based Management (EBM) and how does it apply outside software? Evidence-Based Management (EBM) is a framework from Scrum.org that applies empirical thinking to organizational improvement and value delivery. It focuses on measuring Current Value, Unrealized Value, Time to Market, and Ability to Innovate. In non-software contexts, EBM’s measurement framework provides a structured way to track whether the organization is improving its ability to deliver value — regardless of whether the output is code, consumer products, or clinical outcomes.

What is the ‘Test Kitchen’ approach in agile consumer goods development? A Test Kitchen is a rapid-iteration lab environment that allows consumer goods teams to prototype and test product formulations, packaging, or consumer experiences in low-cost, high-frequency cycles. It operationalizes the ‘Done Increment’ concept for physical products — enabling inspect-and-adapt cycles on a cadence comparable to software sprints.

Working on applying agility in a non-software domain? Explore agility beyond software advisory or connect with Yuval to discuss your context.