Antipatterns in Scrum are habits that are frequently exhibited but are overall ineffective or maybe even harmful. These anti-patterns occur throughout all the Scrum ceremonies and ultimately hamper their (timely) execution.
Let’s discuss it one by one in detail.
Sprint Anti Patterns:
Extending sprint length: Scrum team will extend sprint length by 2–3 days to meet the sprint goal. In this process, they will lose an opportunity to inspect and adapt to deliver the value in future sprints.
Hardening sprints: Some scrum teams will believe that hardening sprint is only the way to improve to address the security concerns of the project. They can add the security concerns in the definition of done to achieve these within the sprint.
Technical sprints: The other assumption is that the scrum team thinks they need to have one technical sprint where they will not deliver anything. Still, they will brainstorm and fix the tech debt they are going through. Again this is not Scrum if we are not delivering working software at the end of the sprint.
Sprint zero: I observed some teams and organisations that believe this is mandatory to kick start the project. As per the Scrum guide, we don’t need Sprint Zero to start a project, and Scrum encourages transparency, inspection, and adaptation. We can explore and learn, and then we can build the product. No need to run sprint zero to make all ingredients ready.
Varying Sprint length: Another important anti-pattern I can say is that some teams will start with sprint length with 15 days, then change to 30 days. Again stakeholders will come and ask so many questions they will come back in 15 days. We need to have a healthy discussion with the scrum team to decide the sprint length to deliver value in that duration.
Daily Scrum Anti Patterns:
Daily Scrum Timings change: The majority of the time, teams will try to change the timings of this meeting, this supposed to be a mandatory meeting, and we need to encourage developers to have this daily at the same time and at the same place to reduce the complexity, this will help developers to discuss their impediments on the way and how exactly it is affecting the sprint goal, where all the development team discusses to get out of the impediments.
Running Daily Scrum Meeting as status meeting:
Sometimes I observed people use this daily scrum meeting as a status meeting to update their progress to scrum master and product owner. We need to discourage this and educate the scrum master and product owner not to disturb them by converting it as a status meeting. The scrum master needs to coach the development team. It is not a status update meeting to their colleagues as well. It is more about how we are progressing towards the sprint goal. If some developers go on leave, others need to pick it up from there, and it is for developers to align with the work they are doing towards the sprint goal.
Daily Scrum is a waste of time: Some senior developers think that daily Scrum is wasting their time and no need to attend, and I can give the updates over the WhatsApp message or through Slack, again this is an anti-pattern which is no encouraging collaboration among the team, so scrum master needs to encourage and also coach developers on the importance of daily Scrum.
Getting on with the discussion:
During the daily scrum meetings, if one developer says what is blocking him, then the other developer who comes across the same problem earlier will start an elaborate discussion on the same and that is not good, and it will waste 15 minutes of valuable daily stand uptime, we can push them to a parking slot to discuss the daily stand up
Sprit Planning Anti Patterns:
Too detailed planning: During sprint planning, the development team will plan the Product Backlog Items(PBI) in detail by dividing them into small manageable tasks. It takes a long time, and it will take a long time to do that detailed planning. We can plan as much as possible and need to move on.
No planning: The development team will use the sprint planning meeting for general discussion instead of planning to identify what they want to achieve in that particular sprint.
Overcommitting: The development team overcommit and drag all the backlog items into sprint backlog, and they will negotiate later with the product owner to move them away
No reserve time for the development team: The development team overcommits and will not have any time to address the critical bugs, so we must reserve 10 to 15%. The development team needs to take this from the product owner.
Lack Of Sprint Goal: During the sprint planning product owner will not give a clear idea of what the Scrum team wants to achieve in that particular sprint. If the product owner doesn’t have the goal, then it isn’t easy to pick the PBI’s for that sprint.
Cherry-picking of PBI’s: The development team tends to pick what they can deliver efficiently instead of what is valuable for business. It is not a good practice and will not provide any value. Hence, the product owner needs to correctly groom backlog items.
Ignoring Definition Of Ready(DOR) and Definition Of Done(DOD): Most of the time, we will miss the DOR, and it is crucial, entire scrum team need to collaborate, and the product owner make sure that product backlog grooming is supposed to be happening at regular intervals, so those backlog items are in a much better state to pick them for next sprint.
DOD also needs to be defined during the sprint meeting. We need to understand the acceptance criteria to release to the users.
Estimation Phobia: Development team will not open much. They will not discuss estimations in detail. Most of the time, they will go with the senior developer estimation plus or minus 1. Hence scrum masters need to pitch in why we need to have the relative estimate of individuals and how it helps the team.
Sprint Review Anti Patterns:
Stake Holders/ Customer absence: Sprint review demonstrates the increment built during the sprint and need to seek feedback from the stakeholders/ customer to discuss what they can do next, if they are not present, then it may not be released, and we are not getting any value out of our effort, we need to include them.
Product Owner Calling All The Shots: The Product Owner is undoubtedly a product visionary, but he needs to consider the concerns of stakeholders and try to incorporate their feedback while the scrum team is developing the product. If the product owner does not respect the input of stakeholders, then it is tough to build the product customer wants.
Big Presentations rather than showing the product: Sprint review demonstrates the developed integrated increment and showcases how it works. Some product owners tend to a big presentation. Instead of showing the actual product, we need to avoid this for the interest of everyone.
Including partially completed PBA’s an increment: The development team includes partially completed PBA’s which are not meeting the definition of done. We are not supposed to do this as this is cheating if the product owner decides to release this, we will get a lot of criticism about the product, which is not suitable for the product in the long run.
Canceling the Sprint Review: Sometimes, at the end of the sprint, if the development team has not achieved what they committed or partially committed, they will skip this meeting rather than showcasing what they have done to stakeholders so far. We never know this might be an excellent opportunity to understand whether the mentioned feature is feasible or not; hence were not supposed to skip this.
Sprint Retrospective Anti Patterns:
No Retro: Scrum Team thinks this is an optional meeting, and they want to have it if the time permits and instead take a day off. However, this is a critical meeting to discuss as a scrum team to understand what went well and areas we need to improve.
Blaming Retrospective: Scrum teams blame each other for the past mistakes that happened during the sprint. As a team scrum team need to do retrospectives without blaming anyone, and they need to find the solutions to make everyone’s life easy in the next sprint.
Conducting the Retro in the same style: The scrum team always uses the same way to run the Retro. Scrum Masters need to innovate ways to make it more interesting, like using some great online tools.
Stake Holders/ Functional Managers involvement: Retro meeting is only for scrum team if the stakeholders and functional managers present it will expense the weakness of scrum team to the entire world. People will not feel psychological safety; hence we have to avoid this. Scrum master needs to educate the organization about the side effects.
Not documenting improvements: As a scrum team, we need to improve sprint by sprint; hence, we need to document where the team needs an improvement. We need to assign the action items to the team to track them closely.
Not allowing expressing concerns by all: Some people in the scrum team are not that open to express their ideas and concerns. Hence, a scrum master or someone needs to facilitate and make sure everyone can voice their opinion and control the other people, whoever dominates the retro meeting.
Excluding Product Owner: There are scenarios where the development team tends to ignore the product owner. They will exclude him from the meeting as they think he will take the side of stakeholders and customers. That is not a good thing to do as he will give us a great picture and vision of the product we are working on. Also, it will be perfect for including him to sort out the differences and what went in the last sprint. Suppose he is adding some deliverables at the last minute. In that case, we can discuss and tell him how it affects the team equilibrium.
Scrum Master acting as a facilitator: Some scrum masters will forget that they are also a part of the scrum team and need to provide their inputs. As a scrum master, the scrum master needs to observe all anti-patterns. He needs to help the development team and product owner and educate them on how to avoid those.