What Happened to the Daily Standup?

I started my career in a previous century, with project plans that were two months of analysis, two months of design, four months of code and two months of testing. We would work on three to eight projects at a time, all at different stages. Once a week we would go to a status meeting, where people tuned out most of the time until their turn. Then, during their turn, they’d typically point fingers at someone else for the delays while making themselves look good. As someone once observed, the meeting was really about the status of the manager. The Daily standup were supposed to fix all that. They were a breath of fresh air: a meeting dedicated to actually figuring out what was going on and fixing it, all in the workspace, so we could get back to work.

When I started doing standups as a project manager in 2005, we invited the customer in. They could see exactly what we were working on, and the complaints about things taking too long stopped as the customer understood our backlog. Not many people embraced the idea of the standup at the time, but they were wonderful.

Now, suddenly, everyone does them and they are silly. Most of the time, when it is not their turn, people tune out. Then, during their turn, they point fingers at everyone else while making themselves look good.

The language has changed to “what I did, what I am doing, and how I am blocked,” but the behaviors are the same: We turned the standup into a status report.

But that wasn’t what the standup meeting was supposed to be. Let’s talk about how to fix it.

What the standup was supposed to be

If you want a status report on your work in progress, you don’t need a standup — at all, ever. You can just look at the cards on the wall or in the tool. Most modern tools track the number of days a story has been in progress, so you don’t need that “blocked by” stuff; you can just check on any card that has an in-progress duration getting longer than the average cycle time for a story.

For that matter, if a team member or pair is blocked, shouldn’t they escalate the issue themselves? Shouldn’t everyone on the team know what to escalate to whom if they are blocked? Shouldn’t that happen immediately? If the standup is at 8:00 a.m. and someone is blocked at 9:00 a.m., why wait almost an entire business day to bring up the issue?

If the view is that the daily standup is a status update, then it is entirely redundant. The other tools of modern software make all that information freely available. To paraphrase Shakespeare, I came to bury it, not to praise it.

But that wasn’t the goal. The goal of the standup is to accelerate the sprint.

Think about that for a moment.

Imagine a team that is actually functioning. Instead of worrying about “my work” or “your work,” we worry about getting the most work possible done this sprint. Instead of tuning out, we actually listen. When a team member talks about needing to test a complex user interface, someone notices, and points out that there are tools to do command-line setup. The setup doesn’t have to be manual, and the automation doesn’t have to do it; you can just call half a dozen commands and test the actual change, not the setup. This sort of “I can help you do that” behavior happens all the time with groups that are actually a team.

As it turns out, most teams know a large number of tips and tricks; they are just distributed across individuals. Sally knows some obscure SQL commands, Joe knows how to do functional programming in Java and C#, and Bob knows how to write little snippet programs that manipulate test data. If we can distribute that knowledge to the team, we can speed everything up. This runs totally contrary to the ideas of the previous century, when we got people to specialize and focus only on what they know.

Why the standup failed

If I had to list a single reason the standup failed, it would be the failure of companies to adopt pair programming in the early 2000s. The idea was just too revolutionary. Instead of Extreme Programming, the Scrum framework “won” the methodology wars. In my opinion, Scrum mostly won because it didn’t really require much — just that teams start working in sprints. Scrum allows for technical specialists and didn’t come with a thick, prescriptive list of rules that must be applied.

In my experience, that’s mostly the way of it. Something new and shiny and challenging comes out, the crazy rebels try it, and it is amazing. Eventually the idea has enough success that the larger organizations want it, but they don’t really want their worldview challenged. It’s easy enough to say, “Oh, we were really doing this before; this is just with new names.” The team adopts Scrum, project managers become “ScrumMasters,” the status meeting becomes a standup, and everything keeps going mostly as it was before.

Just know that wasn’t the way it was supposed to be.

What to do about it

I’m going to go out on a limb here and guess that if you are reading this, then you “get it.” You realize that team success is ultimately about the flow of value to the customer. Software teams deliver that value primarily through working software. It is not test cases, lines of code or stories created that have value to the customer.

That means shuffling work out of your box into someone else’s is … nothing. Under the Toyota Production System (TPS), if that work builds up because it cannot be released to the customer yet, it is worse than nothing. Under TPS, excess inventory in progress is waste. So you want to deliver value to the customer.

Assuming that is true, if the standup is a waste of time, then it is a waste of time. It would be better to stop doing it — or to save it. In 2014, I wrote How to Save the Daily Standup Meeting, about bringing value back. Half a dozen years later, I’ve understood how things fell apart a great deal better, and I can explain the purpose of that meeting.

And now, so can you.

Thanks to the coronavirus, a lot of us are working remotely, which means we no longer have the luxury of screwing around during the standup and figuring it out around our desks later. If your daily standup is a waste of time, save it or ditch it. Just stop the waste.

Ain’t nobody got time for that.

 

About the Author

Matt Heusser is a former board member of the Association for Software Testing and the 2014 CAST Keynote Speaker. The 2014 recipient of the Most Influential Agile Test Professional Personal Award (MIATPPA) award, Matt is also the creator of the Lean Software Delivery family of methods and probably best known for his writing.