Everything Was Tracked. The Team Still Built the Wrong Thing.
The sprint review starts the way every good one is supposed to. Burndown chart, clean diagonal line, right on pace. Every ticket in the sprint shows Done. The dashboard the whole room is looking at is green, top to bottom.
Then the stakeholder sees the feature live for the first time and goes quiet. "This isn't what I asked for."
Nobody missed a meeting. Nobody skipped a stand-up. Nothing was left undocumented. That's what makes this version of the story worse than the usual one — the one where a requirement never got written down, or a conversation never happened. Here, everything that was supposed to happen, happened. And the team still built the wrong thing.
Visibility isn't the same thing as understanding
Somewhere along the way, we started treating "can everyone see the state of the work" as if it were the same question as "do two people hold the same picture of what that work actually is." It isn't. A dashboard shows you whether a card moved from one column to another. It has no way of checking whether the person who wrote the ticket and the person who closed it were picturing the same outcome the whole time.
And it isn't only dashboards. A 👍 on a Slack message can mean "agreed," or "saw it," or "acknowledging so this stops pinging me" — three different things collapsed into one reaction. An "LGTM" on a pull request confirms the code compiles and looks reasonable, not that the reviewer understood what the change actually does downstream. A stakeholder's sign-off on a requirements doc proves someone clicked approve, not that they understood what they were approving. Different artifact, same trap: a visible signal standing in for a check that never actually happened.
This isn't a new problem for Groundwork — it's the automated, screen-shaped version of two myths I've written about before: that being in the same meeting means you have common ground, and that a ticket marked Done means the team succeeded. What's different here is that those myths used to be things a person claimed out loud, where at least someone could push back. Now they're rendered in green pixels, which makes them much harder to argue with.
The more you document, the more certain everyone feels
Here's the part that I think is actually dangerous, rather than just ironic: documentation and status tracking don't just fail to guarantee understanding — they can actively work against anyone checking for it. Every green ticket, every completed report, every clean burndown chart adds to a general sense that things are under control. And certainty is exactly the thing that stops people from asking the question that would have caught the gap: wait, what did you think we agreed on here?
Nobody double-checks an assumption when the dashboard already says everything's fine. The more artifacts pile up, the more confident the room gets — and that confidence isn't the same thing as understanding, it's usually a substitute for it. Two lines that should move together — how certain everyone feels, and how much shared understanding actually exists — quietly diverge, and nothing on the dashboard will tell you when.
This is worth taking seriously in plain business terms, not just as an amusing irony about project tooling. A gap like this is how a team ships a quarter of work that has to be substantially reworked. It's how a client relationship gets damaged over something that was, on paper, fully signed off. A stakeholder who approved a requirements document and still didn't understand what they approved isn't a hypothetical — it's one of the more expensive versions of exactly this trap, and it has nothing to do with software tooling at all.
Why this eventually shows up as something else entirely
It's tempting to say the lesson here is just that dashboards don't measure everything — they don't capture user adoption, or how a feature actually feels to use, or team morale. That's true, but it undersells what's actually going on. Those later failures are usually not separate problems the dashboard happened to miss. They're the same shared-understanding failure, resurfacing downstream, wearing a different costume, at a point where it's far more expensive to fix.
A team doesn't just fail to track adoption. More often, they never had a genuinely shared, checkable answer to what they were building toward in the first place — and nothing in their process was built to catch that, because tracking tickets was never designed to test it. By the time low adoption shows up, it looks like a product problem or a UX problem. It's frequently a communication problem that happened months earlier and was never visible on anyone's dashboard.
AI-generated meeting summaries and auto-updated status reports are, if anything, the newest and most convincing version of this same trap. A machine-written summary reads as even more neutral and objective than a person's manually updated ticket — which means it's questioned even less, while doing nothing at all to guarantee that two people in the meeting walked away with the same understanding of what was actually decided.
What actually catches it
More tracking isn't the fix — more of the same signal doesn't solve a problem the signal was never built to detect. What catches this is knowing, deliberately, who needs to verify understanding with whom, and building that check into the process rather than assuming visibility will surface it on its own. In the research this blog is built on, we call this a role-based communication interface: matching what gets communicated, to whom, and at what depth, to what that specific role actually needs in order to hold the same model everyone else is working from. I'll go deeper on what that looks like in practice — I've started calling the underlying idea a team's "Definition of Aligned" — in a future piece.
For now, go back to that sprint review. Nothing on the dashboard was wrong. The burndown was accurate, the tickets really were done, the report really was green. What was missing wasn't a piece of tracking — it was a moment, somewhere earlier, where someone checked whether the stakeholder's picture of the feature and the team's picture of the feature were actually the same picture. No dashboard was ever going to catch that. Only a person, checking, was.
This piece is part of Groundwork's ongoing series challenging assumptions about communication in agile teams. Read the Six Myths of Agile Communication or the research this is based on.
Comments