Stand Up Against Stand Ups

It's finally happening: your team is finally going Agile, whatever that means. The business has complained for too long. The team has complained for too long. You need to move faster and do more. Word comes down that you're going to try Scrum. This shouldn't be too bad. After all, Scrum can't be that hard to master. Well, turns out that there's a lot to Scrum, and your team can't just switch over in one day! Let's take this slowly, adding in the simple parts and going from there. Timeboxed iterations make sense. Your team already has a weekly meeting, so sprints are a week. That was pretty easy. What's next? Product owner, no; retrospectives, no; story points, no. Aha, stand-ups! Once every day, you stand up and talk about stuff. That's easy enough. Done. You are so Scrummy now!

Or not so much. That all-too-common story of Agile Transformation highlights a number of pitfalls that derail real change. The most deceptive practice, though, is the daily stand-up. The daily stand-up is one of those Agile things that is very visible and very tangible. A team physically moves from their desks, stands in a designated place, and talks in a circle for several minutes. Management can see and hear them move and stand and talk. But a good stand-up is more than just moving and standing and talking.

The biggest deception of stand-ups is that they're really just meetings. People will say they hate meetings but love stand-ups, not realizing they are praising a meeting they have to attend every single day. Because stand-ups are meetings, they suffer from many of the same drawbacks as any other meeting. They are synchronous. They are interruptions. They are, in part or whole, not equally valuable to everyone that must attend. The combined hours of lost productivity every day adds up.

Good stand-ups might be worth the costs, but bad stand-ups are simply drains on the team and the business. What distinguishes a good stand-up from a bad one? I take a page out of the Kanban book: good stand-ups are brief, and they are only about blocking issues. They don't involve discussion, sidebars, announcements, or even solutions for the blockers (unless the solutions are really simple). And they definitely don't include status. Status should be reported elsewhere, either on a board tracking work, in a system like JIRA, or wherever else communicates that information. Because of the difficulty, good stand-ups are expert-level Agile. Teams just starting out should not jump to stand-ups.

This assertion opens the question of what should a team start with if they are moving to Agile? Timeboxing is an easy step, though getting it right-sized is also deceptively difficult. Designating a product owner can go a long way in aligning priorities with the business and users, but can be exceedingly difficult to get someone to commit to. The two practices I believe are both achievable and most effective at improving things are story point estimation and retrospectives.

Story point estimation is easy to do. The team can integrate it as part of the weekly meeting. Even making bad estimates is useful because it shows where the team is under- or overestimating effort. More importantly, story point estimation forms the basis of numerous valuable metrics, facilitating both better future planning and better future estimation.

Retrospectives are not the easiest to get in place. They are another meeting. It also takes some skill to keep a retrospective from becoming a blamestorming session. Effective retrospectives will bring hidden and unexpected issues to the forefront that would otherwise quietly sap performance and productivity. At the same time, they will build trust and confidence in the members of the team.