Scrum anti-patterns refer to the critical deviations from the Scrum workflow steps or development best practices and principles. Ensuring optimum Scrum excellence requires detecting and addressing these anti-patterns with a guarantee of high precision.
Software development methodologies 2021
Source: Statista
Focusing on the major anti-patterns and finding their anecdotes is what one should begin with. In this article, besides explaining some common Scrum anti-patterns that undermine the project execution, I would also like to shed some light on the Scrum anti-pattern definition, examples and detection methods.
Top Scrum Anti Patterns by Category
In the Scrum development environment, anti-patterns can be detected in the following lifecycle stages or categories.
- Daily Scrum
- Product Backlog and Refinement
- Sprint
- Sprint Retrospective
The anti-patterns for each of the above further have been categorized based upon the roles such as Product Owner, Scrum Master and the developers. Through the following write-up, I am going to explain what are the Scrum anti patterns for every facet of Scrum development and job roles. Let’s begin.
Anti-Patterns in Daily Scrum
Generally, the Scrum development team at the start of every working day meets for 15-20 minutes to evaluate their progress in achieving the Sprint objective. The most encouraged time of day to hold a scrum daily meeting is the morning when all team members meet. Because of this short duration, often the Daily Scrum session is rattled by several anti-patterns.
You know Scrum meetings are part of which model. It is but of both Agile & Waterfall Scrum. To make sure that the Daily Scrum meeting adds desired value to the project, it is important to watch out for the following anti-patterns.
Daily Scrum Anti-Patterns for the Scrum Team
- Losing focus: Are we focused to achieve the Sprint Objective? Should we give priority to the plan or the Sprint Backlog? A burndown chart maintained by the developers can provide a relevant visualization to probe into this.
- Submitting status report: Turning the Daily Scrum meeting into an event of submitting reports about their progress to the Scrum Master or Product Owner violates the principle of continuous evaluation and hence is a serious anti-pattern.
- Lack of regularity: When the Daily Scrum session does not follow a routine conducted at a given time and place, the developer teams can develop a habit of skipping it too often.
- Lack of respect: Lack of respect can be visible either when some team members are not paying attention to what other members are sharing or when some members fail to attend the Scrum meeting altogether.
- Turning it into a lengthy discussion: With several team members criticizing each other and discussing at length, the objective of the Daily Scrum session can go astray.
- A large number of participants: What is the optimal number of members for an agile team? Well, it is not more than 10 members. If you fail to follow the basic Scrum principle of limiting the number of team members to a maximum head count of ten, the overcrowded daily session is likely to make itself meaningful.
Daily Scrum Anti-Patterns for the Developers
- Appearing unprepared: This is common for some developers to come with no observation regarding the progress towards the Sprint goal.
- Making new plans: When in the Daily Scrum session developers start talking about new project requirements and plans for new Sprints, this deviates the focus from the ongoing Sprint.
- Violating timebox: Time box for a daily scrum is the allotted 15-20 seconds time slot for the developers to raise issues. Some developers end up extending one point far too long.
- Being Over-opinionated: Some team members being over-opinionated shares their views on all issues.
- Being Under-opinionated: In some cases, developers just refrain from raising any issue or looking for support from other members. The underlying problem can be a feeling of insecurity to express themselves.
Daily Scrum Anti-Patterns for the Product Owner
- Overreaching: This happens when the Product Owner by breaking the protocol starts assigning development tasks directly to the developers.
- Incorporating fresh work: Sometimes, fresh new work is incorporated within the ongoing Sprint by violating the responsibility of developers to take care of the Sprint backlogs.
Anti-Patterns of the Scrum Master
- Not convincing everyone on the importance of Daily Scrum: Even though Scrum Master is responsible for ensuring the presence of all members in the Daily Scrum, the inability to convince everyone of the importance of this session may not produce expected results in terms of fulfilling Sprint objectives.
- Not giving enough support to developers with repeated issues: There are situations when developers despite revealing an issue in several sessions find it difficult to get support from the team members and if the Scrum Master does not take initiative to resolve it, the same can pose a serious challenge for the Sprint outcome.
- Allowing the stakeholders in Daily Scrum: When the stakeholders attend the Daily Scrum without being invited, this can limit the scope of the discussion on relevant points.
- Not being strict about the time slot: Being incapable of enforcing the time slot for every developer to reveal their issues can result in unwanted distractions.
Anti-Patterns in Product Backlog and Refinement
According to the Scrum principles and anti patterns definition, product backlog gives precise direction to the developers about what they are going to build in increments. Now even after the discovery phase is over and the product backlog is ready, it may still need further refinement for an improved project outcome.
Multiple anti-patterns in Scrum play a key role in creating an under-optimized product backlog. Now there are anti-patterns even in the refinement process for the product backlog. Let’s have a look at the common anti-patterns in the product backlog and refinement process.
General Product Backlog Anti-Patterns
- Stakeholders setting priorities instead of Product Owner: In Scrum, the Product Owner makes the final call on the product backlog items. Now when several stakeholders list priorities for the Product Backlog instead of the owner, the project may fail to deliver expected outcomes.
- Outgrowing the capacity: If the Product Backlog consists of too many items requiring too many Sprints (more than the usual six to eight Sprints), it may lead to drainage of a lot of developer efforts and a poor cost against value ratio.
- Outdated backlog items: In some projects, some items in the backlog remain untouched for weeks and they remain vulnerable to getting obsolete. These outdated items at the same time can take away the value of the earlier work of the Scrum team.
- Upfront estimation of time details: While in Scrum continuous efforts are put into refining the backlog items, upfront calculation of development time details for backlog items may very well result in the flawed allocation of time.
- Following horizontal structure instead of vertical: As and when the items in the Product Backlog items follow horizontal structure, the vertically layered functional build-up focus is lost. This often happens due to the horizontal structure of some organizations.
- Too big a list of acceptance criteria: Acceptance criteria for each backlog item need to be precise consisting of a maximum of 5 criteria and in case of more extensive criteria the item may need further splitting up.
- Upfront backlog creation for the whole project: Creating a complete backlog for the entire project well in advance violates the basic principle of Scrum, which is to adapt to the problem and find refined solutions over time. 10.
- Too little or no description: If the items in the Product Backlog only have titles or too little description, it will result in a lack of clarity for the developers and compromise with the value of the increments.
Product Backlog Anti-Patterns of the Product Owner
- Overcrowding of ideas: Sometimes the Product Owner incorporates a lot of ideas resulting in an inflated size of the backlog. As a consequence, there are high chances of stakeholders being overwhelmed and missing the most important items.
- Lack of activity on the backlog: In some cases, the Product Owner fails to work on the backlog regularly resulting in occasional refinement and a lack of focus on constant value addition.
- Product Owner leaving no scope for developer inputs: When the Product Owner when creating the Backlog items explains not just the rationale behind the item, but also the implementation process and the desired outcome, it severely limits the scope of developer inputs.
- Non-collaborative approach: For creating and refining product backlog the Product Owner may decide to take the onus of everything without involving the subject matter specialists and stakeholders in the process. This can put the success of the Scrum team at risk.
Product Backlog Anti-Patterns of the Developers
- An unquestioning Scrum team: When the developers instead of probing and questioning every item in the product backlog just succumbs to the demands and expectations of the Product Owner, it can result in compromising the value of the developer output.
- Not giving attention to perfection: In some cases, developers can be tempted to produce one feature followed by the other without paying much attention to the technical debt, shortcomings or bugs. This may result in poor product quality.
- No Buffer time: If developers follow too strict a schedule with no buffer time to address the unplanned capacity, performance issues are likely to occur.
Anti-Patterns for Sprint
Sprints represent the throbbing and pulsating blood circulation system in the Scrum body. Sprints are carried out sequentially one after the other and achieve incremental goals itching towards the ultimate finished product. To ensure delivering predictable outcomes, every Sprint is run consistently for a month or less and allows frequent inspection to align with the project goal. The sprint planning is important to ensure optimum outcome from every successive sprint.
Each sprint running like a short project works as the vertical building block to achieve the pinnacle of success with the final product release. Sprint planning meetings are held before starting with each sprint.
Unlike other facets of the Scrum development process, anti-patterns during the Sprint can be detected across all roles including developers, product owners, Scrum Master, stakeholders and even the IT management team.
Sprint Anti-patterns of the Product Owner
- Unavailable Product Owner during Sprint: When running the Sprint, developers may detect new scopes of work for updating the backlog and can consider asking the owner. In such cases, the unavailability of the Product Owner can force developers to compromise with the Sprint goal.
- Lack of flexibility to change acceptance criteria: When working developers can find that the previous acceptance criteria are irrelevant in the present state of things, the Product Owner upon inspection should allow changes in the original criteria. Inability to do so will only derail the project outcome.
- Delayed feedback: When the Product Owner waits for the entire Sprint to end and just ignores giving feedback on the particular items of the Sprint Backlog, there can be quality issues just because there are no checks and balances for ensuring the quality of items once it fulfills the Definition of Done and ready for release.
- Overloading the developers once they finish Sprint early: Some product owners try to utilize the time of the developers if they have finished a Sprint earlier than the scheduled time. This extra push for utilization of the developer time can demotivate developers to give their best efforts.
- Canceling Sprint on whims: Realizing that the Sprint goal is not going to be fully achieved, some Product Owners may consider canceling a Sprint. This not just goes against the collaborative principle of Scrum but also limits the chances of allowing someone’s unique idea to achieve the Sprint goal.
Sprint Anti-patterns of the Developers
- No limit for queuing tasks: Creating value for the end-users with an incremental development approach is what Scrum is all about. Now, with no upper-cap limit for a developer to handle tasks, the quality of the product is likely to be compromised.
- Willy-nilly picking of works: When developers just haphazardly pick works just to feel good about solving a problem, this unorganized approach ultimately eats away their productivity.
- Not updating Sprint board with present status: Often developers just forget to update the Sprint board with tickets. Because of not updating the Sprint board, the present statuses cannot be seen.
- Extending a Sprint with irrelevant work: Some developers just stretch the scope of a Sprint unnecessarily by adding extra work irrelevant to the agreed-upon Sprint goal. This not only may lead to distrust in the team but can also drain resources and development time without necessity.
Sprint Anti-patterns of the Scrum Master
- Not preventing interference: The Scrum Master by allowing stakeholders to access his team members to permit line managers to remove or replace developers to allow managers to use Daily Scrum for performance reporting, there are many ways Scrum Master can allow disruptions and all these ultimately compromise the Sprint goal.
- Not standing in support of developers in need: Sometimes developers continue to put efforts without making any inroads into a problem and if they do not voluntarily reach out, it is up to the Scrum Master to address it. Inability to do so can cause unnecessary delay and may even end up compromising the Sprint goal.
- Scrum Master allows direct task allocation by Product Owner: When the product owner or any of the stakeholders directly allocate tasks to the team members, it can disrupt the Sprint.
Anti Patterns for Sprint Retrospective
Sprint Retrospective or reviewing the Sprint to improve the quality of the output and process efficiency embodies the core approach of Scrum development practice. It is done to ensure a thorough evaluation of the way the latest Sprint was carried out with the involvement of the developers, Scrum Master, Product Owner, and IT team and how the tools, interactions and processes are handled. Introspection on the contribution of each of these attributes against the Sprint goal is what Sprint Retrospective is all about. This is also the concluding part of a Sprint and it takes from 3 hours to a month to finish.
Across Scrum projects, some anti-patterns frequently appear in Sprint Retrospectives that we need to watch out for. Here we found some of the important Retrospective anti-patterns.
Sprint Retrospective Anti-Patterns of the Scrum Team
- Not conducting any retrospective at all: Avoiding retrospectives altogether with the notion that there is no scope for improvement completely blocks the way for any further value addition.
- Equating retrospective with buffer time: Sometimes the Scrum team may just consider the time allotted for retrospective just as a buffer time to accommodate unfinished work for completing the Sprint. This mindset often results in the cancellation of retrospectives.
- Doing retrospective in a hurry: Carrying out retrospective in a rushed manner taking less than the bare minimum time ultimately takes away the benefit of this vital Scrum process.
- Not following up on the action plan from the previous retrospective: If the previous retrospective within the Sprint suggested actions and the team just failed to work on the same, the whole objective of running the retrospective is lost.
- Keeping retro for the next Sprint: Sometimes Scrum team just likes to avoid it for the just-finished Sprint and consider it for the next Sprint. This rushed eagerness to concentrate on the next Sprint ultimately results in sacrificing the goal of the current Sprint.
- Not taking responsibility: It is often common among the team members to refuse to take responsibility for the delivered item. This ultimately results in bad collaboration and teamwork to fix the issue.
Sprint Retrospective Anti-Patterns of the Scrum Master
- Participating from compulsion: When the Scrum Master fails to convince the team members of the importance of retrospective and everyone joins just as participating in a ritual, the whole objective of improving the Sprint is lost.
- Not documenting the retrospective: Scrum Master fails to enforce documenting the retrospective findings and actions with minutes that can be used for later reference. Not documenting the retrospective means not keeping the learning from a Sprint for further use.
- Not being able to control the blame game: A failed Sprint can easily spark blame gaming among the team members and if the Scrum Master cannot prevent it with proper communication and command, the outcomes of the future Sprints can also suffer.
- Not guaranteeing team participation: It is the responsibility of the Scrum Master to bring out the team members from their passivity and participate in the retrospective to find areas of improvement.
Detecting Scrum anti-patterns with Burn-down Charts
The burn-down charts for every Sprint work as a reliable mechanism to detect Scrum anti-patterns. The biggest advantage of the Burn-down chart is the visibility of the input and output of the team in a graphic manner. Burn-down charts help keep the entire Scrum team and all members aligned with the Sprint goal with visual insights.
Apart from helping the team to stay focused on the Spring goal, it clearly shows the underlying impediments to the team and the company. From showing the common anti-patterns to detecting the speed of the Sprint, burn-down charts help Scrum teams to address fault lines and come up with action plans in quick succession.
The burn-down charts, despite offering a visually engaging detection mechanism, cannot provide an exhaustive display of anti-patterns. This is why it is always advisable to rely on burn-down charts as a supplementary detection tool besides taking note of all the anti-patterns we mentioned above.
Wrapping Up
Having an in-depth understanding of the Scrum anti-patterns for different Scrum processes and roles is necessary to keep your product development cycle stay out of the common ditches. All the anti-patterns I mentioned above have been experienced by Scrum professionals in their respective job roles across a multitude of projects. This list of anti-patterns should work as the bells and whistles to stay distanced from the mistakes that earlier Scrum projects suffered from.
I have further elaborated on Scrum Anti-patterns in our on-demand webinar, addressed jointly with Pradeep Lavania, co-founder & director of WalkingTree Technologies on 16th June 2022.
In the webinar, I have discussed at length topics such as Scrum Event Anti-patterns, Scrum Role Anti-patterns and How to Detect Anti-patterns. Be sure to check it out.
