Transform your daily standup

So you’re a developer. Of course you’re doing SCRUM. Every sprint starts with a planning and ends with a review or demo. There’s a retrospective, some refinement sessions, and of course, your standup (or daily SCRUM). And although you’re following guidelines and have "standup questions" everyone needs to answer, there’s something wrong. The standup takes forever, you feel you’re wasting time there. You already know what you’re colleagues are up to. Why does that SCRUM master make you listen to this?

Sounds familiar? It does, right? You’re doing the standup wrong. Read on and transform your standup into the little ball of energy and focus for the whole team that it is meant to be.


So, what is it meant to be?

The first thing that pops to mind when mentioning the standup is "tell people what you have been doing and what you will do today". Or maybe "let the scrum master and product owner know how we are doing". While that is undoubtedly very interesting, it is not what the meeting is about.

The standup is there for team members. The update they present to eachother is a way to spot problems before they arise. A way to regain focus. It’s not as easy as it sounds but once your team masters the specifics of a sensible standup, the meeting is a source of information you can use to perfect the team’s happiness. And by that, help the performance of the team improve.

Symptoms of potential improvement

The following symptoms could be an indication your standup can do with a little improvement. Before proposing another approach, I’ll try and explain what went wrong in the first place.

Your standup questions

"What did you do yesterday?" and "What will you do today?" are the standup questions I often come across. The problem with them is that they stand alone. They do not in any way relate to the larger body of work or progress that your team is trying to get done, such as the sprint goal. They don’t even relate to what you said in the standup the day before.

Your standup is a way for developers to get a feeling of their flow. Are you well on your way as a team? Do you see any current or future problems that you need to tackle as a team? Report what you have been doing in close relation to what you told everyone you would be doing the day before.

I propose the following standup questions: 1. Did you reach your personal daily goal since the last standup? 2. What will be your personal daily goal until the next standup? 3. What prevents you and your team from reaching your sprint goal?

By explicitly setting a goal and referring back to it the next day, you’re making progress measurable, and more importantly feel-able, for your co-developers. This set of questions basically breaks down the larger sprint goal into smaller blocks. Not reaching your goal is not failure at all and you shouldn’t be mocked for that. There are loads of valid reasons for not getting there. However, noticing that someone did not reach their daily goal can help identify impediments that are working against you.

Your standup is a status report

Closely related to the standup questions discussed above, I often see developers reporting the status of an issue to the project manager, SCRUM master or product owner. The developers have committed to making the sprint during sprint planning. Micro-management during a sprint will only create tension between developers and other SCRUM team members, such as the product owner.

A product owner, SCRUM master, or anyone not explicitly part of the team needs to place their trust in the developers. Your job as a developer is to set your mind to finish an issue. This is a creative process of problem identification followed by problem solving. No-one can predict up-front how much time that process will take. Not even you. No, really, you can’t.

So how can anyone place trust in a developer that doesn’t know when an issue will be finished? Simple. They need to realize that software engineering is an unpredictable practice. Let them trust you in finishing an issue to your best capacities and report to them if there are any problems. They will then know that the development team does not need micromanagement. This kind of status report is, however, not what the standup is for.

I propose that, if you walk into problems while fixing or implementing an issue that possibly prevent the team from reaching their sprint goal, you walk over to the product owner and/or SCRUM master to tell them. Don’t wait for the standup. They will want to know anyway. This saves a lengthy explanation of the problem at hand during standup. Which I will say once more, is a meeting for developers to get a feeling on their flow as a team.

You are interrupted during your update

So, you are telling people what you have been up to, how that relates to your personal daily goal, and the sprint goal at large. Exactly as described above. You did it all. And still, there’s that product owner interrupting you during your update.

Tell the guy or gal to knock it off. Seriously. Tell them to let you speak. Refer to the trust I point out in the previous paragraph. No-one should interrupt you.

There are two general reasons why people are interrupting. The first is that they actually have valid questions. In that case, make sure to finish your standup with a general quick-question round. Don’t go into detail. Try to offload the answering of questions to somewhere outside the standup. But offer everyone the chance to ask these questions.

A second possible reason is that people think of something while you are talking, and they should have been telling this to the group during their own update.

To solve the latter problem, as well as to help solve the first one, you might introduce a "speaking stick", "standup totem", or the like. Find an object that can easily be hold while talking. The one holding the totem is the one doing the talking. No-one else talks. This is a very explicit and visible way of enforcing the "I am talking. Let me." rule, but it works quite nicely. The one thing to remember is to be very, very strict about it.

People don’t come prepared

Another observation I made is the high rate of participants attending the standup unprepared. While talking, they are looking through the SCRUM board for the issues they have been working on, thinking aloud.

This is the simplest of improvements. Define your standup questions (you could use my proposal found above) and prepare your answers to them. Present your part in a logical and coherent way, while relating to the larger (sprint) goal. This just saves time and allows for a better understanding of what you are actually trying to say.

Your standup takes place early in the morning

This is a tricky one. There is nothing really inherently wrong with having your standup early. It could, however, be an indication of a deeper problem. The standup doesn’t have to be early. The standup doesn’t have to be your daily kick-off, it can easily be held just before or after lunch, or some other convenient time of the day.

When planning your standup, observe the main objectives of the meeting: confidence in the current flow, and focus. To maximize the development team’s focus, you need your meetings to interrupt as few people as possible from their focused workflow.

If most of your team enters the office around the same time in the morning, it makes sense to plan your standup at that moment before everyone gets up to speed for the day.

However, if some people start their workdays at 8AM and others arrive at 10AM, having a 10AM standup breaks the 4 hours of undisturbed work before lunch for the earlybirds. Planning it just before or after lunch, a moment when focus is broken anyway, could in that case just make sense.

There is no silver bullet here. Evaluate your team’s standup time, find the moment that fits your team. Just make sure it’s the same time, every day.

It’s an iterative process

Like everything in modern software development, your standup format is an iterative process too. Experiment. Find your way. Find the team’s way. Don’t change everything at the same time, people seem not to be very good at handling large sets of changes at once.

Talk about this with your team. Try to find out what you and your team members want to get out of the daily standup. Define the goal and then find means to achieve that goal.

And if it doesn’t work? No problem, no shame, no-ones fault. Change it. Keep the feedback cycle short. It’s an iterative process anyway.

Symptoms I missed

This is by no means a full list of symptoms of standups that could do with improvements. These are just situations I run into. Do you have an example from your workplace? Or do you disagree with solutions I proposed? Please leave a comment below.