16 Stand-up Anti-Patterns Threatening Your Transition to Scrum

TL;DR: 16 Stand-up Anti-Patterns

The daily stand-up is the ceremony with the highest anti-pattern density among all scrum ceremonies. Learn more about the stand-up anti-patterns that threaten to derail your agile transition.

Hands-on Agile: 16 Stand-up Anti-Patterns Threatening Your Transition to Scrum

Stand-up Anti-Patterns – From Dysfunctional Scrum Teams to Organizational Failures

Typically, a good scrum team needs about five to ten minutes for a stand-up. Given this short period, it is interesting to observe that the daily stand-up is the scrum ceremony with the highest potential anti-pattern density. The anti-patterns range from behaviors driven by dysfunctional teams to apparent failures at an organizational level.

My favorite stand-up anti-patterns are as follows:

  1. No routine: The stand-up 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 stand-ups. Think of it like a spontaneous drill: don’t put too much thought into the stand-up, just do it. Skipping stand-ups can turn out to be a slippery slope. And skipping may only be acceptable the day after the sprint planning. However, please keep in mind that every team member can veto skipping the stand-up.))(Updated 2017.4-24.)

  2. Status report: The stand-up is a status report meeting, and 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 stand-up

  5. Planning meeting: The team hijacks the stand-up to discuss new requirements, to refine user stories, or to have a sort of (sprint) planning meeting

  6. No red dots: A team member experiences difficulties in accomplishing an issue over several consecutive days, and nobody is offering help. (This a sign that people either do not trust each other or that the utilization of the team is maximized.)

  7. Monologs: Team members violate the time-boxing, starting monologs. (60 to 90 seconds per team member should be more than enough time on air.)

  8. Statler and Waldorf: A few team members are commenting every issue. (Usually, this is not just a waste of time, but also patronizing as well as annoying.)

  9. Disrespect I: Other team members are talking while someone is sharing his or her progress with the team. (Similarly irritating is the need to use speak tokens among adults to avoid this behavior.)

  10. Assignments: The product owner – or scrum master – assigns tasks directly to team members.

  11. Cluelessness: Team members are not prepared for the stand-up. (“I was doing some stuff, but I cannot remember what. Was important, though.”)

  12. Let’s start the shift: The stand-up acts as a kind of artificial factory siren to start the next shift. (This is a common Taylorism artifact where trust in the team is missing.)

  13. Disrespect II: Team members are late to the stand-up. (Note: if the team did not choose the time for the stand-up it otherwise indicates distrust on the management side.)

  14. Excessive feedback: Team members criticize other team members right away sparking a discussion instead of taking their critique outside the stand-up

  15. Overcrowded: Stand-ups are ineffective due to the large number of active participants

  16. Talkative chickens: “Chickens” actively participate in the stand-up. (I think it is acceptable if stakeholders ask a question during the stand-up. However, they are otherwise supposed to listen in merely.)

  17. Anti-agile: Line managers are attending stands-up to gather “performance data” on individual team members. (This behavior is defying the very purpose of self-organizing teams.)

Depending on the context, it could also be an anti-pattern if the product owner – or even another stakeholder – is introducing new tickets to the current sprint during the stand-up. This behavior may be acceptable for priority one bugs. (Although the team should be aware of those before the stand-up.) However, it is an unacceptable behavior – and thus an anti-pattern – for changing priorities on the fly in the middle of a sprint.

Lastly, some teams like to have stand-ups in Slack, particularly those that are not co-located. Again, depending on the context, this does not need to manifest an anti-pattern per se. I was even working with a co-located team that used Slack as their preferred way of having a stand-up. It worked.

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


A lot of agile practitioners tend to consider stand-ups to be a candidate for waste. However, from a scrum master or agile coach perspective stand-ups offer the highest yield of anti-patterns – given the effort is so small by comparison to other ceremonies.

What stand-up anti-patterns have you observed? Please share with us in the comments.

✋ Do Not Miss Out: Join the 3,100-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.

Related Posts

28 Product Backlog and Refinement Anti-Patterns

Scrum: 19 Sprint Planning Anti-Patterns.

Why Engineers Despise Agile

7 thoughts on “16 Stand-up Anti-Patterns Threatening Your Transition to Scrum”

  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.