Dark Agile

Concept

A state where a team has copied the meetings and the board exactly, but nobody holds the authority to change the plan.

Why it exists

As agile spread, adopting it got easy. Meeting names and boards move in an afternoon. Block fifteen minutes every morning, cut the calendar into two-week chunks, put up a board with columns for to-do, doing and done, and the outward form is complete.

What doesn't move is authority. Can the team decide what to drop? Can an improvement raised in a retrospective actually enter the next cycle's plan? Does the person who says they're stuck avoid paying for it? All three sit in the org chart and the performance review, so they don't go up and come down like a board. Moving them means changing who gets to say no, which is a slower and more political decision than putting up a whiteboard.

Teams with the form and nothing behind it became common, and there was no name for that state. At Pagedeck, three months into running a daily scrum, Theo asked what the meeting was for. Every morning six people took turns describing yesterday and Mia wrote it down. In three months not one person had said they were blocked. The meeting ran exactly as specified and nothing happened in it.

Without a name, that conversation restarts from zero every time. One person says there are too many meetings, another says the team is lazy. Dark agile pins the state to a single phrase and points at where to look.

How it works

It comes from one sequence: copy what's visible, leave authority where it was. Each borrowed form loses a specific interior, so the symptoms repeat.

  1. The daily scrum turns into a status report. The point is to surface blockers early enough to clear them that day, but once a manager sits in and takes notes, nobody reports being stuck, because saying so reads as not being able to do the work. Without psychological safety — the sense that raising a mistake or a disagreement carries no penalty — this meeting always ends up here.
  2. The retrospective becomes a feelings session. It exists to change how the team works, but when the improvements raised there never enter the next plan, people go quiet after two or three rounds. A retro log carrying the same item for four months is the evidence. The meeting still happens by then; it just costs an hour and returns nothing.
  3. The sprint turns into a deadline. A fixed-length cycle exists so the team can adjust how much goes inside it. Set that amount from outside and the cycle becomes a deadline that arrives every two weeks, with unfinished weeks covered by overtime.
  4. The self-organizing team keeps only its name. The structure is that the team decides the order and the method, so when work is assigned person by person from above, there's no reason to help the person next to you. Everyone just finishes their own share.

The four symptoms arrive together rather than separately, because they share one root in missing authority. That's why adjusting the meetings rarely cures it. Take the manager out of the daily scrum and, as long as reviews are scored on how fast work moves, people still won't say they're blocked.

Where it shows up

Mostly in diagnosis. In a retrospective or an organizational review, someone asks whether the team has gone dark agile, and the question locates where form and authority came apart.

Four things are worth counting. How many improvements from the last three retrospectives actually landed. Who decided how much went into this cycle. Whether anyone in the past month volunteered that they were stuck. How many requests arrived mid-cycle from outside. All four are countable, which makes them harder to argue with than impressions. "Two of sixteen" is a harder sentence to dismiss than "the meetings feel like theater," and it also says where to start. Counting keeps the conversation off intentions, too, so nobody has to agree on whether management meant well or the team tried hard.

People weighing a job offer use it in interviews. Ask a company that says it works in an agile way what came out of its last retrospective and whether it shipped. A team with only the form usually can't answer. "We don't hold retros" is a better sign than "we hold them, but I don't remember what came up." The follow-up worth asking is who decided the thing that did ship, because a clear answer there says more than whatever framework the company names.

One caution. The moment this phrase gets used to blame people, it stops being useful. Calling a team dark agile is a verdict rather than a diagnosis, and a team that's been judged starts hiding problems. What needs pointing at isn't the team but the place where authority was cut.

How it sounds at work

"Three months of daily scrums and not once has anyone said they were blocked."

The meeting runs, but its purpose is dead.

"If what comes out of the retro can't go into the next sprint, it's just a feelings session."

There's no slot in the plan for improvements to land in.

"Two-week cycles, and a new request drops in from above every week. Is that a sprint?"

The reason for cutting the cycle at all has been cancelled out.

After Theo's question, Pagedeck spread out four months of retro notes and counted. Of sixteen improvements raised, two had entered a later plan. The other fourteen existed only in the notes.

What Grace asked wasn't why they hadn't been done but who could have done them. The answer was nobody. Items for each cycle came down from the quarterly roadmap, and the plan had no room for anything else. So what changed wasn't the meeting but the rule: fifteen percent of every cycle is now left for the team to fill on its own, and from the next retrospective on, improvements went into that space. The first two rounds went to test cleanup nobody had been allowed to prioritize.

What people get wrong

The most common misreading is that agile itself doesn't work. Two years in with nothing better to show, the conclusion arrives naturally enough. But what got adopted in those two years was a meeting schedule and a board, and nothing in the agile manifesto was ever put to the test. Organizations that reach this conclusion usually import a differently named methodology the following year and handle it the same way. Two more years pass with new meeting names.

The second is that too many meetings are the cause. The symptoms surface in meetings, so it looks that way. In practice the count is beside the point. Drop the fifteen-minute morning meeting and you save the time, but you also remove the place where being stuck could be said out loud, and a week later the same problem shows up larger. The fifteen minutes were never the cost. The cost was a room where the only safe answer was that things are on track. If anything needs cutting, it's the structure that makes those meetings decide nothing.

Where to go next

  • Agile

    check what the original looked like before the copy

  • Agile manifesto

    the one-page document that says what the gap is measured against

Last updated 2026-09-16