#NoStandups

The traditional daily stand-up meeting as generally practiced ranges from merely ineffective to a colossal waste of time. It’s a band-aid that’s hiding ineffective communication.

First, some history. The 15-minute “stand-up meeting” is de rigueur for many Agile shops. It’s been a standard practice from very early. JJ Sutherland told me the “first standup happened during the second sprint ever (February 1994)…at Borland.” First encounter that I had with the notion was the formalization in Kent Beck’s Extreme Programming Explained in 1999. 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. (See the Scrum Guide for more about Scrum’s take on the concept).

Whether or not you’re doing Scrum, the meeting involves the entire team, and usually follows a formula where everybody recounts some flavor of:

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

I personally think that three-question format is ridiculous. It just turns a simple coordination session into an empty recitation according to formula. All mention of the three questions has been expunged from the Scrum Guide, but like a zombie, it carries on, eating the brains of the teams that use it. So, what’s better?

Let’s start by looking at what shouldn’t be happening. 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. (You may uncover the need to replan in the meeting, though). 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) or update Jira to hold information that everybody already knows. 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.

To me, a stand-up—if it makes any sense to have one at all—has four main benefits:

  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.” (i.e synchronization).
  4. To arrange to get help if you need it.

Frankly, any way that you can achieve these ends is just fine with me, 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.

The best way to stay synchronized is to work in a way that doesn’t require it…investigate Mob Programming.

Where are we? It’s helpful to have a big-picture look at how the team’s doing. When done right, a stand-up can provide a place for the team to come into synch with itself at the beginning of every day. However, 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 often leaves all problems in one person’s lap rather than bringing the collective intelligence and skills of the entire team to bear. (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 Kanban board 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 board and figure out how to fix things. You may want to do that daily, but you probably don’t have to. Frankly, though, the best way to stay synchronized is to work in a way that doesn’t require synchronization. I strongly recommend that you investigate #MobProgramming.

I should add that “synchronization by infusion” (e.g. informal random conversations) doesn’t really work. What I’m suggesting here is many micro-synchronizations throughout the day, not abandoning synchronization entirely.

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 often just an ineffective substitute for continuous face-to-face conversations. It’s a band-aid covering a dysfunction. We certainly need ways to synchronize as a team, but to me, the standard formulaic standup is not the way to do that. Instead, we need to work on more-effective ways of working (like #MobProgramming), better communication, and continuous micro-synchronization. Yes, you can “fix” your stand-up, but to me, other approaches work better and achieve the same results: Work as a team, not as a bunch of isolated individuals who happen to be sitting next to each other. Talk to each other as you work (that is, continuous micro synchronization.) When you communicate constantly and effectively, a stand-up meeting is just a distraction.

1 Comments

  1. Alex on August 1, 2020 at 12:34 pm

    Dear Allen, I’ve been developing software for years (mostly embedded, mostly small scale), I love getting things done in highest code and product quality. I didn’t come to the topics of team organization because it just worked for us. We had a reorg to an “Agile” way and so I found your talks on Youtube and your ideas which I like (and take with a grain of salt).

    I understand the objections to the kind of Jira Stand-ups well, here’s my question: Nowadays when people tend to work from home to keep the virus at a distance, what are your best thoughts on ways to achieve _remotely_ the goals you mentioned?

Leave a Comment