Your daily standup, meeting, scrum, or whatever you call it might seem like a sacred ritual that you cannot break. After all, it’s one of the key scrum ceremonies.
The vast majority of technology and product companies have a daily meeting in one form or another. You could even say it’s like a package deal for any IT job.
But should it? This article explores the premise of daily standups and whether they deserve the role that product teams give them.
According to the scrum guide, daily scrum improves communication, helps to identify impediments, and promotes quick decision-making, effectively eliminating the need for other meetings.
In theory, it should be a meeting that fine-tunes the team alignment and facilitates collaboration. Scrum assumes that daily meetings provide great return on time invested.
Sadly, the results often differ.
Your daily meeting can easily become a Jira “show and tell” where each team member goes through their tickets on the board (something you could easily read yourself). This quickly becomes a boring status update meeting.
Some could say we must level up our game and “do better.” But let’s be honest, are there that many topics that require daily alignment to justify the investment? Likely not.
Besides that, daily meetings might be fifteen minutes long on paper, but in practice, they’re more time-consuming. Meetings distract you, consume energy, and introduce the “I have a meeting in seven minutes, so it’s not worth it to start a new task now” syndrome.
Let’s do math for an eight-person team:
15 minutes of daily time + 15 minutes of productivity lost x eight team members x 22 days in a month / 60 = 88 hours
Now, if you consider that one hour is worth roughly $75 (whether in salary or agency fee), you’re investing $6,600 in daily meetings per month. With that budget, you could hire a new team member.
Taking it all into account, my team decided to run an experiment.
The rules were simple: ditch all daily meetings and do ad-hoc huddles whenever necessary.
Initially, we agreed to post a written update at the end of every day on our Slack channel, but after two weeks, we realized it didn’t give us enough value, so we ditched that too. One could always look at the Jira board.
We ran this experiment for four weeks before making a pivot.
In those four weeks, we learned a lot about the value of daily meetings. These findings grouped into three categories:
Surprisingly, the team’s happiness increased significantly. Although we didn’t quantify it, everyone agreed that they felt somewhat more satisfied now. People could start and finish the work any hour without the need to adhere to a specific time slot, and on many days, they could be in “flow” mode for a whole day without interruptions.
Productivity actually increased. Our velocity grew by roughly 5-10 percent, although that’s hardly statistically significant, so treat it with a grain of salt.
I won’t lie to you; as a PM, the lack of daily meetings made me nervous. As much as I trusted my team, not only did I have this nagging “what if something is off track and I don’t even know?” thought in my head, but I also had problems confidently dealing with stakeholders. I simply wasn’t sure what was going on in my initiatives, and others noticed.
The team integration suffered quite a lot. During daily meetings, we often went off track, small-talking, sharing gossip, and just having casual conversations. As ineffective as this might sound, it helped us bond as a team.
Without these daily interactions, we felt more and more like a group or individual people and less like a team.
After two sprints, we decided to pivot our approach and find a sweet spot that would still give us the benefits of no dailies while mitigating the problems we encountered.
Ultimately, we settled for having meetings twice a week.
During these meetings, we did the usual standup stuff, but we also made them 30 minutes long to give us ample time to chill together and talk about anything we wanted.
It still gave us three days a week of “no daily” benefits, reducing the overall time investment needed while allowing us to integrate as a team. It also helped me stay on track with the team’s daily work.
We would probably keep experimenting to optimize our meeting cadence further, but sadly, the project ended soon after, and the team was disbanded.
So, do I recommend skipping dailies? Not really.
It worked very well in our specific context, but it may or may not work for you.
However, the key here is to not be afraid to break the rules every once and a while. Whatever framework or methodology you use, don’t treat them as set in stone.
Instead, keep identifying problems and experiment with different approaches, even if they are far from what the rest of the company or industry is doing. Frameworks are just starting points. Don’t limit your options just because some book says so.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
To help demystify stakeholder management, you can use tools that introduce a structured approach for your product team.
Role-definition frameworks like RACI, RAPID, and RASIC take a structured approach to assigning roles and clarifying accountability.
Jann Curtis talks about understanding your audience’s purpose and what they hope to get from the conversation.
Scaled agile is an approach that allows you to extend agile principles across multiple teams, projects, or business units.
Learn more →
