Classic Anti-Patterns During Scrum Events

Below, are some more commonly observed anti-patterns, seen in Scrum.

The list in is not conclusive.

Overall Sprint | Daily Scrum | Sprint Planning | PBR | Sprint Review | Retrospective

During a Sprint
  • Too many people (beyond 3-9 recommended in Scrum) consider themselves as ‘team members’.  Entire functional groups (component teams) that belong to the same reporting structure consider themselves, as teams.
  • Managers, PMO and other marginally involved in work people get involved
  • Too many unresolved/undiscovered external dependencies on groups and individuals that work outside of Sprint.
  • Team members have only partial dedication to Sprint and do side-work, elsewhere.  People that contribute to Sprint work are not on a team
  • Sprint duration is not consistent: sprints are shortened or made longer.   Sprints are too long (> 30 days
  • Scrum Master role is passed around from one person to another as a “hot potato”, due to the fact that nobody is able to perform the role well.  Common reasons: lack of Scrum knowledge, lack of comfort with raising dysfunctions, seeing no personal benefit in performing the role.
During Daily Scrum
  • People, arriving late to a meeting that is very short, to begin with
  • People, attending remotely, with poor connection and no visual support
  • Focusing too much on resolutions (this is to be done after daily scrum), not on discoveries
  • Daily scrum, becoming a status report, where team members ‘report’ their deliverable to Scrum Master (or someone else, who self-invited, e.g. manager, PMO)
  • Too much focus and updates of electronic tools, taking time from a meeting. Scrum Master, becoming tool specialists” / administrators, making updates, on behalf of others
  • Deep dives into detailed discussions OR… Referencing to ticket numbers only, without sharing meaningful content about WIP
  • Refinement of backlog items or planning of future sprints, instead of focusing on a current sprint
  • Command & control behavior towards team members, from a Scrum Master or among team members, e.g. direct task assignment by leads or line managers
  • Product Owner comes uninvited and takes over a meeting
  • Too many “I am here just to observe” people, eventually, leading to too many side-bar discussions and a loss of focus. This follows the classic pattern: as a number of communication nodes (people) increases, so does a number of communication channels (discussion threads), eventually, leading to excessive communication
  • Team members, are not being able to clearly articulate/express themselves
  • Some people are overly talkative; others very silent.  Monologues, arguing, disrespect, excessive feedback, loss of focus and orientation
During Sprint Planning
  • Product Owner did not clearly articulate to a team sprint goals
  • Work proposed for next Sprint is not well refined
  • Not enough effort is made to validate that planned work is really doable (DoR is not met)
  • Planned work has strong (and asynchronous) dependencies
  • Planned work by far exceeds a teams capacity (overall, skill set)
  • Team’s planning is treated as a hard commitment
  • No (or little) indication that the whole team plans together (everyone plans their individual work)
  • Product Owner is not explicitly informed about what a team is planning to work on
During Product Backlog Refinement
  • Product Owner is not present and/or sends in a ‘proxy’ or BA, instead
  • Not all team members are present. OR… too many people join, including uninvited guests
  • Refining backlog items that are low in priority
  • Too much focus on generating estimate numbers, not on shared understanding, a.k.a. as CCC (card, conversation, confirmation)
  • Attempts to solve/implement backlog items. Spending too much time on “how to build” details, instead of understanding “what to build”
  • Keeping Product Owner and stakeholders in a meeting, beyond their interest (e.g. technical discussions)
During Sprint Review
  • Meeting is made extremely short and treated as a formality (‘Scrum mandate’)
  • Review turns into a ‘town-hall’ with political agenda, instead of being a working session
  • Product Owner and/or key stakeholders/users are not present
  • Team shows, a ticketing system (mostly), power points or lines of code, instead of working software
  • The same person “shows” and takes all the credit for a team’s deliverable
During Sprint Retrospective
  • No feedback from Sprint Review is taken in
  • Managers, Product Owner, others – come uninvited
  • Lack of safety and comfort in a meeting. Too much hostility
  • Too much political correctness and lack of openness
  • Same people speak up. Same people remain silent
  • Same impediments are being raised in each Retrospective, nothing gets resolved

Leave a Comment

Please help us fight spam. Lets make sure you are not a robot !!!