Are daily standups still adding value?

Are daily standups still adding value to the development process? Probably. Do they need to change with the times? Almost certainly.

We’ve been doing standups for almost thirty years now. Can you believe that? Shoot, the Agile Manifesto happened just over 20 years ago.

There has been a lot of water under the software development bridge in that time. Over the last thirty years, we’ve seen the rise of distributed source control tools instead of ZIP files, project management tools instead of spreadsheets, and metrics tooling instead of sticking our finger in the wind. A lot has changed, so it stands to reason that the daily standup should change as well.

The daily standup was originally conceived as an information-sharing meeting. Setting aside whether you should ever have a meeting merely to pass out information, the meeting typically would answer three questions:

1. What did you do yesterday?
2. What will you do today?
3. Are you stuck, and if so, how?

The idea was to keep things short and sweet and not do anything other than answer those three questions quickly and succinctly. The ideal meeting was fifteen minutes or less. No discussion. No solutioneering. Just the answers.

But of course, we all know it usually doesn’t work out that way. We always end up talking about problems and trying to solve them right there. We cross-talk. We try to fix where we are stuck on the spot. We go over fifteen minutes all the time. It takes real discipline to run a standup the way it was intended to be run, and I’ve seen precious few teams who were consistently able to pull it off.

Plus, the three questions have been rendered almost moot by our current tooling. Tools like JIRA and Shortcut (formerly Clubhouse) keep us up to date with what people are working on and what is getting done when. GitHub, GitLab and BitBucket let us see even more detail about exactly what the team is doing. Conversations on Slack or MS Teams are constantly flowing, and are often the first place people go to when they get stuck. Combine those tools all together into a tool, and you can have deep insights into your software development process. So I’m wondering – do those questions even need to be asked in light of these new, modern capabilities?

Where’s the value?

I might push a little further. So commonly people answer the 3 questions, but go past it. Why do we do that? What are we trying to achieve with those three questions? I find that solidifying the purpose of these meetings helps identify things like… can you do it effectively async or remote. My direct answer to the question though is that most standups never achieved their purpose or value.. but they can still be really valuable in person, remote, or async.

– Ryan Latta, in the DevInterrupted Discord

If you have an 8 person team meeting for 20 minutes a day, 5 days a week, that is 800 minutes, or 13 hours and 20 minutes a week. That is a non-trivial amount of time and spending it on a daily meeting needs to be justified.

Standups do have some inherent value. No matter how they are run, they do promote teamwork and camaraderie. They do allow everyone to see and hear from everyone else on a daily basis. They can ensure that everyone is on the same page.

But at the same time, if you do decide to spend the time, you need to spend it wisely. And of course, that makes one think: Are the three questions above really the best way to spend that time? If the team pretty much already knows the answers to the three questions because of better communication tools, what are the things that the team doesn’t know about? What are the questions that could be asked in a standup that would provide real value? Here are the things that come to mind:

1. How far along am I on my project?
2. Is the scope of my project the correct size for this iteration?
3. Am I being pulled away from my top priority? If so, how?

All three of these questions are critical pieces of information that point to one central idea: Am I going to complete what I said I would in the timeframe I said I’d do it in?

How far along am I on my project?

This question is important because it tells the team where you are at with regard to the current scope of your project. It probably would be answered in a percentage, though that would merely be an estimate. It could increase or decrease by the day as you learn more about the thing you are working on. Of course, that fact leads to the next question:

Is the scope of my project the correct size for this iteration?

This question is critical because it may be that the project is simply too big to be finished within the defined time or iteration. Software estimation is a black art at best, and very often you bite off more than you can chew. (Only occasionally will a project take less time than you think it will). If the answer to this question is ‘no, the scope is too big’ then adjustments to the schedule need to be made.

Am I being pulled away from my top priority?

This question is similar –- but not quite the same – as ‘Am I blocked?’. This is asking about a very specific type of blockage: external demands. Maybe the CTO specifically asked you to work on something. Maybe the product manager gave you a presentation to deliver. There could be any number of things that distract you from your number one priority. Reporting that in a daily standup gives your project manager the opportunity to do something about it and remove the distraction.

Importance of observability

If a team is going to follow this new way of doing things, then of course the ability to observe the software development process, the development pipeline, and the metrics associated with both becomes critical.

In the past few years, such tools have become available. At my current company, we make a tool that enables development managers to take deep dives into things like Cycle Time, what teams are accomplishing, the status of projects, and many other important and hard-to-otherwise-see data about software development. A tool such as this makes it easy to see and find out the information about the old questions, thus enabling the time to be spent on the new, more germaine questions discussed above.

How does being remote affect things?

And of course, there is the question of whether being remote or partially remote changes things. My first thought is — how could it not? If the team is completely remote — a thing that is happening more and more every day — then the daily standup might actually be called the ‘daily zoom-up’. Doing standups online definitely changes the dynamic. Depending on the team size and the video conferencing tool you are using, you may not even be able to see everyone at once. Online standups actually can take less time because you don’t have to walk to and from a room – you do the standup right at your workstation.

Hybrid environments also make for an interesting situation. If some people are at the office and some are remote, you basically have two choices:

1. Have everyone jump on the video conference regardless of location, or
2. Equip a conference room with video conferencing gear to allow remote team members to “be present” in the room on a TV, and to see the room with a web camera.

Personally, I find the second choice to be inferior. It’s too easy for online folks to feel like second-class citizens. By putting everyone on equal footing on the video conference, you can avoid that. I recommend that in a hybrid situation, you go with the first option.

Standups still add value

I still believe that standups add value and are worth the time spent on them. However, I do think it’s time to change the way we extract that value from the meeting. If we use our current tools to communicate what we can, and use the standup to communicate other important information, we can truly turn the daily standup into a valuable and worthwhile activity.