Change Your Standups

The simple action that will change your team for the better

Francisco Trindade
4 min readMay 8, 2020

Teams are different, problems are different. But if you are running any kind of agile-inspired process, you probably have a daily standup meeting. Its format has been the consistent change I’ve made in all the teams I’ve managed in the recent past, always for the better.

I’m not sure exactly how you are working, but I could bet it will help you as well.

The problems with “What did I do yesterday?”

In most teams I’ve had contact in my career, the standup format follows the industry de-facto standard. Something on the lines of:

  • What did I do yesterday?
  • What am I doing today?
  • Any blockers?

It doesn’t take long observing a standup in this format to start seeing red flags: nobody is paying attention because they are thinking about what they need to say, people are looking at their calendars/lists to figure what’s happening today, and the whole exercise becomes a status report that is only interesting to the team manager.

Besides the obvious indicators of a bad meeting above, there are a few deeper issues that this format brings:

Focus on individual work and effectiveness: the standup becomes about the person. What am I doing/building/finishing? What commitments can I make as an individual?

It’s hard to understand what is going on: having a clear picture of where the work is becomes a puzzle. I have been in too many teams where the product manager would come to ask me after the standup what was going on with a specific piece of work since the meeting itself would just leave them more confused.

It steers the team away from their goals: if all we talk about is what each person is doing, when do we talk about how the team is doing against its current goals?

So if this doesn’t work, what does?

The better metaphor

Many years ago while working with Dan North, he explained me his view of standup meetings, which is also shared in this presentation. In his words, standups are the equivalent of a team huddle before a play.

A more athletic version of a software engineering team’s standup

“How many yards can we get towards the goal line before the next time we stop. What can we do to make the next 20 seconds the best we can. Plays are called, the team agrees, everybody does their part in the play and if they do it right, they regroup again in a very short time and do it again”.

Standups are the time of the day where everyone should have a sight on the goal, understand where the challenges and opportunities are, and agree on how to work together to have the best day possible.

To do that, follow the walk the wall format. Focus your standup on the work being done and not the people. Here is my version of it:

Forget about what people did yesterday.

Not everyone needs to speak unless they have information about the work being discussed. Ideally, someone is running the meeting, which could be anyone in the team.

Go through each card on the board.

Start from the ones closer to completion and go backward from there. The mantra should be stop starting, start finishing.

For each of them, understand as a team what is the current status and how to get it done as soon as possible. I try to achieve that with a few questions:

  1. How is the work going/is there an estimate to finish it?
  2. Are there any blockers?
  3. Can anyone help you to move it faster?

Updates should be short. If they become too long, add them to a parking lot to be discussed as a small group after standup.

Look at the system

Which cards have been in the same column for long? Is any engineer in a rabbit hole? Is any card blocked because we are waiting for external dependencies?

The standup provides the high-level view of the team and you should use it to act on it. Rearrange things if needed. Ask people to pair, redirect priorities, and make sure you have the best formation for the day.

Align the team on the overall goal

Make it clear what you are trying to achieve. Some days you are trying to get a project live, some days you are trying to be careful with refactoring a complex area of the codebase. Use this time to set the tone for the day.

Try it. You won’t regret it.



Francisco Trindade

Born in Brazil. Living in NY. Engineering at Braze. Previously MealPal, Meetup, (co-founder) and ThoughtWorks.