Why Software Engineers hate standups
And why I think you should have them anyway
Recently I’ve seen an upward trend in developers sharing their dislike of stand-ups. The majority of them have valid concerns, and they are quite right to point out the drawbacks that can sometimes come with it, namely that of context switching. But generally speaking, the reasons against stand-ups that I hear about are often hypothetical scenarios which aren’t true all the time or from ‘hero’ developers who don’t really want to work in a team to begin with. My issue more broadly is that these examples get taken out of context and are presumed to be the de facto reasons why stand-ups should not exist at all for any team. In this article I want to talk about some of these concerns, some actionable takeaways, and why I think stand-ups can actually be beneficial for teams.
Context switching
For anyone who doesn’t know, context switching (in humans at least) refers to the drop in productivity that comes from switching tasks. For software engineers, more complex tasks can create heavier amounts of cognitive load which takes time to build up. Interrupting a developer after this time investment therefore leads them to have to repeat this process to get back into a productive state. As you might imagine, we’re trying to avoid as much of this as possible. The below chart helps to illustrate this:
Granted, this is a bit of an exaggeration on my part (and in part due to my lack of skills on Excalidraw) but it paints a pretty good picture as to why many developers dislike the stand-up when all they see is a productivity killer. I’ve seen this problem before and even experienced it myself at times. But the answer was always straightforward to me. The solution? We simply moved stand-ups to earlier in the day. That’s all it took. Instead of the usual 10am after people had ramped up a bit, we moved it to 9:15 (9am was a bit too ambitious) to get it out of the way. That way you’ve got clear runway until you stop for lunch.
As an aside, the other problem I saw with stand-ups starting at 10am wasn’t just the context switching. After Covid and the switch to remote working, I had noticed that some people were starting their work increasingly later, right up to the point of stand-up starting. It was as if they had already written off the morning since they ‘couldn’t possibly be productive anyway’ - now, those people were in the minority sure, but it did become a pattern for some. At this point it’s worth clarifying that I’m not a clock watcher type of manager, and I fully support flexibility for people’s working hours. I don’t mind if you want to start late one day and finish later another, etc. You are accountable for your own work - but if you’re going to chop an hour out of your day every day, then I’m probably going to call you out on it.
So by moving it to the start of the day we eliminated the productivity problem, everyone starts the day with a plan (even if that plan is the same they had yesterday) and we don’t take longer than we need to - and yes that sometimes means stand-up takes 2-3 minutes. Great!
Information exchange
The second most common issue that I hear about is more general, in that they don’t see much value in the information that gets exchanged in these meetings. E.g.:
People’s progress on tasks
People’s plan for the day
Reporting of any blockers
With the arguments typically being:
As a developer, I don’t need to hear updates on other tasks or plans that aren’t relevant to my own.
As a team, we shouldn’t wait until the morning stand-up to bring up blockers.
Again, completely valid concerns… that I somewhat disagree with.
I can’t argue that if my task is completely different from yours that it’s always relevant to you, but that example isn’t always the case. Software Engineering is after all a team sport and it’s not unheard of for multiple people to be working on the same feature. Or maybe it’s someone working on a service you know in depth, even if you’re busy on something else - your insight could save them a ton of time at the cost of a couple of minutes of yours. That’s a pretty good trade in my view. And when it comes to people’s plans for the day, what if I’m nearly done and you need a hand finishing up? That nugget of information you shared with us now helps me have a plan for the day: ‘I’m going to finish this this morning then I can pair with you after lunch to get your task over the line’.
As for blockers, well I think that’s more of a ‘it depends’ answer. Are you blocked entirely? Don’t wait for the stand-up of course. Are you partially blocked but can get on with something else related to your task in the meantime? Probably a good one for stand-up. Do you just need some help? Definitely don’t wait for the stand-up!
Format
I’m not saying that the stand-up format has to stay the way it is, if you’ve ever worked with a distributed team across time zones then you’ll know the difficulty of getting an overlapping timeslot that works for everyone. Having an async stand-up can absolutely work in these scenarios too and can be done easily in Slack or Teams and people can write them up at a time that better suits them too. You might well question if it’s still a stand-up at that point, and maybe it strictly isn’t but you are making a coordinated effort to discuss and plan which makes it a stand-up in my book.
I know some people are going to read this and still say ‘we don’t need a stand-up, I trust my team to raise any issues as they come up and they can grab tasks off the backlog’ and that’s great. Maybe you don’t need a daily stand-up because you have great refinement or backlog grooming sessions? Really what I’m advocating for here is keeping teams in sync and coordinated on a regular basis, and stand-ups square most of that away for me. I find that in software engineering things tend to change quickly enough to warrant a daily stand-up; but in your team, maybe that’s not the case. If it’s not broken then absolutely don’t try and fix it, what works for one team won’t always work for another. I personally lean towards having a stand-up as a default as I think that applies to most software engineering teams, but your experience may differ.
There’s a couple of points we didn’t cover in this post like the benefits that junior engineers get from interacting with and hearing from seniors discussing their work; and even just the simple human interaction. If you’re working remotely, that stand-up might just be the only point of contact for someone that day, surely you can spare them a few minutes to grab yourself a coffee and say good morning? Stand-ups aren’t there solely for team productivity, or because some manifesto tells you to do it. They are daily opportunities to connect with your team as individuals as well.
Takeaways:
If you’re concerned about context switching, change the stand-up time.
Don’t be afraid to cut meetings short if you need to.
Remember that information sharing is almost always beneficial.