The Watermelon Project: six questions that cut through pattern blindness

Six questions that help you see, decide and act before green turns red

Most teams that struggle don’t lack a framework. They have Scrum, SAFe, a PMO, a stage-gate process, or all of the above.

What trips them up is quieter. They read the patterns in front of them the wrong way, and they keep doing it with total confidence.

At the IIBA Australia Festival of Business Analysis (FoBA2026) in Adelaide, I presented From Pattern Blindness to Value Acceleration. I opened with a simple hypothesis.

We don’t lack frameworks. We misread patterns.

Here’s the story behind it, the six questions we worked through, and a field card you can use in your next delivery conversation.

The Watermelon Project

We were delivering a new platform. The front-end team was reporting that everything was going well. The whole project had been sized at 1,200 story points, estimated before it started.

I was asked to stand up a new team to deliver the back end. I was also told that everything had to fit inside those 1,200 points, and that the number couldn’t change. Our work hadn’t been scoped. The two teams barely collaborated. So we built our own backlog and got on with it.

Everything was green.

As we started delivering, we struggled with dependencies and priorities across the two teams. People were forecast at 100% on the project but still had day jobs. Work carried over from sprint to sprint. Rework was high, and a few key people had everything waiting on them.

Everything was still green.

Velocity showed output, so the charts looked healthy. Outcomes told a different story. Because scope and points couldn’t move, there was a lot of scurrying before every sprint review to make the figures look right.

Eventually the numbers couldn’t hide it any more. The project was green on the outside and red on the inside. A watermelon.

If you’ve worked in delivery for any length of time, you’ve probably had one of your own.

Why smart teams miss it

In the room, we ran a version of a classic 1960 experiment by psychologist Peter Wason. I told the audience that 2, 4, 6 follows a rule, and asked them to find it by testing their own sequences.

Most people guess “add two” and test 8, 10, 12, then 20, 22, 24. Every answer comes back yes, so they feel certain. Very few test a sequence that could prove them wrong, like 6, 4, 2.

The rule is any three ascending numbers.

We look for evidence that confirms what we already believe. On the Watermelon Project, every green status report was another 8, 10, 12.

A better process won’t fix this on its own. What helps is looking through more than one lens. A mental model is a simple way of seeing a situation, and each one shows you something the others hide. Here are six, grouped by what they help you do: see, decide and act.

See: notice what’s really happening

1. The map is not the territory

Every artefact we make is a map: the backlog, the RAG status, the requirements, the velocity chart. Maps are useful because they simplify. They’re risky because of what they leave out.

Our 1,200 points was a map drawn before anyone had seen the territory. Then we treated it as fact and made it unchangeable.

Ask: “What would I see if I went and looked, instead of reading the report?”

2. Pattern or point?

One bad sprint is a point. Extreme results tend to drift back towards average, so overreacting to a single data point wastes energy.

The opposite mistake is just as costly: treating a pattern as if it were a one-off. We said “we’ll catch it up next sprint” six sprints in a row. Afterwards, hindsight made it all look obvious, which teaches the wrong lesson.

Ask: “Is this a pattern, or a point?”

Decide: avoid false certainty

3. Inversion

Instead of asking how to succeed, ask how you would guarantee failure. Then avoid those things. Optimism has nowhere to hide.

If you’d asked me on day one to design a project that would fail, I’d have listed fixed scope estimated before the work was understood, two teams that don’t talk, and people at 100% who still have day jobs. That was our plan.

Ask: “What would guarantee this fails?”

4. Second-order thinking

First-order thinking asks what happens next. Second-order thinking asks what happens after that.

The mandate that scope “can’t slip, can’t grow” gave the sponsor certainty. That was the first-order win. The second-order effect was that the only way to stay green was to make the numbers green. The mandate didn’t remove the risk. It hid the signal.

Ask: “And then what?” Then ask it again.

Act: build momentum, not just motion

5. Velocity, not speed

In physics, speed is how fast you move. Velocity is how fast you move in a direction. You can run flat out in circles and get nowhere.

Story points per sprint measure speed. They say nothing about direction. Our charts showed plenty of output while outcomes stood still.

Ask: “What outcome moved because of this work?”

6. Bottlenecks

A system moves at the speed of its constraint. Speed up anything else and you only grow the queue in front of it. In knowledge work, the constraint is usually a person or a decision, not a task. Overloaded people become bottlenecks without anyone noticing.

Business analysts often sit right at that constraint. That puts you in the best position to see it, and to say it out loud.

Ask: “Where is work waiting, and on whom?”

How we cut the watermelon open

When we finally intervened, every fix lined up with one of these lenses.

• We removed the bottleneck. We rebuilt the teams so each one had front-end and back-end engineers able to deliver value end to end.
• We brought the map closer to the territory. We set new norms for refining the backlog before each sprint started.
• We fixed the pattern instead of explaining away the points. We automated repetitive tasks and drove rework down.
• We pointed at direction instead of speed. We ran a sprint dedicated to innovation and improvement.
• We made a small second-order change. We moved the sprint start day.

None of this needed a new framework. We already had one. We needed a second lens, and we needed it sooner.

Watermelon warning signs

If any of these sound familiar, it’s worth a closer look.

• The status stays green while carry-over grows.
• Scope is fixed before the work is understood.
• People are “100% allocated” and still doing their day job.
• Numbers get tidied up before the review.
• There’s lots of output and no visible outcome.

Get the Second Lens field card

I’ve put all six lenses on a one-page field card. It includes the trap each one counters, the question to ask, where to use it, and a quick signal-or-noise test for stakeholder conversations and delivery data. Register below and you’ll get the web version plus a printable PDF.

Pick one lens and attach it to something you already do every week. Here’s mine.

“When I open a status report, I’ll ask: is this the map or the territory?”

Thank you

Thank you to the IIBA Australia team and everyone who joined the session in Adelaide. ScrumCraft was also proud to sponsor the festival in Sydney and present the Business Analysis Innovation Award.

Earlier in the festival, I presented Brain-Based Stakeholder Management online. You can read that write-up here: Stakeholders ≠ difficult.

Jason Cameron · ScrumCraft