Quantum Agile: Building Products When Everything Is Uncertain

Two weeks in, we knew the model was broken. The application workflow we'd agreed on started shifting — the client was showing the prototype to real users and getting feedback. Then the primary target market changed countries, bringing new security and infrastructure requirements. Then we discovered that BLE hardware configuration required dedicated research across platforms and devices. Then — that processing biosignals from a new type of device required deep domain expertise that we didn't have, and that frankly barely exists anywhere — the field is that young.

Every week we had to re-establish what we were actually building. Plans became obsolete faster than we could write them.

At some point we realized we were in a state best described by quantum superposition: uncertainty had reached a level where literally anything could happen. Any technical decision, any requirement, any market. Everything simultaneously possible and impossible until you looked. That's when the name stuck — quantum agile. And that's when we understood: to work in this kind of environment, a team must be ready for anything. Not "anticipate every scenario" — that's impossible. Ready in the sense of internal readiness: treating uncertainty not as a crisis, but as normal working conditions.

Why Standard Agile Falls Short

We had no fundamental quarrel with agile — it works well for most product development. The issue is different: even flexible methodologies quietly assume you have enough understanding at the start. Enough to write a User Story. Enough for a backlog to make sense at least within a sprint horizon.

Yes, the agile family includes tools for dealing with unknowns — Discovery sprints, Dual Track, Lean UX. These help when uncertainty is local: an unclear feature, an unvalidated hypothesis, a UX experiment needed. But our uncertainty was systemic — market, regulations, hardware platform, and the domain itself were all shifting simultaneously.

When understanding is missing at that level, sprints start spinning in place. Tasks are written knowing they'll change tomorrow. Velocity becomes meaningless because work gets thrown away. And crucially — the team can't feel progress, because the unit of progress in agile is "a shipped feature," and there are no defined features.

Waterfall is worse here: it demands you lock down everything upfront. But even agile, for all its flexibility, isn't flexible enough when uncertainty shifts from tactical to strategic.

Cynefin and the Domain We Were In

There's a useful framework — Dave Snowden's Cynefin. It categorizes work situations into several domains. In the complicated domain, experts apply proven practices — this covers most normal IT projects. In the complex domain, cause and effect are only visible in retrospect, and the only viable approach is probe → sense → respond: do something small, observe what happens, adjust.

Our project was in the complex domain from day one. We just didn't recognize it immediately — and so we spent several weeks trying to apply complicated-domain tools to a problem where the very definition of "what needs to be done" was changing faster than we could react.

Principles Over Plans

The answer we arrived at: manage by principles, not by plans.

To be clear: we're not claiming a new methodology. This is an honest attempt to assemble a working approach from what others have already thought through, combined with what our own experience taught us.

The idea isn't new — you can find it in Sarasvathy's Effectuation theory (how entrepreneurs make decisions under radical uncertainty), in McChrystal's "Team of Teams" (how distributed teams operate without centralized command), in Altshuller's TRIZ (how to solve inventive contradictions without a known solution). But in the context of managing software development, this idea is rarely articulated.

Here's the core insight. Under high uncertainty, a plan is an illusion of control. You spend time creating it, then updating it. Again. And again. The team starts to see planning as a meaningless ritual.

Principles work differently. They're not "what to do" — they're "how to make decisions." They remain stable even when everything around them changes. And — this matters — they let the team act autonomously without waiting for instructions on every step.

Here are the principles that emerged during this project — and that we've been refining since.

Seven Principles of Quantum Agile

1. A fast answer beats a correct answer.

When you don't know what's right, the fastest way to find out is a quick experiment. Not "we'll spend three weeks researching" but "in two days we'll build something we can show to a user." In our project, this meant: before solving the BLE platform question, we built a rough prototype to test whether that level of precision was even needed. It was.

2. The user's problem outranks the developer's problem.

Engineers tend to fall in love with technically elegant solutions. But the user doesn't care how clean the architecture is — they care whether the product solves their problem. When we changed the workflow for the fifth time, engineers were frustrated. This principle helped explain: it's not the client's whim, it's the market talking.

3. Good code is not perfect code.

Under constant change, over-engineering kills the team. We built "proper" architecture for requirements that changed a month later — multiple times. "Good code" means: follow best practices, but don't build castles where you need a cabin. This isn't permission to write bad code — it's a ban on architectural perfectionism under uncertainty.

4. If the market hasn't decided — we're ready for 10, 20, 100 iterations.

This sounds expensive. In reality, it's cheaper than building "the final solution" on unvalidated assumptions. When we shifted from "let's get it right the first time" to "let's build fast and learn," the project's pace actually increased — despite the chaos.

5. Research is work too.

The hardest principle to explain to stakeholders. When we spent two weeks diving deep into the domain, from a traditional project perspective we "did nothing." From a quantum agile perspective — we eliminated a critical uncertainty that would have killed the product during clinical validation. Not knowing is also a task. And it has a Definition of Done.

6. The team must understand "why," not just "what."

Under high uncertainty, a task can change mid-execution. If the developer understands the goal — not the specification, but the goal — they make the right call on their own, without waiting for a manager's update. This is the autonomy that McChrystal describes.

7. Transparency about uncertainty is not weakness.

When we stopped pretending we had the answers and started explicitly labeling tasks as "known," "unknown but researchable," and "unknown unknown" — project management became more honest and more effective.

What This Demands from the Team

Principles aren't magic. They only work if the team has a certain baseline.

First, trust. Principles work when people believe their colleagues are applying them in good faith — not hiding behind them to justify sloppy work. "A fast prototype beats perfection" in the hands of a responsible engineer yields speed. In the hands of an irresponsible one, it yields technical debt.

Second, high personal standards. Every team member can self-assess the quality of their work without waiting for external review. Otherwise, autonomy becomes anarchy.

Third, a culture where mistakes are acceptable. In a high-uncertainty project, mistakes are inevitable — you make decisions on incomplete data, and some of those decisions will be wrong. If the team fears mistakes, they avoid experiments. And without experiments in the complex domain, you don't survive.

Risks Worth Knowing

Quantum agile is not for every project or every team.

Clients with fixed budgets. If funding requires a locked scope, that's not a reason to abandon the approach — but a reason to have an honest conversation upfront. Agree in advance on an acceptable rate of change and how you'll justify it. We did monthly baseline reviews: documenting what changed and why, then aligning with the client on an adjusted scope. This removes the feeling of chaos and gives the client control — not over every step, but over the big picture.

Teams without self-discipline. The absence of a detailed plan demands high personal responsibility. If the team is used to working from tickets and waiting for instructions — the transition will be painful.

The illusion of movement. Constant changes can create a feeling of productivity without real progress. What matters here are metrics of uncertainty reduction, not process metrics: What did we learn? Which hypotheses did we validate? What did we eliminate?

Further Reading

• Dave Snowden, "Cynefin" — a framework for understanding which domain your problem lives in
• Eric Ries, "The Lean Startup" — Build-Measure-Learn under uncertainty
• Stanley McChrystal, "Team of Teams" — autonomous teams operating on shared principles without centralized command
• Saras Sarasvathy, "Effectuation" — how expert entrepreneurs make decisions under radical uncertainty
• Genrich Altshuller, "Creativity as an Exact Science" — TRIZ in its original form; the logic of resolving contradictions is universal

Quantum agile is not a methodology in the traditional sense. It has no ceremonies, no roles, no tools. It's more of a working stance: in conditions where the plan breaks faster than it's made, the only durable structure is principles shared by the team.

That medical project is ongoing — the product is already on the market. We held the baseline budget: some originally planned features had to be cut, but what remained genuinely solves the user's problem and sells. That, perhaps, is the real takeaway: we didn't build everything we planned — we built what was needed.

For us, that's the definition of success in the complex domain.