Skip to main content

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

March 21, 2022

TL; DR: 24+2 Daily Scrum Anti-Patterns

In my experience, the Daily Scrum is the Scrum event with the highest anti-pattern density among all events. Learn more about Daily Scrum anti-patterns that threaten your Scrum team’s success, from becoming a reporting session to assignments to answering these three questions.

Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team

🇩🇪 Zur deutschsprachigen Version des Artikels: 24+2 Daily Scrum Anti-Patterns.

🗳 UpdateJoin the poll and its lively discussion on LinkedIn.

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 34,000-plus subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

Download the Scrum Master Salary Report for Free

🇩🇪 Zur deutschsprachigen Version: Scrum Master Gehalt 2022 — die Umfrageergebnisse.

The Purpose of the Daily Scrum

The purpose of the Daily Scrum is clearly described in the Scrum Guide — no guessing is necessary:

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.

SourceScrum Guide 2020.

The Daily Scrum is an essential event for inspection and adaption, run by the Developers, and guiding it for the next 24 hours on its path to achieving the Sprint Goal. The Daily Scrum is hence the shortest planning horizon in Scrum and thus highly effective to guide the Scrum team’s efforts. 

Contrary to popular belief, its 15-minutes time-box is not intended to solve all the issues addressed during the Daily Scrum. It is about creating transparency, thus triggering the inspection. If an adaption of the plan or the Sprint Backlog, for example, is required, the Developers are free to handle the resulting issues at any time. In my experience, most Daily Scrum anti-patterns result from a misunderstanding of this core principle.

Download the ’Scrum Anti-Patterns Guide’ for Free

Daily Scrum Anti-Patterns – From Dysfunctional Scrum Teams to Organizational Failures

Typically, a good Scrum Team won’t need more than 10 to 15 minutes to inspect its progress towards the Sprint Goal. Given this short period, it is interesting to observe that the Daily Scrum is often so riddled with anti-patterns. The anti-patterns often cover a broad spectrum, ranging from behaviors driven by dysfunctional Scrum teams to apparent failures at an organizational level.

My unprioritized list of notorious Daily Scrum anti-patterns is as follows:

Daily Scrum Anti-Patterns of the Scrum Team

  • Orientation lost: The Daily Scrum serves one purpose as it answers a simple question: Are we still on track to meet the Sprint Goal? Or do we need to adapt the plan or the Sprint Backlog or both? Sometimes though, the Developers cannot answer that question immediately. (In that respect, visualizing the progress towards the Sprint Goal is useful. Removing the Developers’ task of maintaining a mandatory burndown chart from the Scrum Guide a few years ago does not imply that such a visualization is useless.)
  • Status report: The Daily Scrum is a status report meeting, and Developers are waiting in line to “report” progress to the Scrum Master, the Product Owner, or maybe even a stakeholder. (The “three Daily Scrum questions” often serve as a template for this anti-pattern.)
  • No routine: The Daily Scrum does not happen at the same time and the same place every day. (While routine has the potential to ruin every Retrospective, it is helpful in the context of the Daily Scrum. Think of it as a spontaneous drill: don’t put too much thought into the Daily Scrum, just do it. Skipping Daily Scrums can turn out to be a slippery slope: if you skip one Daily Scrums or two, why not skip every second one?)
  • Disrespect I: Other team members are talking while someone is sharing their progress with the Developers. (The use of talking tokens among adults to avoid this behavior does not qualify as a solution in my eyes.) 
  • Disrespect II: Team members are late to the Daily Scrum or do not show up at all. (This failure poses a massive risk for the Developers as they are inspecting and probably adapting their plan to accomplish the Sprint Goal based on incomplete information, thus reducing the probability of achieving the Sprint Goal.)
  • Excessive feedback: Team members criticize other team members right away sparking a discussion instead of taking their critique outside the Daily Scrum.
  • Overcrowded: The Daily Scrum is ineffective due to a large number of active participants. (There is a reason why the Scrum Guide recommends to limit the number of team members to ten.)

Anti-Patterns of the Developers

  • Cluelessness: Developers are not prepared for the Daily Scrum. (“I was doing some stuff, but I cannot remember what. Was important, though.”)
  • Planning meeting: The Developers hijack the Daily Scrum to discuss new requirements, refine user stories, or have a sort of (Sprint) Planning Meeting, probably collaborating with the Product Owner.
  • Problem-solving: Discussions are triggered to solve problems, instead of parking those so they can be addressed after the Daily Scrum.
  • Monologs: Team members violate the time-box, starting monologs. (60 to 90 seconds per team member should be more than enough time on-air.)
  • Statler and Waldorf: A few team members are commenting on every issue. (Usually, this is not just a waste of time, but also patronizing and annoying.)
  • Ticket numbers only: Updates are generic with little or no value to others. (“Yesterday, I worked on X-123. Today, I will work on X-129.”)
  • No impediments: No one reports any obstacles; no one needs any help or support from their teammates. (Congratulations on your seemingly well-oiled machine! However, maybe, Developers do not feel safe to address issues, challenges, or problems?)
Download the Scrum Guide Reordered for Free

Daily Scrum Anti-Patterns of the Product Owner

  • Assignments: The Product Owner assigns tasks directly to team members. (The Developers self-organize their work: “No one else tells them how to turn Product Backlog items into Increments of value.” SourceScrum Guide 2020.)
  • Additional work: The Product Owner or even other stakeholders attempt to introduce new work to the current Sprint during the Daily Scrum. (This behavior may be acceptable for high priority bugs, although the Developers should be aware of those before the Daily Scrum. Otherwise, the composition of the Sprint Backlog is the sole responsibility of the Developers: they may accept new work during the Sprint; however, that is their sole decision.) 

Anti-Patterns of the Scrum Master

  • Daily Scrum enforcer: The Scrum Master is enforcing the Daily Scrum. (It is the task of the Scrum Master to ensure “[…] that all Scrum events take place and are positive, productive, and kept within the timebox.” (Source.) However, if none of the Developers believes that Daily Scrum is a sound investment, the Scrum Master cannot simply compensate for this lack of intrinsic motivation by using the Scrum Guide as a forcing function. They need to help to create the motivation on the side of the Developers to run the Daily Scrum in the first place. Enforcing the Daily Scrum is a common Taylorism artifact where trust in the Developers’ capability to self-organize is missing.) 
  • Not supporting struggling Developers: A Developer experiences difficulties in accomplishing an issue over several consecutive days and nobody is offering help. Moreover, the Scrum Master fails to facilitate the necessary discussion. (Often, this result is a sign that people either may not trust each other or do not care for each other. Alternatively, the workload of the Developers has reached an unproductive level as they no longer can support each other. The use of ‘work item age’ has proven to be a helpful practice.)
  • Not preventing stakeholders from attendance: Although the Developers decided to limit attendance to the Daily Scrum to the Scrum team members, stakeholders show up uninvited, and the Scrum Master is not addressing the issue. (It is the Developers' prerogative to decide how to run the Daily Scrum. If they choose to keep stakeholders away from it, this decision needs to be respected by everyone else. If stakeholders fail to do so, the Scrum Master needs to step in.)
  • Not enforcing the time-box: The Developers extend the Daily Scrum regularly beyond the 15-minute time-box. (This is unfortunate, as the extension of the time-box invites problem-solving and other activities into the Daily Scrum, thus distracting from answering the critical question: are we still on track to accomplish the Sprint Goal?)
Download the Remote Agile Guide for Free

Daily Scrum Anti-Patterns of the Stakeholders

  • Command & control by the management: Line managers attend the Daily Scrum to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-managing Scrum teams.)
  • "A word, please”: Line managers are waiting until the Daily Scrum is over and then reach out to individual Developers for specific reporting from them. (Nice try. However, this hack is also unwanted behavior and distracts the Developers.) 
  • Talkative chickens: “Chickens” actively participate in the Daily Scrum. (Stakeholders are supposed to listen in but not distract the Developers members during their inspection.)
  • Communicating via body language: Formally, stakeholders remain silent. However, they participate in the Daily Scrum via their body language. (Again, stakeholders are supposed to listen in but not distract the Developers. Yet rolling eyes and face-palming are as powerful as the spoken word. Moreover, even subtle forms of body language represent communication, as one cannot “not communicate.” Furthermore, some stakeholders may have a naturally intimidating presence that can prove harmful to the communication among the Developers.)

🤔 Food for Thought

There are some issues that are worthwhile considering as a Scrum Team:

Synchronous and asynchronous Daily Scrum events: Some teams like to have their Daily Scrum in Slack, particularly those not co-located. But, of course, using Slack does not manifest an anti-pattern per se; it is the prerogative of the Developers to run the Daily Scrum in any fashion that serves its purpose: inspect the plan for the next 24 hours to meet the Sprint Goal. I was even working with a co-located Scrum team—sitting around a large table—that used a synchronous Slack session as their preferred way of having their Daily Scrum. It worked well. But what about an asynchronous Daily Scrum in Slack?

Substituting the Daily Scrum: What about the idea to skip the Daily Scrum altogether, as the Developers are heavily using more or less automated messaging systems on most aspects of their daily work, while they can handle the rest during other events, for example, pairing or mobbing sessions? Is it beneficial to allocate 15 minutes every day to the Daily Scrum under these circumstances? Or is that mere dogmatism? 

Daily Scrum Anti-Patterns — Conclusion

Given the importance of the Daily Scrum for the success of the Scrum Team’s effort of achieving the Sprint Goal, its anti-patterns density is no surprise. Unfortunately, people seem to be either ignorant (or at least less well educated) about its purpose. Or they — intentionally or not — interfere with the Developers’ self-organization. One way or another, it is a crucial responsibility of the Scrum Master to help all participants overcome typical Daily Scrum anti-patterns.

What Daily Scrum anti-patterns have you observed? Please share those with us in the comments.

📖 Related Posts

28 Product Backlog and Refinement Anti-Patterns

Scrum: 20 Sprint Planning Anti-Patterns

27 Sprint Anti-Patterns Holding Back Scrum Teams

21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams

Download the Scrum Anti-Patterns Guide for free

✋ Do Not Miss Out: Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Team and Learn more about Daily Scrum Anti-Patterns

I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

Membership Application for the Hands-on Agile Slack Community

If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.

The article “Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team” was first published on Age-of-Product.com.


What did you think about this post?