HomeArticlesHow to Run a Standup That's Not Pointless

How to Run a Standup That's Not Pointless

Want to receive these updates in your inbox? Sign up for my mailing list using the form on the right. (or below if you're reading this on your phone)

What did you do yesterday?

What are you doing today?

Do you have any blockers?

If you aren't familiar with these three questions, you probably haven't been working in software for very long. These are the revered three questions that--when answered by each team member each morning--are supposed to magically keep everyone on the same page and working harmoniously. Impediments are cleared, merge conflicts are avoided, and release deadlines are met.

So many teams mindlessly churn through these questions each morning, never stopping to ask why they're doing so, or whether it's bringing them any benefit. Almost every team I've ever worked with has used this formula at some point, and almost without fail it's a complete waste of time.

The problem is that it focuses on the individual.

Consciously or unconsciously, this format incentivizes each person to say as many words as they can think of, in order to sound like they were busy and productive. No one wants to sound like they've been slacking off, so they pack in all the things that they did yesterday, short of what they had for lunch, and provide little to no context for why any of it matters.

From the perspective of the listener, that lack of context means there's no incentive to pay attention to what the speaker says. As an individual, I don't really care what each of my teammates worked on yesterday. Or what they'll work on today. Unless my work is directly dependent on the work of one of my teammates, it's mostly irrelevant to me in the immediate term. I simply wait my turn to give my update, and promptly forget everything that was said in the meeting after it's over.

Be honest. If I were to ask you immediately following your morning standup to tell me what just one of your teammates did yesterday, would you be able to tell me?

I didn't think so.

This is not to say that standups are pointless, just that I have never seen this format provide any real value to a team. Instead, I prefer to use the format known as "walking the board" or "walking the wall".

It goes like this: Gather the team around your Dev Board (aka Scrum Board, Kanban Board, Factory Board) or present it via screen share if you're doing your standup remotely.

Starting with the column that is closest to being shipped, go through each work item and get a status update from the developer primarily responsible.

Continue through the columns until you have gotten updates on each card.

Adjourn.

There are several reasons I find this format superior to the Yesterday/Today/Blocked format:

  1. It focuses on the work, not the individual. This means that discussion is kept focused and relevant to the team. No more fluff in the updates.
  2. It surfaces interdependencies between work items more effectively. Issue XYZ was just moved into the Code Review column. Who's going to review it? It's easy to remember to ask this question, because you ask it of every card in the Code Review column.
  3. It exposes the team to higher-level concerns. For instance, it's really obvious if cards are piling up in the Code Review column. You don't have to rely on one enforcer to notice this and bring it up the team.
  4. Gathering around the board gives visual reinforcement to verbal updates. You'd be amazed how this keeps people engaged in the meeting and helps them retain the information afterward.
  5. It's faster. I know, it seems like it would take longer because you have many more cards on the board than team members, but refer to point 1. In my experience, the increased focus of discussion means that standups are often finished in 50-75% of the time that they take with the traditional format.

Don't get me wrong. Each team member should be interested and engaged in what the team needs and accomplishes beyond her own individual work. And in my experience, most of them are. Individuals are not interested in how their teammates spend their workdays. Walking the board focuses the team on what they are accomplishing together, rather than what each individual had for lunch.

If you try this format out with your own team, let me know how it goes.

Ben Wilhelm

Is your dev team working hard but not shipping? I can help.

I send a few emails per week with tips and ideas to help your team stop thrashing and start shipping reliable code consistently.
"What we got from Ben was more than just expertise: it was expertise plus organized thinking, clear communication, good humor, and an obviously habitual willingness to listen before advising. We recommend him without reservation, and look forward to the next time we work with him ourselves."