3 Common Scrum Anti-Patterns and How to Fix Them
For a Scrum team to operate successfully, the entire team—including product owner, cross-functional development team, and ScrumMaster—must honor the Scrum values of commitment, courage, focus, openness, and respect. By following through on those five values, Scrum teams help build trust within their team and organization.
But that’s not always easy. Here are three common anti-patterns that emerge in Scrum practice, as well as the solutions to overcome them.
The Absent Product Owner
Anti-pattern: In Scrum, the product owner is part of the team. They’re responsible for driving the value of the product for the customer through the work of the development team. The PO needs to actively work with the team throughout the sprint to answer questions and inform decision-making.
While not having the PO around might sound less distracting, an absent PO actually slows down the team’s learning process and potentially causes rework due to misunderstandings.
Solution: Sometimes, a product owner is responsible for multiple Scrum teams, which makes it challenging for them to be present. The only real solution to keeping the PO in the loop is to get them actively engaged with the Scrum team, from sprint planning to the daily scrum to the sprint review and sprint retrospective.
No Retrospective
Anti-pattern: At the end of every sprint, Scrum teams should be meeting to inspect how the previous sprint went, identify what went well and areas to improve, and create a plan for implementing those improvements moving forward. However, retrospectives can become repetitive and boring, often leading teams to just go through the motions or not hold retrospectives at all.
Continuous improvement is integral to software development (and workflow in general), so not facilitating effective sprint retrospectives can have detrimental effects.
Solution: One of the biggest reasons teams stop holding retrospectives is because they are boring. Scrum teams fall into the repetitive questions “What went well?” “What went poorly?” and “What could be improved?”
Try changing up your retrospective format, like using the 4 L’s:
- Liked: Things you really liked
- Learned: Things you have learned
- Lacked: Things you have seen the team doing but that could be done better
- Longed for: Things you desired or wished for
Pre-Assigning Tickets
Anti-pattern: During your sprint planning, the PO or ScrumMaster assigns tickets to the people on the development team who they feel should complete the work. Sounds like an efficient system, right?
Wrong. The problem with pre-assigning tasks is that it causes siloes within the team. Team members start working individually rather than as a team, and skills transfer and improvement never happen.
Solution: Rather than pushing tasks to individuals during sprint planning, allow team members to pull tasks into their in-progress work. If there are individuals who are better at certain tasks, you could make a note of that on the ticket, then have team members who are less familiar with that task work with the expert on the ticket. This creates new skills on the team, increases your bus factor, and improves communication.
