#NoStandups

The traditional stand-up meeting as generally practiced is just a waste of time. Ineffective at best, a waste of 5% of your workday at worst.

First, some history. The 15-minute “stand-up meeting” is de rigueur for many Agile shops. The concept comes from XP, and the notion was that requiring everybody to stand up limited the meeting length by necessity. The worse your knees, the shorter the meeting. Scrum, of course, calls for a Daily Scrum, but there’s no requirement to stand up. The meeting length is timeboxed to 15 minutes, though. The Scrum Guide adopts the XP formula for the meeting: The entire team attends, and the meeting follows a formula where everybody recounts:

1. What they did yesterday
2. What they plan on doing today
3. What’s blocking them

You don’t solve problems in a stand-up. If you’re blocked, you arrange to get help later. You don’t plan in a stand-up, there are better times to do that and planning makes the meeting go on for too long. Looking at Jira and checking off “done” items is is a particularly heinous dysfunction that I see over and over. Stand-ups are not the time to create a “progress report.” (Not that there’s ever a good time to create a progress report.) In any event, an SM is not a manager, and producing a progress report for an SM is a perversion of the role. The team does not report to the SM. It’s self organizing. The meeting is for the team’s benefit.

A stand-up has four purposes:

1. To help with team unity by having a regular ritualized meeting
2. To avoid duplicate work
3. To give everybody a feeling about “where we are.”
4. To get help if you need it

Frankly, any way that you can achieve these ends is just fine, and if you can do it without yet another meeting, all the better. Let’s take these purposes one at a time:

Team unity: Team unity is a great thing. Instead of the stand-up, I’d recommend meeting at the local bar after work every day :-). It’s an environment more conducive to team bonding and honest conversation than standing around the office. How about a team breakfast? By far the best way I’ve seen to build the team and solve team-level problems was a lunch-time running card game. The company was located out in the boonies where there were no convenient restaurants, so everybody brought their lunch to work except for the one day a week where the company provided it. Afterwards, a huge card game ensued (Spades): multiple tables, usually with a mix of people from various teams. Kibbitzers as well as players. Great things happened, over and above having fun for an hour. People chatted about their problems and solved them. The conversations spanned teams, so we sometimes solved bigger problems than a single team could solve. Everybody in the company knew what everybody else was working on, so duplication of effort was minimized. More to the point, we could dispense with formal meetings that would only half-way achieve the same ends with a lot more pain and disruption.

Avoid duplication: A team that communicates effectively knows what everybody’s working on. That’s one of the reasons that most highly effective teams are colocated teams that talk to each other as they work. Yeah, I know that you want to work in your bathrobe and bunny slippers. Solve that problem with a change of dress code at work. Remote team members always introduce inefficiencies, and having even one remote member can completely eliminate communication effectiveness when a group is talking. You just can’t have a free-wheeling discussion when somebody’s on speakerphone. You may need the equivalent of a stand-up just to find out what the remote person is doing, but that’s just adding more waste to an already wasteful practice. Better to address the root cause.

Where are we? It’s helpful to have a big-picture look at how the team’s doing. A meeting where you all stand around and stare at a spreadsheet (that’s basically what Jira is) doesn’t do that. The 3-statement-stand-up approach tends to leave the problem in one person’s lap. (Yesterday I did X and today I’m still doing X—yawn). The two best tools I know to capture the state of the work are a physical Kanban board and a physical CFD (cumulative-flow diagram), both literally on the wall and updated continuously as you add and complete work. You don’t need a meeting to look at a physical CFD because you’re looking at it all the time. If the same information is hidden in a computer, you’ll probably never look at it. When something goes wrong, it makes sense for the whole team to gather around the CFD and figure out how to fix things. You may want to do that daily, but you probably don’t have to.

Get help: If you need help, you need help now, not tomorrow morning after the stand-up. When you talk to each other as you work, you get help when you need it. You need to be working together to pull that off, though. Remote people will tend not to ask for help in a timely way. Work out solutions to that problem in your next retrospective.

So, to me, a stand-up is an ineffective substitute for face-to-face conversations. It’s a band-aid covering a dysfunction. Work as a team, not as a bunch of isolated individuals who happen to be sitting in the same corner of the building. Talk to each other as you work (which gets us to #MobProgramming, but that’s another post). When you communicate constantly and effectively, a stand-up meeting is just a distraction.

(This article originally appeared on the author's blog: https://holub.com/nostandups).