The Agile Manifesto opens with "individuals and interactions over processes and tools," and we built an industry that sells processes and tools on top of it. Most teams still run the ceremonies. Far fewer remember what they were for.
The standup
Ten people stand in a circle (or a grid of cameras) and take turns telling the manager what they did yesterday. Nobody else is listening, because they're rehearsing their own update. When someone mentions a blocker, it gets taken offline and nobody follows up. That's fifteen minutes a day for a report the ticket board already shows.
A standup is meant to be the team coordinating with itself. Once everyone is facing the manager instead of each other, it's a status meeting wearing a hoodie.
What works better is talking about the work instead of the people:
- 1Put the board on screen, not a list of names. Everyone looks at the same thing.
- 2Walk it from right to left, starting with the cards closest to done. Finishing what's in flight matters more than starting something new.
- 3Ask one question per card: what's stopping this from moving? If the answer is nothing, go to the next card.
- 4When a card is stuck, agree who will help and when before you move on. "Let's take it offline" only counts if it has a name and a time attached.
- 5Pull in new work only after everything in progress has been covered.
- 6Stop at fifteen minutes; most days it takes five. Any problem-solving happens afterwards, with only the people it involves.
If the board hasn't moved and nobody is stuck, skip it.
Here's what that sounds like on a real board. Step through it:
To do1
- Search filters
In progress2
- Payment webhook
- Rate limiter
Review1
- CSV exportStuck→ Sam reviews it after standup
Donenot walked
- Login page
Card 1 of 4: CSV export.
What's stopping it? Waiting two days for a review.
→ Sam reviews it after standup.
Story points
We spend forty minutes deciding whether a ticket is a 3 or a 5. The points get summed into velocity, velocity goes on a slide, and the slide reaches someone who reads it as a commitment. Then the team is asked to "increase velocity," and it does, straight away, by estimating everything higher. It's Goodhart's law with a sprint board.
Points started as a rough way to decide how much work fits in an iteration. Ron Jeffries, who was there at the time, says "I may have invented story points, and if I did, I'm sorry now." The useful part was always the conversation ("wait, why do you think this is big?"), not the number.
You can keep that part for much less. Ask whether the ticket is too big. If it is, split it, and if it isn't, start it.
The retro
"What went well, what didn't, what will we change." The same three complaints come up as last sprint. Actions get written down, assigned to "the team," and never looked at again, and after a few rounds people stop raising real problems because they've learned nothing happens. At that point the retro is doing harm, because it's teaching the team that speaking up is pointless.
- Raise it to Owned by "the team": write it down
- Owned by "the team" to Nothing changes: nobody picks it up
- Nothing changes to Speak up less: next sprint
- Speak up less to Raise it: safer topics
The fix is small: one action, one named owner, and the first item of the next retro is checking whether it happened. If it did, you're already ahead of most teams.
Process should be the smallest amount of structure that stops a team tripping over itself. Once the process is what you're producing, delete some of it.