The Scrum fans will all pile onto this and criticize it, for daring to challenge an entrenched practice. No original thinking allowed.
I agree that standups are a very poor way of achieving what they are supposed to achieve: awareness and accountability (I plan to work on XYZ).
The author points out correctly, that if someone has a blocker, they should raise that immediately — not wait for a standup. By the time of the standup, the blocker should be old news!
The author is also right that the critical thing to uncover is what issues exist. Not all issues are blockers: some issues are about how something should work — that’s not a blocker, because someone might just decide to approach it in some way that is not a good way.
The Agile Manifesto does not mention standups, yet so many people treat standups as if they are built into Agile. They are not.
What is Agile is,
- Just-in-time issue identification. (But how can we best achieve that?)
- Rapid issue resolution. (How can we best achieve that?)
- Those who need to know about a dependency, learn it just as soon as they need to know it, or sooner, but no later. (How can we best achieve that?)
Standups are not effective for any of that.
What is effective — and is Agile — is to,
- Have people share their intended feature level design approaches before they start work. This can be done in a “tech scrum”, a cross-team “design review” (because features usually affect more than one team), whatever you want to call it.
- Have someone — a team tech lead — be aware of what everyone is working on, every day, and think hard about what is being overlooked — because most people on a team are too focused on their stories to think holistically. That is just a fact that I have observed.
- A culture of reaching out immediately when there is a blocker is an issue emerges.
