Why Strong AI Programs Still Fail Governance Reviews
AI programs often fail governance reviews due to poor documentation, not weak controls. Learn why ISO 42001 evidence matters for audits and procurement.
AI speeds up execution, but it can’t tell you whether work is ready to start. The 2-1-0 Framework gives teams a test for checking readiness before execution begins: two units of work queued, one committed, zero blockers.
Who this is for:
Delivery leaders, product owners, and engineering managers running AI-assisted teams who believe speed of execution is the problem when the real issue is whether work was ready before anyone touched it.
In brief:
- AI compresses the Agile execution timeline, leaving no slack for resolving unclear requirements and open dependencies that existed before the project began.
- As a result, issues surface on delivery that would have been caught and fixed in slower, more manual delivery cycles. The project is done, but not necessarily ready.
- Agile built a rigorous Definition of Done, but it left Definition of Ready largely undefined. The 2-1-0 Framework closes that gap without replacing Scrum, Scaled Agile Framework (SAFe), or Kanban.
- The 2-1-0 Framework assigns readiness to three owners: two units of work queued by product and planning, one unit committed by design and architecture, and zero blockers owned by delivery.
- 2-1-0 measures AI project readiness so you can fix problems before they escalate.
Most executives I work with ask the same two questions after a rough sprint: Why did we miss, and why is velocity down? They ask as if the answers live inside the team. Were the developers too slow? Were their estimates off?
In my experience, the problem is rarely the team.
Instead, the sprint likely slipped because the work wasn’t ready to begin. Requirements weren’t fully clarified, dependencies remained open, or decisions that should’ve been made weeks earlier were still sitting on someone’s desk.
For years, long timelines absorbed that slack. A late decision cost a few days of rework, and the miss looked like a velocity problem instead of a readiness problem. AI ended that era.
While some have challenged its methodology, MIT NANDA’s 2025 preliminary survey on enterprise AI found that 95 percent of generative AI pilots deliver no measurable financial return. DORA’s research goes a step further: As speed and input increase in software development, stability decreases.
The reason for these challenges has less to do with the models and more to do with what teams give product developers to work with.
AI hastens execution to a point where unclear requirements and open dependencies arise almost immediately, leaving no slack to mitigate them. After three decades running delivery organizations through this pattern, I built a way to test for these compressed-execution challenges: the 2-1-0 Framework.
Here’s what it is, how the three owners make it work, and where it fits alongside the Agile practices your team already runs.
Why AI Raises the Stakes
AI doesn’t create the readiness problem. Rather, it eliminates the time teams once had to absorb it. In the past, execution was slow enough that a skilled team could catch a vague requirement mid-sprint and quietly fix it.
Speed doesn’t reduce the expertise a project needs—it just relocates where that expertise appears. Today, the judgment call about whether work is ready must be made before execution starts, not during. Otherwise, AI closes the mid-sprint window before anyone notices it was open.
Teams that skip the readiness check get a bad outcome faster and then ship it with confidence. A 95 percent failure rate is most likely a readiness problem wearing a technology costume.
Once inputs are correct, AI can produce the deliverable—but it can’t tell you whether the inputs were correct in the first place.
Most organizations have no formal owner for that call and no fixed point when a human must intervene. The 2-1-0 Framework closes this gap.
What Is the 2-1-0 Framework?
The 2-1-0 Framework tests readiness with three numbers and three owners: two units of work queued ahead of execution, one unit fully committed with every decision made, and zero blockers when the work begins. Each number belongs to a different role, so readiness is less a feeling and more a tangible item you can check.
No more starting work with open questions. The 2-1-0 Framework builds a pipeline of readiness — from planning to delivery — so teams never hit a blocker on day one.
Two means two units of work are ready ahead of execution: prioritized, scoped, and written with clear acceptance criteria. Product and planning own this number.
One means one unit is fully prepared and committed. Designs are finalized, technical decisions are made, and dependencies are cleared. Design, architecture, and enablement own this number.
Zero means zero blockers exist when the work begins. Delivery owns this number, and it’s the simplest of the three to check. Either the queue is full and clear or it isn’t.
The framework tests whether team members upstream did their job before execution began, regardless of which methodology a team follows.
The 2-1-0 structure flexes to fit almost any environment. I’ve applied it as the outcome of a readiness assessment for one client and as the operating model for a team that never had one. It can also be applied as a layer on top of existing Agile practices.
None of that flexibility would have mattered if Agile already had this covered.
The Readiness Gap Agile Left Open
According to the 2020 Scrum Guide, Agile formalized when work is done, but it built much less rigor around when work is ready. In fact, the guide listed the Definition of Done as a formal artifact commitment, which Scrum.org’s “What Is a Definition of Done” webpage affirms. However, neither requires an equivalent Definition of Ready.
Individual teams have cobbled together their own versions of readiness for years, with no shared standard and no consistent way to measure it.
Other tools solve adjacent problems without addressing readiness:
- INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable), created by user story expert Bill Wake, helps a team write a good user story, but it says nothing about whether the surrounding system of work is ready.
- RACI (Responsible, Accountable, Consulted, Informed) assigns who’s responsible for a task but not when they need to complete it.
The 2-1-0 Framework answers the readiness question directly, assigning it to a specific role at a precise point in time. It checks something a well-written story can’t tell you—whether the queue behind it is full.
Readiness has been Agile’s blind spot since the start. The framework required done but left ready for each team to discern on its own.
What the 2-1-0 Framework Doesn’t Replace
The 2-1-0 Framework isn’t a substitute for Scrum, SAFe, Kanban, or other Agile frameworks. It doesn’t ask a team to abandon what’s already working. Rather, it sits underneath whatever methodology you use, treating readiness as a habit built in to how a team operates.
Most engagements I take on start with a walk-through: what’s ready, what’s decided, and what’s still open. It’s one of the cheapest gut checks in delivery, and it’s the one most teams skip.
Ask yourself one diagnostic question before your next planning cycle: If your team pulled the next unit of work into a sprint, could they start it without waiting on a decision, dependency, or designer? If the answer is “no,” you likely don’t have a velocity problem. Instead, you have a readiness problem, and AI will only make it more visible.
The test doesn’t fit every environment. Teams shipping small, well-understood changes with little variability may not need a formal readiness gate at all. The framework earns its place when the cost of starting the wrong work outweighs the cost of the check.
Readiness isn’t a phase you complete once; it’s a habit three roles maintain in every sprint.
None of this asks you to change your methodology. It asks you to name who owns readiness and when they’re supposed to deliver it.
Make AI the Accelerant, Not the Problem
The next time a sprint slips, don’t start with velocity. Start with readiness. Check whether the two units in your queue are scoped and whether the one unit ahead has cleared its dependencies. Then, ensure the work in front of your team has zero blockers in its way.
AI didn’t create this discipline—it just removed the slack that used to hide its absence. Teams that discern readiness and delivery ownership make AI an accelerant. Teams that don’t will keep mistaking a readiness problem for a velocity problem, and AI will only make that mistake more expensive.
If your team is fast with AI but still missing on delivery, the fix usually isn’t more tooling. Our experts help delivery leaders build readiness into how their organization plans and commits work. As a result, speed turns into results instead of rework.
