Daily Scrum Anti-Patterns: 20 Ways to Improve

TL; DR: 20 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 the Daily Scrum anti-patterns that threaten to derail your agile transition.

20 Daily Scrum Anti-Patterns — Age-of-Product.com

Update 2019-10-25: Today, I extended and revised the original article to address additional aspects of the topic.

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.

The Purpose of the Daily Scrum

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

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Source: Scrum Guide 2017.

The Daily Scrum is an essential event for inspection and adaption, run by the Development Team, 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 mandatory.

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 Development Team is 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.

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:

  1. 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 stand-up, 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?)
  2. Status report: The Daily Scrum is a status report meeting, and Development Team members are waiting in line to “report” progress to the Scrum Master, the Product Owner, or maybe even a stakeholder.
  3. 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.”)
  4. Problem-solving: Discussions are triggered to solve problems, instead of parking those so they can be addressed after the Daily Scrum.
  5. Planning meeting: The Development Team hijacks the Daily Scrum to discuss new requirements, to refine user stories, or to have a sort of (sprint) planning meeting
  6. 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? Often, the Development Team cannot answer that question immediately. (In that respect, visualizing the progress towards the Sprint Goal is a useful exercise. Removing the Development Team task of maintaining a mandatory burndown chart from the Scrum Guide a few years ago does not imply that a burndown chart is obsolete.)
  7. No use of work-item age: A Development team member experiences difficulties in accomplishing an issue over several consecutive days and nobody is offering help. (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 Development Team has reached an unproductive level as they no longer can support each other. Note: Of course, the Scrum Guide does not mention the ‘work item age.’ However, it has proven to be a useful practice.)
  8. Monologs: Team members violate the timebox, starting monologs. (60 to 90 seconds per team member should be more than enough time on-air.)
  9. 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.)
  10. Disrespect I: Other team members are talking while someone is sharing his or her progress with the Development team. (The use of talking tokens among adults to avoid this behavior does not qualify as a solution in my eyes.)
  11. Assignments: The Product Owner – or even the “Scrum Master” – assign tasks directly to team members.
  12. Cluelessness: Team members are not prepared for the Daily Scrum. (“I was doing some stuff, but I cannot remember what. Was important, though.”)
  13. Let’s start the shift: The Daily Scrum acts as a kind of artificial factory siren to start the next shift. (This is a common Taylorism artifact where trust in the Development Team’s capability to self-organize is missing.)
  14. Disrespect II: Team members are late to the stand-up or do not show up at all. (This poses a massive risk for the Development Team as it is inspecting and probably adapting the plan based on incomplete information thus reducing the probability of achieving the Sprint Goal.)
  15. Excessive feedback: Team members criticize other team members right away sparking a discussion instead of taking their critique outside the Daily Scrum.
  16. 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 Development Team members to nine.)
  17. Talkative chickens: “Chickens” actively participate in the Daily Scrum. (Stakeholders are supposed to listen in but not distract the Development Team members during their inspection.)
  18. Command & control by the management: Line managers are attending the Daily Scrum to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-organizing teams.)
  19. "A word, please”: Line managers are waiting until the Daily Scrum is over and then reach out to individual Development Team members for specific reporting from them. (Nice try. However, this hack is also unwanted behavior and distracts the Development Team.)
  20. 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 Development Team should be aware of those before the Daily Scrum. Otherwise, the composition of the Sprint Backlog is the sole responsibility of the Development Team.)

Upcoming Scrum and Liberating Stuctures training classes and workshops — Berlin Product People GmbH

Lastly, some teams like to have their Daily Scrum in Slack, particularly those that are not co-located. Using Slack does not manifest an anti-pattern per se; it is the prerogative of the Development Team 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 that used Slack as their preferred way of having a Daily Scrum. It worked.)

Scrum Master Interview Question: free download of the most popular ebook on Scrum Master job interviews — by Age-of-Product

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. People seem to be either ignorant (or at least less well educated) about its purpose. Or they — intentionally or not — interfere with the Development Team’s self-organization. One way or another, it is a crucial responsibility of the Scrum Master to help all participants to overcome typical Daily Scrum anti-patterns.

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

✋ Do Not Miss Out: Join the 6,200-plus Strong ‘Hands-on Agile’ Slack Team

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.

Join the Hands-on Agile Slack Group

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.

Daily Scrum Anti-Patterns — Related Posts

28 Product Backlog and Refinement Anti-Patterns

Scrum: 19 Sprint Planning Anti-Patterns.

Why Engineers Despise Agile

7 thoughts on “Daily Scrum Anti-Patterns: 20 Ways to Improve”

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Leave a reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.