More teams within my company have been adopting the Scrum framework to enhance their product development process. Occasionally, I have the opportunity to engage in conversations with the developers and Scrum Masters from these teams.
Among the various comments and discussions about Scrum, the most common issue raised is the abundance of lengthy meetings. Their managers complain that their teams are spending more time in meetings since implementing Scrum. However, is this issue truly caused by Scrum? When I presented my team’s weekly calendar to them, they were astonished by its brevity and simplicity.
That's all
One colleague shared their schedule with me. Their team begins the Daily Scrum at 09:30, followed by a Code Review until 11:15. There are a few meetings with different purposes in the afternoon. Even if there is a Sprint Review, a progress meeting still takes place weekly. Another colleague told me that she attends a Daily Scrum from 09:15 to 10:00 every day, followed by another Daily Scrum with a different team until 11:00.
There is a misconception that using Scrum means having a lot of meetings. However, according to the Scrum Guide, there are only four events with a container event called Sprint. If we calculate the maximum total time allocated for these events throughout a 4-week Sprint, it should amount to only 20 hours out of 160 working hours. That is merely 1/8 of the total working hours. But what about activities like code review, release review, and progress meetings? They do not exist in the Scrum Guide.
Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.
Scrum Guide 2020
The purpose of Scrum events is to replace traditional meetings. For example, if stakeholders wish to assess progress, the Scrum Team should invite them to attend the Sprint Review, which aims to inspect the outcomes of the Sprint and determine future adaptations. Thus, the need for regular progress meetings is eliminated.
The Daily Scrum is a 15-minute event exclusively for the Developers. It serves “to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.” In one team’s Daily Scrum, I observed managers actively speaking a lot. One developer spent seven minutes talking about the numerous trouble tickets he handled the previous day. Are these details truly worth sharing within this 15-minute event meant for developers only? The Scrum Guide has already eliminated the classic “three questions” format for Daily Scrum since 2020, meaning there could be better ways to facilitate this event. Pull out the Work Item Aging Chart. Address the most ageing item and try to get it done today. This topic would likely yield more value than highlighting the heroic efforts of a developer who resolved trouble tickets the previous day.
When coaching a team that is new to Scrum, I often ask them to read aloud the relevant section of the Scrum Guide before commencing a particular Scrum event. This serves as a reminder of the purpose behind each event. Without a clear understanding of an event’s purpose, it is easy for the team to get off track.