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.
Update 2022-03-19: Today, I extended and revised the original article to address additional aspects of the topic, including some food for thought on what constitutes Daily Scrum anti-patterns.
🇩🇪 Zur deutschsprachigen Version des Artikels: 24+2 Daily Scrum Anti-Patterns.
🗳 Update: Join 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!
🇩🇪 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.
Source: Scrum 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 timebox 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.
Cannot see the form?
Please click here
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 timebox, 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?)
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.” Source: Scrum 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?)
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
27 Sprint Anti-Patterns Holding Back Scrum Teams
Scrum: 20 Sprint Planning Anti-Patterns
15 Sprint Review Anti-Patterns Holding Back Scrum Teams
21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams
Download the Scrum Anti-Patterns Guide for free.
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
✋ 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.
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.
You forgot my favorite anti-pattern. Standup Anti-Pattern #17: This article.
Once you start precisely following someone elses view of “waste” without considering and tailoring your processes to your own environment’s unique circumstances, you’ve entirely missed the point. I think many of the suggestions in this article are good practices to consider – but I don’t want to foster an environment where someone is going to have a panic attack because they want to communicate for (more times than not) a very good reason while the team is assembled. Software is hard. People are not robots and typically haven’t worked together for decades. Slack rules.
I agree on this, Dave. A successful stand-up means to me that the team is taking care of its affairs. (And I am mere listening in.)
Give Slack a try, it really appeals to the introverts. (I underestimated that effect in the beginning.)
I love “overlapper”, Louise, will keep that in mind… 🙂
One issue I find particularly egregious is when the scrum master acts as the Master of Ceremonies: introducing the next speaker, playing off someone who is going overtime and deciding for the team what is important and what is not. The scrum master needs to be a facilitator, and sometimes that means he/she must take on some of this. But when it becomes the SOP for the team it is a sign that the scrum master does not trust or believe the team can organize itself around the priorities.
Oh, yes, all of th raisedese. In my mediation work I’ve seen some of these same anti-patterns. Over the years, I’ve observed why people develop these antipatterns.
6. Team members violate the time-boxing, starting monologs.
Some of my clients don’t know how to speak about just the most important points about their case. They’ll tell every little detail, plodding along in a boring way.
Other clients are so concerned with making sure they explain themselves clearly, that they’re never satisfied with their first explanation, so they explain themselves a second time, then they’re not satisfied with that, so they explain themselves a third time… and on and on.
Another reason why this anti-pattern shows itself is that people have different conversational styles and standards. Some of my clients who repeat themselves or give a monologue, they’re waiting for the other person to interrupt them and say that they understood their point. But the other person’s conversational style doesn’t include interrupting people, so they don’t say anything, and the person giving the monologue keeps going.
As a mediator, I can point out to my clients that we don’t need every detail at first, that they should talk about the most important points, and we’ll talk about the rest later. I coach them again about this if they do it again.
The clients who are trying to come up with the best explanation, once I notice this anti-pattern, I’ll say something when they start their second explanation. Something approving like, “That’s a good point. You’ve made it very clearly.” Then I say something to move the conversation on.
And if clients have different conversational styles and standards, as soon as it becomes a problem, I point it out. Even if one of the clients is being rude, I still express the problem as a difference in conversational styles. I usually say, “Client A, I notice that you’re a turn-taker in conversations, but Client B, I noticed that you’re an overlapper. Client B, Client A would like to finish everything they have to say before you start talking, and Client A, if Client B starts talking, they’re not intending to interrupt you.”
Some of these interventions I can do during a joint session, but as a Scrum Master, from what I’ve learned, you’d probably wait it out during a few standups, and then tell the team you’ve noticed a problem, and would they like to hear a suggestion for resolving it. Or else to talk to the team members in private.
Offshore teams with ineffective communications abilities (technological and verbal). That is not to be racist, it’s a fact of life. I recently worked on a team which had outsourced some of the development. The IT Director wasn’t sure two of the four offshore employees existed, as they didn’t speak, all communications were relayed via one of the two other offshore team members.
When I turned up and assisted with improvements to the agile scrum set up, I quickly discovered that two of the employees could barely speak English. So even in a stand up we had chinese whispers going on!
I have struggled with stand-ups and agile in general with offshore teams convincing management to bring the team in house.
Perhaps this is a failing of mine in investigating other methods, i.e. As mentioned in the article, using Slack.