It was sprint planning. Week 6.
The team had assembled the backlog. Stories were estimated, prioritised, ready to pull. The product owner was there. The developers were there. We had a board, a velocity chart, a Definition of Done on the wall behind us.
Then the product owner picked up the top three stories and said the words that changed how I think about delivery:
"I need to check these with David before the team picks them up."
David was the programme director. Not in the room. Not on the sprint team. Had not attended a single ceremony since kickoff. But nothing not a story, not a technical decision, not a design direction — moved without his explicit approval.
We had two-week sprints. We were spending an average of three days per sprint waiting for David to reply to emails about stories he had already signed off at roadmap level six weeks earlier.
That programme is where I first coined the term I now use for this pattern: Agile Cosplay.
Today’s Menu
🚨 The problem: What Agile Cosplay actually is, how it forms, and why the people inside it rarely see it
💸 What it costs: The exact delivery tax your team pays every sprint, measured in days, decisions and departures
✅ The fix: 3 interventions that dismantle Agile Cosplay without detonating your governance structure
⚠️ What Agile Cosplay actually is
Agile Cosplay (n.)
A delivery condition in which a team adopts the full visual language of agile sprints, standups, retrospectives and velocity tracking while actual decision-making authority remains entirely outside the team, operating on a sequential approval model, and is never acknowledged as a constraint in any ceremony.
The cosplay is not deliberate deception. It is institutional self-deception that the organization has adopted agile's vocabulary without changing any of the underlying power structures that agile was designed to dismantle.
Agile Cosplay is not about a team doing agile imperfectly. Every team does agile imperfectly. It is specifically about a team going through the motions of self-organization while operating inside a governance structure that makes self-organization structurally impossible.
Agile Cosplay is not a team failing to do agile properly. It is an organisation that wants agile's output without surrendering agile's prerequisite: actual decision authority inside the team
How it forms and why nobody stops it
Phase 1: The genuine adoption. The organization adopts an agile approach following a failed waterfall programme. Ceremonies are introduced with real intention. There are sticky notes. The language changes.
Phase 2: The first governance collision. A sprint produces a direction that a senior stakeholder did not expect. They do not say "I want to change how we make decisions." They say: "Can we just run the big decisions past me first, just while we get started?"
Phase 3: The normalisation. "Just while we get started" becomes permanent. The team adapts. Everyone understands, without it ever being said, that the real decisions happen elsewhere.
Phase 4: The mythology. New team members join, observe the ceremonies, and assume they represent reality. The senior stakeholders point to sprint reviews as evidence that they "do agile". An entire institutional story forms around a process that no longer resembles the thing it claims to be.
The ceremony said | The reality was |
2-week sprints with full team autonomy on story sequencing | Effective sprint: 12 days. 3 days per sprint lost to approval latency |
Retrospectives addressing real blockers | Retrospectives addressed everything except the actual blocker, naming it felt politically unsafe |
The product owner is empowered to make scope decisions | The product owner operated as an approval-routing function |
Velocity as meaningful planning input | Velocity varied 60% sprint-to-sprint based on how quickly David replied to emails, not team capacity |
🤔 Quiz
You join a programme mid-delivery. In your first 2 weeks, you observe: 2-week sprints with all four ceremonies, a well-liked product owner, sprint velocity consistent at 28–31 points for 4 consecutive sprints, and a well-groomed backlog. In every sprint planning, the product owner says: "These are the priorities we've aligned on.“I never thought I’d enjoy running this much. The energy, encouragement, and consistency of the group made all the difference.”
What is the most important question to ask in your first week?
A) "What is the team's Definition of Done and is it being applied consistently?"
B) "Who decided what the priorities are, and how?"
C) "Why is velocity so consistent — is the team sandbagging?"
D) "What does the product owner do between sprint reviews?"
👉 Answer at the end of this issue
💡 The fix
Agile Cosplay is not a process problem. It is a power structure problem. The fixes are not retrospective action items; they are specific, political conversations with the person whose approval behaviour created the pattern.
✅ Fix 1: Name it in the room without naming it as a problem
The wrong version: calling a meeting to discuss "governance dysfunction". That frames David as the problem. He will spend the meeting defending himself.
The right version: in the next retrospective, add one question at the end of the impediments section:
"On a scale of 1 to 5, how often this sprint did the team have to wait for information or approval from outside the team before work could progress?" |
Do not ask who caused the wait. Just quantify it. When the team answers you will have made the pattern visible without making it personal. Share the score with David framed as a delivery risk. Most senior stakeholders genuinely do not know their approval process is costing three days per sprint.
BEFORE Approval dependency was never raised in the retrospective. The team adapted around it silently. The pattern continued for 6 months. | AFTER Impediment question introduced. The team scored approval wait at 4.2 out of 5. Score shared with programme director. He voluntarily delegated story approval to the product owner within 2 weeks. |
✅ Fix 2: Replace approval with alignment of the Decision Boundary document
The root cause is almost always an unclear answer to one question: what is the senior stakeholder actually worried about? In my experience, it is one of three specific fears: strategic misalignment, reputational risk, or resource over-commitment.
The fear | The structural answer |
Team will build the wrong thing strategically | Quarterly strategic alignment session. The senior stakeholder sets the direction once; the team operates within it. |
Stakeholders are accountable for decisions they didn't make | Sprint review attendance they accept completed work each fortnight, after delivery, not before. |
Team committing resources without authority | A written decision boundary document: what the team decides alone and what requires escalation. |
The Decision Boundary document is a single page 2 columns. Decision category on the left, authority on the right. Once agreed, the senior stakeholder has what they needed: confidence that the things they care about will reach them. The team has what they needed: everything else.
BEFORE No documented decision authority. The senior stakeholder defaulted to approving everything because nobody told him what he did not need to approve. | A Decision Boundary created in a 90-minute workshop. Sprint approval dependency was eliminated for 73% of story categories. The remaining 27% is routed through a 24-hour SLA, not an open-ended email. |
✅ Fix 3: Fix the ceremony, make it do what it was designed to do
6 months of Agile Cosplay leave residue. The team has learned not to raise real problems in retrospectives. 3 repairs:
The retrospective reset. One dedicated session outside the normal cadence with a single agenda item: "What have we not been saying because it felt too political?" Use anonymous written input. This surfaces six months of accumulated frustration and signals genuine change.
The product owner recalibration. They need an explicit, witnessed mandate, ideally with the senior stakeholder present, that they have authority to prioritize the backlog without pre-approval. Without this, old patterns reassert within weeks.
The standup rescue. Replace the 3 standard questions with one: "What is the one thing that, if it does not happen today, will affect the sprint outcome?" Same 15 minutes. Fundamentally different conversation.
BEFORE Retrospectives became progressively shorter and less substantive. The team had collectively learned that the format was not a forum for the actual problem. | AFTER Retrospective reset ran in week 3 after structural fix. 11 items surfaced that had never been raised. Eight were resolved within the following sprint. |
Task for you
🎯 What to do this week
Run this four-question diagnostic on your current delivery environment:
In the last sprint, did the team pull any story without first checking with someone outside the team?
If the answer is no — you may be in Agile Cosplay.In the last retrospective, was the biggest actual impediment raised and discussed openly?
If there is a constraint everyone knows about but nobody names, that is the retro pattern of Agile Cosplay.Can every team member articulate what decisions they are empowered to make alone?
Unclear boundaries default to escalation.When did the most senior person in your governance last attend a sprint ceremony?
More than 3 sprints ago means they are disconnected from delivery reality and that disconnection is what enables Agile Cosplay to sustain itself.
If any of those made you uncomfortable: the issue is not your team's agile maturity. It is the governance structure your team is operating inside. Those are different problems with different solutions.
Want the Decision Boundary template?
🌐 Around the web this week
⚡ 1 tool: Linear's decision log feature lets teams document why a priority decision was made, not just what the decision was. Invaluable for giving senior stakeholders confidence that decisions are traceable without requiring them to approve each one.
📊 1 number: A VersionOne State of Agile report found 44% of organizations cite "organizational culture at odds with agile values" as their biggest barrier to adoption ranking above lack of experience, management support, or training. The ceremonies are not the hard part.
💬 1 quote: "Agile is not a methodology. It is a philosophy about where decision-making authority should sit." A programme director I worked with who said this to explain why he was dismantling agile on his own programme. He was right about the definition and wrong about the conclusion.
👉 Quiz answer
B — "Who decided what the priorities are, and how?" The phrase "these are the priorities we've aligned on" is doing a lot of work. Aligned with whom? How? When? The answer tells you immediately whether the product owner is making decisions or routing them. If they say "we go through them with the programme director before each sprint" you are in Agile Cosplay and you found it in week one. Option A is good governance, but tells you nothing about decision authority. Options C and D are downstream of the real question. Governance signals almost always hide in language, not in ceremony quality. |
👉 Quiz answer
David, the programme director in the opening story was not a bad leader. He was a thorough, conscientious person who had been burned once by delegating a decision he should have held, and who had developed an approval reflex as a result.
The tragedy of Agile Cosplay is not that the senior stakeholder is malicious. It is that they are protecting themselves from a risk they experienced once and in doing so, they are creating a much larger, slower, more expensive risk that nobody is measuring.
If you are the delivery lead trying to manage around David: naming the pattern, clearly and without blame, is the only thing that has ever actually worked. Most Davids, when shown the invoice, voluntarily put down the rubber stamp.
Is there a David in your current programme? What does the approval pattern look like and have you ever named it directly?
Hit reply. I read everything.
That’s it for this week.
Keep showing up, keep cheering each other on — and as always, run happy! 🏃♂️
P.S: Details in this issue have been changed to protect client confidentiality. The situation and the lesson is real
New here?
If this issue is named something you have been watching but could not describe, forward it to one person who needs to read it.