Is your daily stand-up a daily waste of time? These 5 experiments may help

Categories Agile
Is your daily stand-up a daily waste of time?

We’ve probably all been there at some point, standing in a daily stand-up meeting, thinking “This is a complete waste of my time!”.

Maybe, the stand-up dragged on forever, with someone going on and on about the day before in such detail that you start wondering whether they will mention that they went to the toilet as well. Or a couple of people were discussing how to solve some admittedly important issue which was completely irrelevant to the rest of the team, who ended up blankly staring into the distance, thinking about what might be for lunch today and just wishing for the whole thing to be over.

Or you were in an incredibly “efficient” stand-up, blitzing through the team members’ updates: “Yesterday I worked on Jira XYZ-123, today I’ll do the same, no impediments, next!”. Box ticked. Was it really worth getting disrupted in the middle of whatever complicated problem you were trying to solve for that?

Or the short daily status meeting where the project manager (who we might refer to dutifully as the product owner or scrum master because we are doing Scrum) get a progress report from each team member and then does a bit of micro management to ensure maximum efficiency.

As familiar as these examples might be, they are not what the daily stand-up is supposed to be about!

The purpose of the daily stand-up is to provide a convenient way for the team members to coordinate their work. If that’s the case, why is it then that stand-ups can cause so much frustration or, worse, apathy?

Some signs to look out for

If your stand-up feels like a waste of time, it probably is! Often, though, things can be a lot subtler than that. Maybe you do get some value out of it but have a nagging feeling you should be getting more.

Looking out for the following warning signs may give you some ideas:

  • Reluctance: Do team members need to be nudged to join the stand-up? Do they grumble or speak negatively of the stand-up? Not a good sign!
  • Blanking out: Do people give their update (typically to the scrum master) and then blank out, thinking about other stuff or even play with their phones while the others talk?
  • Micromanagement: Does someone use the stand-up to get progress reports from team members and assign tasks?
  • Too long: Does the stand-up often last more than 10-15 minutes? Chances are people get into too much details that are not relevant to the others.
  • Too short: Is the stand-up so short there is no time to get anything useful out of it?
  • Restrained: Are the team members prevented from freely discussing the things they need to (for example through the presence of someone from outside the team)? Or do they feel the need to appear busy, talking about irrelevant things they did yesterday?
  • Preventing collaboration: Might the stand-up even prevent the team from collaborating effectively? For example, if people delay solving a problem and wait a day instead for the next stand-up to talk to each other, that could add a lot of time to even the simplest thing.

Time to experiment!

So, if you’ve concluded that your stand-up isn’t up to the task, how do you go about fixing it? As so often, a good starting point would be to bring it up in your retrospective. Find out from your team mates whether they share your concerns. There is a good chance they do! Then work together to try to understand what’s not working and why that might be.

Once you think you understand what’s causing the problems, brain-storm solutions and agree on what to do differently in the next sprint and what result you are expecting from the change.

Read on for a few suggestions on possible experiments you may want to try, depending on the problems you are seeing.

1. Changing the start time

Do people often miss the stand up or does it feel disruptive to the work going on? Think back to when the start time first was agreed. Why did you go for that time slot? Have you considered lately whether those reasons are still strong enough to hold true? For example, let’s say that a manager decided that all stand-ups start at 9am, to make everyone arrive on time in the office. If people still rock up closer to 10am, resulting in a rubbish stand-up, wouldn’t it be better for everyone involved to just find a suitable time later in the day?

Ask your team mates when would be most convenient for them to have the stand-up meeting and reschedule it. For example, who says a stand-up must happen first thing in the morning, or indeed in the morning at all?

2. Making the stand-up meeting smaller

Perhaps the problems you see in your stand-up are part of a bigger problem, quite literally. If your team is very big, it will be very hard to make good use of the stand-up. With 15 people in your stand-up, chances are there won’t be much of the meeting that is relevant to each of them.

If the problem is that people from outside the team feel a need to come along and share what they were doing yesterday and what they are doing today, is there any chance you can make them not do that?

When it’s the team that’s too big, would it be possible to split it into two smaller teams? Scrum prescribes a team size of 3-9 members and many find that a team in the lower half of that interval makes it easier to collaborate than one that’s bigger. If the team is too big, there is simply too much work going on for it to be possible for everyone to stay across everything enough to feel responsible for the work together, as a team.

3. Shaking up the format of the meeting

Regardless of what some might say, there is no specific format a stand-up meeting needs to follow. Experiment to find out what works for you. Some suggestions:

  • Take turns running the meeting or do it without anyone “running” it at all. There is no reason the scrum master needs to run every stand-up meeting. In fact, it is probably better if they don’t, to reinforce the point that the meeting exists for the benefit of the team.
  • Ditch “the three questions”. If you haven’t already, try what happens if you move away from the standard questions (“What did you do yesterday”, “What are you doing today?”, “Are there any impediments?”) and focus instead on the cards on the board (or whatever equivalent you use), going through them one after another. Maybe the stand-up gets more focused and fewer things get forgotten?
  • Get a flipchart. In case impediments are raised but then forgotten about until the next stand-up, might it help to write them down straight away? Or maybe it’s worth writing down those questions you agree to take offline so you don’t forget?
  • Set a timer. Do you have a problem with discussions often going on for too? Might it be an idea to set a one or two-minute timer for each story or person or would that feel too strict?

The things you can vary are endless and the team will be the best judge of what’s appropriate or not.

4. Inviting or un-inviting the product owner

Despite us now often working with a generation of developers who may never (on paper) have been working in a traditional environment, there is still often an assumption that you need a manager to be able to make decisions. If a manager turns up to the stand-up, chances are people might look to him or her to do just that.

If you struggle as a team to use the stand-up as an opportunity to self-organise around the work in the sprint, try suggesting to the product owner that they probably don’t need to attend every stand-up.

On the other hand, a product owner who attends the stand-up for the right reasons can be of great help, answering questions, clarifying misunderstandings and offering to help removing impediments outside the team. If they don’t yet attend stand-ups, you will probably want to ask them to attend at least a few times every sprint.

If you are a scrum master, you can reinforce the message of the meeting existing for the benefit of the team by you intentionally missing a couple of stand-ups. On the other hand, a scrum master who rarely attends would struggle to achieve their job, so don’t take it too far!

5. Replacing the stand-up with something else

The final experiment is potentially the most controversial, so first a word of warning. If your stand-up doesn’t work, the first thing to try should not be to cancel the meeting. That would most certainly address the symptom rather than the problem. Instead, try to find out why the meeting isn’t worthwhile in its current form.

With that out of the way, let’s not forget what the stand-up primarily is about: enabling the team to coordinate their work. If you and your team mates already have an effective way to achieve that goal, and it just so happens it doesn’t involve physically standing up together in front of the task board for 15 minutes at a fixed time every day, there is no reason you must have a daily stand up meeting.

Maybe you have found that your pull requests in Github, a chat tool like Slack and/or a sitting down for a coffee together meets the same goal. If so, why not get rid of the stand-up? Who’s going to stop you? If everything comes tumbling down, you could always add a stand-up back in later.

The important thing is that you achieve the goal of the stand-up; it doesn’t matter how you do it!

What problems have you’ve been seeing in your stand-up and what did you do to address them? Share your experiences in the comments below! 

Magnus Dahlgren – Scrum Master (CSP) and Agile Coach

1 thought on “Is your daily stand-up a daily waste of time? These 5 experiments may help

  1. The larger the team the less useful the stand up becomes. People end up wasting 20 minutes listing to things that don’t concern them. Sadly this is all too common as many teams attempts to adopt Scrum is actually just Waterfall with stand ups.

    Ideally with a small well communicating team a standup style coordinated communication activity becomes a spontaneous thing where everybody wants to know how each others task is going as they all relate directly to a unified sprint goal. I’ve actually experienced such useful discussions be interrupted by a call to a stand up that failed to achieve what the conversation was achieving…

Comments are closed.