The status report says green. The team says they’re on track. The percent-complete bars keep advancing week after week. Then the date slips, the scope cuts, the budget overruns, and the conversation in the boardroom shifts from delivery to recovery. The reports were never wrong in any individual week. They were wrong in what they were measuring.
- Watermelon reporting — green on the outside, red on the inside — hides the real state of a project until the recovery window has closed.
- Percent-complete measures activity against a plan, not whether the plan still describes the thing the organisation needs built.
- The rescue is evidence: a working product placed in front of the board every two or three weeks, with every prior assumption forced to either hold or fail visibly.
- The Sprint Review is the most under-used governance event available to a sponsor — and the place where the next decision is actually shaped.
- The transparency Scrum produces puts the decision about what gets built next back in front of the board every fortnight, while there is still time to decide.
Watermelon reporting, green on the outside and red on the inside, is what an executive sees when a project has stopped being legible to the people running it. Percent-complete measures activity, not value. It tells the board how much of the plan has been worked through, not whether the plan still describes the thing that needs to be built. By the time the colour changes, the recovery window has usually closed.
The rescue is not better reporting. It is a different kind of evidence: an actual piece of working product placed in front of the board every two or three weeks, with every prior assumption forced to either hold up or fail visibly. Watermelon reporting persists because the activity-based model rewards plans that don’t change and discourages the bad-news conversation that would change them, until the conversation can no longer be avoided. Scrum is the most established mechanism for producing evidence that interrupts that cycle. The ten calls below are the ones that matter when an executive sponsor, steering committee chair, or program director decides to use it as a rescue lever.
1. Stop accepting percent-complete
The first call costs nothing and changes everything. Refuse to approve any status report whose primary measure is percent-complete against a plan. Ask instead what has been built, what works, and what a user has seen. If the answer is “nothing yet, we’re still in design,” the project is not in delivery, regardless of what the Gantt chart shows. This single demand collapses the reporting fiction faster than any other intervention available to a sponsor.
2. Demand a one-sentence Product Goal
A project that cannot describe what it is delivering in a single sentence does not have a goal. It has a scope document. Demand a Product Goal: the single observable outcome the work exists to produce, written in language a non-specialist can verify. If the team needs three slides to answer, the goal has not been agreed. That uncertainty has been producing the watermelon all along.
3. Insist on one ordered backlog
Most rescued projects arrive at the boardroom carrying five or six parallel workstream plans, each with its own milestone schedule and its own RAG colour. Replace them with one rank-ordered Product Backlog: the entire body of remaining work, sequenced top to bottom by value. The exercise of producing it surfaces every disagreement about priority that the workstream view was hiding. The disagreements are the diagnosis.
4. See working product every fortnight
A Sprint is two to four weeks. At the end of it, something the user can see and the sponsor can test must exist. Not a status update, not a percentage, not a demo of an interface mock-up, but an actual piece of working product the business can operate. If the team cannot produce one in the first cycle, the work has not been broken down into deliverable parts. That is the structural problem the rescue is solving.
5. Attend the Sprint Review yourself
The Sprint Review is the executive’s most under-used governance event. It is the half-hour every fortnight where the product that has been built is shown to the people who paid for it, and the conversation about what comes next happens in front of the evidence. Sponsors who attend reshape the work in flight; sponsors who delegate the Review inherit whatever the team decided in their absence — and then ask, eighteen months later, why the product did not match what they thought they were funding.
6. Your product manager exercises sponsor authority on your behalf
The accountability Scrum calls Product Owner is the only role in the team authorised to decide what gets built next. That is a strategic product manager function, exercised on the sponsor’s behalf. If the person holding that accountability is junior, conflicted, or split across three other projects, the executive has effectively delegated their authority to whoever is closest to the developers each morning. Appoint a product manager whose judgement you trust as you would trust your own, because that is what they are exercising — and make sure they are the named Product Owner inside the team.
7. Approve the order of the backlog
Sponsors are usually asked to approve plans. They should instead approve the order of the backlog. The order is the strategic choice: what the organisation builds first if it can only build one thing. Estimates are the team’s professional judgement about effort, and they will change. The order is yours. Spend the governance time there.
8. Read the Definition of Done
The Definition of Done is the standard every increment must meet before it counts as done. It is the contract between the team and the business about what “done” actually means: tested, documented, deployable, accessible, secure, and compliant with whatever the sponsoring environment requires. Boards that read it and challenge it produce work that holds up after handover. Boards that never see it find the gaps after go-live, when they cost the most to close.
9. The Retrospective is your forward signal
The Retrospective is the team’s own inspection of how the work is going: what is helping, what is impeding, what they intend to change. It is the earliest visible signal that the structural conditions of delivery are improving or degrading. Sponsors do not attend retrospectives, but they should ask, every cycle, what came out of the last one and what was changed as a result. Stagnant retrospectives are the leading indicator of a project drifting back into watermelon territory.
10. Decide what gets built next
The transparency chain Scrum produces — vision into Product Goal, Product Goal into ordered backlog, backlog into Sprint, Sprint into working increment — exists to give the sponsor one specific capability they did not have before: the ability to look at what has been built, look at what is next in the order, and make a real decision about whether to continue, redirect, or stop. That is the payoff. Every other call on this list exists to make that decision possible.
Watermelon reporting persists because percent-complete does not require the executive to make a decision. It asks the board to approve continued effort against a plan that may already be obsolete. The transparency Scrum produces puts the choice back in front of the board every fortnight, with actual evidence underneath it. The sponsor who works this way is not waiting for the colour to change. They are deciding what gets built next, while there is still time to decide.
