Iterating Beyond Software: Agile Outside of Code

Working software and Done Increments are two related ideas that people struggle with when they apply Agile or Scrum outside software. If you are developing a razor, a beverage, a clinical trial, or an internal operating model, “working software” is obviously not the literal goal. But the underlying idea still matters.

The point is evidence. You want transparency early enough to validate or invalidate assumptions before you spend too much money, burn too much time, or commit the organization to the wrong path. The non-software version of agility starts by asking what kind of increment would create useful evidence in this context.

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.

Some environments make working increments easier than others.

Food and beverage formulations — tweaking a formula is relatively fast. If you have a good setup for consumer testing, you can get increments in front of customers quickly. A “Test Kitchen” approach—a rapid-iteration lab environment—is an excellent example of this model working in practice. It operationalizes the ‘Done Increment’ concept for physical products, enabling inspect-and-adapt cycles on a cadence comparable to software sprints.

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 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, viability, feasibility). You can use these 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.

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

But the principle—frequent inspection of assumptions—still applies. In long-cycle domains like pharma R&D, you break the path into shorter hypothesis-testing loops. A clinical trial cannot be shortened, but the work of preparing, designing, and de-risking it can be managed iteratively.

Mock regulatory panels — a panel of experts convened every few weeks to review where you stand. Not a complete submission, but a holistic review of one risky aspect. The purpose is to find the smallest experiment that gives you meaningful evidence about your biggest assumption.

Clinical hypothesis tracking — breaking the path to approval into explicit hypotheses (safety, efficacy, competitive differentiation) and maintaining visible tracking of evidence. This is Evidence-Based Management (EBM) applied to R&D. EBM provides a structured way to track whether the organization is improving its ability to deliver value—regardless of whether the output is code or clinical outcomes.

Discovery-to-validation cadence — moving from Build It to Ship It is a considerable cliff in regulated development. Iterative work happens in the Think It and Build It stages, building up enough evidence to clear that cliff confidently.

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 formula development, cost is low and fidelity is high—so iterate fast. In razor manufacturing, full mold cost is high—so use 3D prints, accept lower fidelity, and iterate early before committing to tooling.

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 core value of Scrum—empiricism through frequent inspection of working increments—applies in any domain with uncertainty.

Practices that translate directly:

• Sprint cadence for regular stakeholder review
• Retrospectives — inspect and adapt the process, not just the product
• Product Goal and Product Backlog — a prioritized list 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 — requires careful design per domain (e.g., a tested formulation, a 3D-printed prototype)
• Sprint Review — the “shippable increment” becomes the appropriate fidelity increment for that domain

Practices to be cautious with:

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

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