I. We Will Not Inflict Daily Standups on Our Devs

Daily standups are as ubiquitous as they are stupid. I’m amazed that such an expensive and disruptive activity has become commonplace. Daily standups guarantee that your devs will never have a single full day of meaningful work. This is a steep price to pay.

Yes, yes, I know standups help devs be productive. They increase transparency, highlight blockers, improve alignment, etc. … Even if I were to accept those things as true, standups are an irresponsibly expensive way to achieve those goals.

Why are standups expensive? Presumably, you didn’t hire engineers because you had a bunch of empty meeting rooms. Your customers and clients needed features and fixes. You hired devs to build. Any time spent in standups is time not spent building.

If you have four devs standing around for 15 minutes every day, you are losing more than 20 hours of building time every month, at a minimum. Every single month, your product could have a new feature that pulls in revenue or reduces customer churn, but instead you just throw that opportunity in the trash.

The sad truth is that it’s way worse than this. Standups are supposed to only be 15 minutes long. In fact, that’s why they’re called standups: Their primary selling point is that they are short. Unlike other meetings, devs have to remain standing so that they don’t get too comfortable and drag the meeting out.

I’d like to pause here to reflect on how bonkers this is. We’ve all agreed that by its very nature, this type of meeting is inefficient, and our solution is to make it even more uncomfortable. I’m surprised nobody has suggested standing on hot coals to make them even quicker.

Unfortunately, even if we make standups uncomfortable enough to limit them to 15 minutes, their damage will always exceed that time. Why? Your devs can’t and won’t be productive right up until the standup starts and immediately after it ends. There are two main reasons for this: First, context-switching takes time; and second, devs will avoid working on anything complicated if they know they’re about to be interrupted.

Think of software development as working at the bottom of the ocean. It takes the dev time to put on their scuba gear, check their oxygen tanks and seals, and slowly descend. Once they’re down there, they can be highly productive. However, any interruption that causes them to surface, swim to the boat, and take all their gear off to have a conversation is hugely disruptive. If you knew you were going to get interrupted in 10 minutes, would you dive down or just wait in the boat? I’d wait in the boat.

So what does this mean? It means that even if you used next-gen torture techniques to pare the meeting down to a single minute, you’d have at least 30 minutes of disruption on either side. In other words, the absolute minimum cost of a single standup is more than an hour per dev. If you stick to 15 minutes per meeting, you’re losing more than 100 hours a month of productive time with a team of four.

What do standups give us in exchange for all that lost productivity? There’s an argument to be made that work is useless if it’s on the wrong things. Meetings and planning are essential to make sure that devs are working on the correct priorities. Is it possible that engineers lose 15% of their working hours to standups but become 20% more effective? It’s possible but unlikely.

One promise of standups is that devs will take accountability for their work. There’s no better pressure than peer pressure, and surely no dev would slack off for a day knowing they’d have to admit that to their team. If you’ve actually been to a standup before, you’ll know that devs can make the simplest tasks sound like epic accomplishments. Of course, that’s assuming anyone is even paying attention.

Another benefit of standups is transparency and alignment. When Alice describes what she’s working on and mentions a blocker, Bob can take note and adapt if it affects the project he’s responsible for. I’m not going to say that this never happens. But I will confidently say that no dev wakes up in the morning excited to listen to another dev talk about their previous workday. If you expect Bob to always give Alice his undivided attention, brace for disappointment.

The biggest standup wins are when one dev can save another dev time and frustration. If Bob mentions that he’s going to be adding a new OCR library to the app, and Charlie happens to know that the library is a tire fire and will be a gigantic waste of time, that’s a hugely valuable warning. If Charlie saves Bob 25 hours of hassle, he just “paid” for a whole week of standups right there. I wonder if standups are popular for the same reason people like slot machines.

If this depresses you, I have good news: You can get all the benefits of standups without the costs. Nothing is stopping you from holding your devs accountable or from sharing what each dev is working on with your team. Nothing stands in the way of devs alerting their teammates to blockers. All of these actions are possible without adding a daily interruption to everyone’s calendar.

results matching ""

    No results matching ""