3 Common Scrum Anti-Patterns and How to Fix Them
To be successful, a Scrum team must honor the values of commitment, courage, focus, openness, and respect. It's easy to fall into practices that can erode trust and collaboration. Here are three common Anti-Patterns that emerge in Scrum and the solutions to overcome them.
Join the DZone community and get the full member experience.Join For Free
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
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.
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.
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.
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
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.
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.
Published at DZone with permission of Owen Gotimer, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Software Development: Best Practices and Methods
Scaling Site Reliability Engineering (SRE) Teams the Right Way
Using Render Log Streams to Log to Papertrail
The SPACE Framework for Developer Productivity