The daily scrum stand up meetings need to end.
– Me, for the last 5 years
There, I said it. Actually I’ve been saying it for a long time but most in software engineering leadership and project management don’t want to hear it. The vast majority of the daily scrum stand up meetings that organizations are doing are a complete waste of time. Many in software engineering leadership tell us that stand up meetings are a crucial part of communicating between team members and staunchly defend them. Project managers sometimes believe that they must have these meetings to keep informed on what the team members are doing. Agile purists just must have the meetings because “that is the way” (apologies to Din Djarin). I think that they are all wrong.
Three Problems with Stand Up Meetings
Context Switching Kills Productivity
Daily standup meetings require engineers to stop what they are working on at an arbitrary time to attend. Anyone who has ever written software knows that it takes a tremendous amount of cognitive effort. It takes time and effort to adequately understand a task and begin to craft a software solution in your mind. The further an engineer gets into attempting to solve that problem, the more context their brain manages. Having to switch contexts at specific time to go to a meeting severely impacts the engineer’s progress toward solving the problem. When the meeting is over, it takes another significant amount of effort to “re-load” the previous context and continue working. Furthermore, a frequent situation arises where an engineer finishes a task, sees a stand up meeting on the calendar coming up shortly, and it doesn’t make sense to get started on their next task because they’re going to have to stop soon. That’s just wasted, unproductive time that could have been used if not for a daily meeting on the calendar.
Better Communication Tools Exist Today
My colleague Rex and a couple other engineers have been working on some items for me over the last few weeks. Last week he pinged me in Slack with this question: “do we have a standup?”. My reply surprised him I think when I said “no, I hate them”. He laughed (at least via chat), and we continued discussing the issue. He made an incredibly astute observation:
“I think the Agile process was created pre-chat era before it was widely used as a communication medium in the business world.”
Yes! I hadn’t considered that honestly. I’ve been a full-time work-at-home person since 2001 so text chat of some sort has been ingrained in my daily routine for literally decades (Yahoo Messenger, ICQ, or AIM! anyone?). I didn’t stop to think about the fact that agile software development practices including Scrum had been around since the early to mid-80s. For those of you reading this that weren’t alive in the 80s, there was no internet (gasp!), ergo, there were no chat systems like we have a plethora of today. The stand up meeting was much more important communications medium then. Nowadays, we type messages and make them available to one person or hundreds of people sometimes hundreds of times per day already. We don’t need yet another meeting.
The Purpose They Serve is Redundant
“DRY” (Don’t Repeat Yourself) is a term that most software engineers are familiar with. This saying has implications beyond the code engineers produce. Don’t waste time telling the same thing to multiple people, tools, or groups over and over. The information on what each engineer is working on is already available in the ticket tracking system for any who may want to know. Many stand ups I have been a part of in the past literally use the Jira (RedMine/Trello/insert-tool-here) scrum board as an “agenda” for the stand up meeting. Those that don’t often fall back on the “yesterday, today, any blockers” method of moving the meeting along. The yesterday and today information is in the ticketing system. If an engineer has any blockers, contact someone right away instead of waiting for the next stand up meeting (most engineers do this anyway, and then have to repeat themselves at the next standup meeting). The bottom line is to not spend time and effort doing something you’ve already done somewhere else.
My Alternative to Stand Up Meetings
Below are my 4 recommendations for replacing the useless (in my opinion at least) daily scrum meetings.
Go Asynchronous
Have a (Slack/Teams/etc) channel dedicated to status updates for your team. Appoint someone, possibly the project manager, to start a new thread every day for that day’s updates. Then, tell your engineers that they can post their update to the thread whenever they reach a natural break point in coding. This gives a central location where anyone that needs to see an update can go. It also allows the engineers to “mute” the channel so they aren’t interrupted when other engineers post updates and stay in the context of their current work longer.
Document Decisions in the Ticket Tracker
Chat systems are wonderful tools for quickly resolving questions on things engineers are working on. However, more often than not, that conversation eventually gets lost to the ephemeral nature of the chat environment. Sure the interaction is available via search, but that assumes the person needing the information remembers what keywords to search for or was involved in the original chat at all. Make sure to emphasize transcribing a record of that decision-making process into a longer-lasting tool, such as your departmental/company wiki or even as a comment on the issue in your issue tracking system. This eliminates having to take time to explain when someone asks and forms a more “permanent record” for the decision or issue resolution.
Tell Your Engineers to Ignore You
Encourage your engineers to block calendar time for tasks and allow them the freedom to ignore you and everyone else during that time frame. You can even go so far as to make this a team exercise to figure out some guidelines around this. For instance, your team may agree to check email and messaging a minimum of 3 times during the day but the rest of the day be unavailable to unscheduled interruptions. This forces you as the engineering manager to trust your people, sure. However, if you have the right people, you’ll find that placing this kind of trust in them increases the quality of their work as well as their overall satisfaction with their job.
Have a Meeting
“Wait a minute!” I hear you saying out there. “You have just spent the entire article telling us to get rid of meetings!”. Yes, sort of. While I am definitely against daily scrum meetings, it is still important for your team to meet and discuss things. You likely have some other “ceremonies” scheduled around sprint planning, retrospectives, and backlog refinement, but I’m not talking about those either. Take some time each week to get together as a team in a meeting that is specifically and purposefully not a status update. Talk about some cool tech you saw, a MeetUp you went to, or even a hobby you enjoy. The purposes of these meetings is to make sure you are all staying connected as teammates. Humans are social beings (software engineers sometimes less so, but stay with me). All the productivity tools in the world won’t help if you are lonely, burned out, or don’t feel connected to your team. Take care of each other and watch your team’s productivity grow.
Header image courtesy of Mario Gogh at Unsplash.