Delivery
Why the sprint board and the steering pack never agree
The sponsor asks for a one-line status and gets two contradictory answers in the same afternoon. The steering pack says the programme is on track: milestone three signed off, budget on plan, risk register green. The sprint board says something rougher: the backlog has grown by forty stories since kickoff and nobody is quite sure when it stops growing.
Both are correct. They are not measuring the same thing.
A stage gate and a burndown chart answer different questions
A steering pack exists to answer "are we still doing the thing we agreed to do, for the money we agreed to spend." It assumes the thing was defined well enough at the start to be trackable against, and that assumption is exactly what a stage-gate, PRINCE2-style structure is built to enforce: a business case, a defined scope, a set of stage boundaries, and a formal decision to continue or stop at each one.
A sprint board exists to answer a different question: "given what we now know, what is the most valuable thing to build next." It assumes the requirement will keep sharpening as the team learns, and that trying to freeze it early would produce the wrong thing built precisely on schedule.
Neither assumption is wrong in general. One of them is wrong for a given piece of work, and the disagreement between the two reports is usually the first visible symptom that the wrong one got picked.
A programme with no named methodology is not neutral. It is running an unplanned hybrid, and nobody chose its rules on purpose.
The tell: what changed between the plan and the board
When we are asked to look at a stalled programme, the fastest diagnostic is not the risk register. It is comparing the original business case to the current backlog. If they still describe the same thing in the same terms, the stage-gate structure is probably still earning its keep. If the backlog has drifted a long way from what the business case funded, and nobody formally re-baselined the case, the programme has quietly gone agile without anyone deciding to run it that way, and the steering pack is now reporting against a target that stopped being the real target months ago.
The reverse failure is just as common and less talked about: a genuinely exploratory piece of work, forced into stage gates because that is the only reporting format the organisation knows how to run. Each gate review becomes a fiction where the team pretends the next stage is well-defined enough to commit to, because saying "we do not know yet" is not an acceptable answer in that room.
Choosing the method is a risk decision, not a preference
The honest version of this choice rests on two questions, asked at the start and revisited at each stage boundary: how much of the requirement is actually fixed, and how much does getting it wrong cost. High governance load and a genuinely fixed scope point toward PRINCE2 or a PMBOK-aligned waterfall, because the cost of an ungoverned change is high and the requirement is stable enough to govern against. Low governance load and a requirement that will keep moving point toward Scrum, because the cost of a rigid plan is discovering, three stage gates later, that you built the wrong thing precisely as specified.
Most real programmes are neither. A migration, for instance, usually has a hard, fixed constraint (the cutover date, the data that must reconcile) wrapped around genuinely exploratory work (exactly how the new platform's edge cases should behave). The honest answer there is a named hybrid: stage gates around the fixed commitments, sprints inside them, with an explicit statement of which parts of the plan are fixed and which are expected to move. Calling it a hybrid on purpose, in writing, is what separates a deliberate blend from an accidental one.
What a RAID log is actually for
Underneath both reporting styles sits the same unglamorous document: a risk, assumption, issue and dependency log, kept current and reviewed on a schedule. Agile teams sometimes drop it because a backlog feels like enough; PRINCE2 programmes sometimes let it become a compliance exercise nobody reads until an auditor asks for it. Either failure mode produces the same result: the sponsor finds out about a risk on the day it becomes an issue, rather than three weeks earlier when it was still cheap to manage.
A RAID log that is actually used is boring in exactly the right way. It has a small number of live entries, each with a named owner and a next review date, and it gets ten minutes at the start of every steering meeting whether or not there is anything dramatic to report.
How to tell if you have this problem
The symptoms travel together: status meetings spend more time reconciling two versions of reality than deciding anything; a milestone gets marked "on track" the week before it visibly is not; and nobody can point to the moment the methodology was chosen, because it never was, it just accumulated.
None of that is a team performance problem. It is a structural one, and it is fixed by naming the method on purpose rather than discovering which one you were running after the fact.