Agile Readiness Check

This checks the organisation, not the team. Teams rarely fail at agile; they are usually agile inside a system that is not, and absorb the friction as overtime.

Run it before a transformation, or when one has stalled and nobody can say why.

Organisation / programme: _______________ Date: _______

1. The constraint triangle#

• [ ] Scope, date and budget are not all three fixed
• [ ] If they are, everyone knows quality is the variable that will move
• [ ] Someone with authority has agreed which one flexes

🔴 Agile flexes scope. Where all three are fixed by contract or by mandate, the negotiable variable becomes quality, silently, and it is repaid over the following year. This single row predicts more transformation outcomes than the rest of the list.

Which variable actually flexes here: _______________

2. Feedback#

• [ ] Real users — not internal proxies — see working software at least every ____ weeks
• [ ] Their feedback changes what gets built next
• [ ] The plan has changed in response to feedback in the last quarter
• [ ] Someone can name a thing that was dropped because feedback said so

If the plan never changes, feedback is not reaching the plan, and iteration is producing overhead without its main benefit.

3. The product owner#

• [ ] One person decides what is built next
• [ ] They are available to the team, not booked solid
• [ ] They can say no without escalating
• [ ] They can decide within ____ hours

The team's iteration speed is capped by this number, whatever the process documentation says.

4. The release path#

• [ ] The team can release without a committee
• [ ] Time from merged commit to production: ____
• [ ] Rollback is tested and takes ____
• [ ] Change freezes are rare and time-boxed
• [ ] Environments are available when needed, not booked weeks ahead

A team that iterates in two weeks and releases quarterly is not delivering iteratively. It is batching, with extra ceremonies.

5. Funding and governance#

• [ ] Funding does not require a full specification before work starts
• [ ] Budget can move between priorities within a period
• [ ] Governance gates do not require documents that contradict iterative delivery
• [ ] Procurement can move at the speed of the work

These four are where transformations stall, and none of them are within the delivery team's control. If they are all "no", buying training for the team will not help.

6. Dependencies#

• [ ] The team can complete most work without waiting on another team
• [ ] Cross-team dependencies are visible and actively managed
• [ ] The team has the skills it needs, or access to them
• [ ] Shared services (platform, security, data) are not a queue measured in weeks

Average wait on an external dependency: ____

7. Estimates and measurement#

• [ ] Estimates are used to plan, not as commitments
• [ ] Estimates are not in anyone's performance objectives
• [ ] Velocity is not compared between teams
• [ ] Outcomes are measured, not activity

The moment a forecast becomes a promise, estimates inflate, scope is defended rather than discussed, and the information the numbers carried is gone.

8. What is actually measured#

The last row is the uncomfortable one, the hardest to gather, and the closest thing to the actual point of iterative delivery.

Verdict#

Three or more "no" answers means the constraint is the organisation, not the team. Fix those before training anyone. Certifying a delivery team does not move a funding cycle, a governance gate, or a release committee — and those are usually what is actually in the way.

Back to Agile