Top 6 Scrum Anti Patterns | List of Anti Patterns in Scrum

Welcome to PremierAgile!

Recognized for 'Outstanding Leadership in Education and Learning' by the Education 2.0 Conference Dubai 2024

We are proudly recognized for Excellence in Agile Consulting and Transformation Services – 2023 by Economic Times and Times of India!

*Avail a Flat 10% Discount Across our Agile-Scrum certification courses use coupon code FESTIVE10

*Avail Zero Interest EMI

We Offer World-class guidance to transform yourself as well as your organizations

PremierAgile

With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...

Top Scrum Anti-Patterns

Top Scrum Anti-Patterns

Scrum is one the most adopted frameworks among many organizations as Scrum is lightweight and easy to understand. Most companies have benefited by implementing Scrum and overcome the disadvantages they faced while using the traditional software methods. Scrum has made companies more Agile and ready for the competition that they face in the markets. Benefits such as customer satisfaction, employee satisfaction, faster time-to-market, quality product development, early return of investment, etc are a few of the greatest highlights of using Scrum for complex projects. The success of Scrum depends on the way the employees have been trained about Scrum and how much knowledge and skills they have gained by training programs and certification courses. Mere implementation of Scrum would not guarantee the success of the organization if the employees are not well-trained and educated about using Scrum tools and techniques. Scrum anti-patterns are ways in which the Scrum Team functions that would disrupt the workflow of Scrum, where the company may reduce its product and business value. In this article, we learn about top Scrum anti-patterns that disrupt the workflow of the Scrum Team.

Scrum Anti-Patterns

As stated in the Scrum Guide, Scrum is a framework where people can address complex problems productively and creatively by delivering products of the highest value. Here Scrum is described as easy to understand, lightweight, and difficult to master. Hence, beginners use some Scrum practices and mechanically use them without knowing the underlying principles. The term anti-pattern is an expression that describes software that is initially attractive and has easy to apply solutions but is far from solving problems and ends up causing bigger problems. Let us understand how the Scrum Team functions and later identify the antipatterns in the Scrum Team. 

The Developers work on the Sprint Backlog and deliver it at the end of every Sprint. They check the Definition of Done and complete the work which gets accepted based on the acceptance criteria.

A few functions of the Developers include:

  • They convert the Product Backlog Items (or product requirements) into Product Increments.
  • They do not have titles
  • There are no sub-teams in the team despite several tasks such as Testing, Operations, Development, Business Analysts, etc.
  • The whole team is responsible for a particular product even if the team contains people with different skills.

As the team is self-managing, there may be confusion on how the Developers should respond to the Scrum Master and Product Owner, and what their roles are when it comes to Product Development. Here are a few of the top Scrum Anti-patterns seen in various situations in the Scrum Team.

Anti Patterns at Sprint Planning Meetings

1. Unrefined Product Backlog

The Product Owner is solely responsible for maintaining the Product Backlog. One of the major mistakes that they could make is not updating the Product Backlog before a Sprint Planning meeting. An unrefined Product Backlog would make it difficult for the team to figure out what are the upcoming tasks that they have to focus on. This may consume a lot of time which could have been spent on working on the Sprint Backlog.

2. Absent Key Stakeholders

Sprint Planning could be done effectively when relevant SMEs are present and could share their views on the Product Increments. When they are not present, it leads to issues such as:

  • Product Owner not able to clarify questions
  • Team members who have to take up the task are missing and cannot commit to their availability
  • Developers cannot set time aside to fix bugs and ad-hoc work

This makes the team members to overcommit to tasks but underperforms which leaves certain tasks to the next Sprint and the workflow of the team gets disrupted. 

3. Having a Weak Definition of Done

Definition of Done helps the team to estimate the efforts that have to be put in to complete a task. When the DoD is weak, there may be confusion as to what exactly is considered completed. This leads to either delivering more than what is required and in most cases, not delivering the tasks which are asked for. This scenario also makes it very strenuous to estimate how much effort each member has pitched in.

Anti Patterns at Daily Scrum

1. Noise from Outside

The Daily Scrum is open to all the stakeholders, where the team members discuss their progress in the Sprint. Often, this discussion is taken over by outsiders and becomes a pointless meeting that does not concern the meeting. Other problems that could take place are:

  • Teammates talking over each other and interrupting.
  • Team members not concentrating while other people are presenting
  • Members come late to the Daily Scrum and create distractions for others.
  • The environment where the Daily Scrum takes place may be noisy or uncooperative.

2.Discussing work in details

Often, the most common cause of extension of a Daily Scrum is by team members over-explaining the progress and discussing the work heavily. The Scrum Master has to know that the Daily Scrum should be timeboxed to 15 minutes such that everyone works more than discussing. These discussions should be reserved for other Scrum Events as it does not align with the purpose of the meeting.

3. Current Problems 

Team members cannot resolve the problems faced and cannot go about their work. Also, in such cases, other team members do not offer any help due to a lack of time or trust, or competence. This causes a break in the process and may cause a delay in product development and delivery.

4. Skipping Daily Scrum 

Few teams may consider that Daily Scrums are unnecessary and the progress could be caught up at once. But this takes away the opportunity of catching up with the team and planning their day based on the progress of other team members. Also, the team should conduct the Daily Scrum at the same time and location to avoid any ambiguity and wasting time. 

5. Not preparing for the meeting

When team members cannot remember what they worked on yesterday, or what they will be working on today, or didn't prepare as required; there will be an extension of the 15-minute time limit and few important details may be missed out. This could be avoided by preparing a sticky note and using it as a source of information.

Anti Patterns at Sprint Review

1. Lack of Attendance

Team members may feel that the Sprint Review is not as important and their attendance is not required which causes many problems such as:

  • Lesser insights are presented to the stakeholders which makes them feel that enough information is not shared.
  • Meetings are repetitive and the agenda does not change
  • Similar faces present the Product Increment due to fewer people

People may just read from the slides and do not make the presentation interesting.

2. Unfinished business 

There could be a false sense of achievement where the Developers do not complete the items as stated by the Definition of Done. This leads to unfinished business and a bad reputation in front of the stakeholders.

3. Unpreparedness or lack of preparation

Team members rushing up the presentation which could make the stakeholders not understand the purpose of a particular feature could be one of the results of lack of preparation. This could also hamper the meeting's effectiveness and could end up stakeholders not showing up the next time.

Anti Patterns at Sprint Retrospective

1. Making Personal Attacks

Retrospectives are planned to look at tasks that were not completed. During these sessions, team members can attack each other which causes discomfort and friction. The team members should have the courage to address the underlying issues but should also treat each other with respect.

2. Skipping or Rushing Retro

The team may skip or rush through the retro sessions as it may feel that it is not as important as other sessions. This shows that the team does not understand the importance of the meeting and cannot reap the benefits of conducting retro.

3. No actions taken

Even after addressing the issues and coming up with action plans, no one would follow up them due to:

  • Lack of accountability among team members
  • Scrum Master cannot explain the changes required to improve the team's performance.

No one pays attention and takes notes of the action plans that have been discussed.

4. Snitching

The Retrospective meetings are conducted inside the Scrum Team, but sometimes, team members may share few discussed points with external stakeholders which creates a breach of trust and fear of ramification. Hence, people cannot speak up openly and address the issues that could help the team.

Scrum Master Anti Patterns

Anti Patterns are behaviors that can also be associated with Scrum Masters and Product Owners. Here are few anti-patterns that the Scrum Masters can show:

1. Avoiding to Resolve Conflicts

Human beings tend to avoid uncomfortable situations and look for security and stability. There are high chances that a Scrum Master may not show up when conflicts are going on in the group which leads to more misunderstanding and haziness. The Scrum Master has to listen to both the groups and learn new techniques to resolve conflicts in a group setting. The Scrum Master should seek help from outside and get guidance from coaches to solve the issues in the group. 

2. Giving Too Much Freedom

Although the Scrum Team is a self-managing team and can make decisions on their own, it does not mean that the developers can do whatever they want and make decisions that do not align with the product vision. Instead, the Scrum Master should teach the Developers the principles and values of self-managing such that they align their vision with the company's vision.

3. Using competition as Motivation

Comparing the work performances with one another would only stress out the Developers which would lead to a lack of focus and motivation. This affects the high-quality increments and causes the team members frustration and puts the entire organization at stake. The Scrum Master should motivate the team members based on their achievement and not by making them fear that they are worse than someone else. 

Product Owner Anti Patterns

1. A Product Owner who is inaccessible

When a Product Owner is not available for the team members to answer their questions about the product, it leads to major miscommunications that lead Developers to create the wrong products. Few reasons why a Product Owner is inaccessible is due to:

  • Part-time employment of Product Owner
  • Managing multiple projects simultaneously
  • Product Owner also takes the role of Scrum Master
  • Product Owner is represented by a group of people who also carry on their day-to-day work.

2. Poorly Managed Product Backlog

A Poorly managed backlog is one of the worst-case scenarios for the developers to carry on their work. Some examples of a poorly managed backlog are:

  • Oversizing the Product Backlog which causes the team to delay the delivery of Product Increments
  • The backlog contains outdated items that are not relevant to the project
  • User Stories that miss acceptance criteria
  • Unrefined items such as User Story that contains only headings and no descriptions
  • Estimating all the User Stories with a timeline in advance may prove to be a waste of time as overtime, few User Stories may be outdated

3. Selfish Product Owner

A Product Owner who would take the credit for all the fellow team members achievements can indefinitely affect the morale of the team. This affects the team and may lead to a lack of cooperation and productivity of the team's performance.

4. Product Owner who does not take accountability

Product Owner who blames the team members for their failure or holds others responsible for a failure in the product development would bring the team's performance and morale down. PO's who take failures stating that how could I be responsible for a product not working out?

Conclusion

Scrum Anti Patterns are behaviors that the team members exhibit that would drain the resources from the Scrum Team in the long run. Keeping an eye out for such behaviors in the Scrum Team would enhance the productivity and performance of Developers. These behaviors are subtle and it becomes the responsibility of each member to report such instances to the higher authority and to reach out to people who would help them. Identification and elimination of Scrum Anti patterns would increase the morale of the team which positively affects the productivity of the team.

References
  1. https://productmint.com/what-are-scrum-anti-patterns-definition-examples/
  2. https://www.techwell.com/techwell-insights/2020/01/3-common-scrum-anti-patterns-and-how-fix-them



Useful Links:

Product Owner Online Certification Oklahoma CityA-CSPO Virtual Certification Training SpokaneAdvanced Certified Product Owner Certification Course KuwaitAdvanced CSPO Virtual Certification Training OaklandScrum Master Course Training IndiaPremier Agile CSM Training TestimonialsCSPO Online Certification WilmingtonAdvanced Scrum Master Course Training AmsterdamAdvanced Certified Product Owner Training New York CityAdvanced Scrum Master Course Training Berlin

Author

Paula

Is a passionate learner and blogger on Agile, Scrum and Scaling areas. She has been following and practicing these areas for several years and now converting those experiences into useful articles for your continuous learning.