While the Scrum concepts and techniques are fairly easy to understand, mastering their daily execution is very challenging. After all, changing deeply ingrained habits is nothing that we can complete overnight.
Ultimately, we (as agile practitioners and participants) want to be able to recognize and eliminate behaviour detrimental to the agile way thinking and working. These bad influences are what we call anti patterns.
This article will take an in-depth look at how we define anti patterns in Scrum and how some of them look like.
Definition Of Scrum Anti Patterns
Anti patterns in Scrum are habits that are frequently exhibited but overall ineffective or maybe even harmful.
These anti patterns occur throughout all the Scrum ceremonies and ultimately hamper their (timely) execution.
Furthermore, even the agile practitioners (such as the Scrum Master or Product Owner) may suffer from some of these shortcomings themselves. This makes it all the more complicated to them.
Anti Patterns During The Sprint Planning Meeting
Unrefined product backlog. One of the biggest sins of the product owner (as he/she is responsible for managing the product backlog) is to come into the sprint planning meeting trying to figure out the details of the upcoming sprint tasks. This will take away valuable clock time that should be spend planning the upcoming sprint.
Missing key stakeholders. We can only plan accordingly when the effort of tasks can be estimated accordingly. As such, we need all the necessary domain expertise to help us do so. This can lead to many problems, such as:
- The product owner pushing too many tasks into the sprint
- The development team might not enforce time to be set apart for bug fixes and ad-hoc work (through so-called stretch objectives)
- The development team cannot commit to their availability for the upcoming sprint (in case some of its team members are missing)
As an overall consequence, teams end up committing to too many tasks. Many of those end up spilling over to the next sprint, ultimately hampering the team’s performance to deliver.
Weak Definition of Done and/or Ready. DoR’s and DoD’s allow teams to precisely estimate the efforts of delivering an increment of work. When teams don’t have a shared understanding of what constitutes ready and done (and the underlying tasks involved to ship the item), then it becomes close to impossible to reliably estimate effort.
Anti Patterns During The Daily Scrum
Outside noise. The team tolerates outside stakeholders to actively participate in the stand up, which ultimately ends up in pointless discussions about the work to be done.
Other noisy problems can include:
- Team members interrupting each other
- Team members talk to each other while someone else speaks
- Team members come late to the stand up, thus creating distraction for the others involved
- The environment in which the meeting is held (e.g. in the middle of the office) causes interruptions
Heavily discussing work. The Daily Scrum is not to be used to spark heated (or any other sort of) discussions. This will a) keep your team members from being productive, b) negatively affect morale and c) is not in line with the purpose of this meeting. Reserving them for after the meeting is the way to go.
Ongoing problems. Team members are not able to resolve ongoing issues or simply don’t offer to help out. This oftentimes shows either a lack of trust, time, competence or even a combination of them all.
Skipping altogether. The Daily Scrum is held at the same time and location each day to reduce complexity. Doing the meeting infrequently robs the team of the opportunity to catch up and strategize for the day ahead.
Lack of preparation. Team members simply cannot remember what they were working on or lave it important details for the others. A lack of preparation can also lead to the violation of the 15 minute time limit. Pro tip: write down on a sticky note what you did the day before and use that as your guiding source of information.
Anti Patterns During The Sprint Review
Lack of attendance. People, whether they’re internal or external, are simply not showing up to the sprint reviews. This can be due to a couple of reasons, for instance being:
- Lack of insights presented, thus stakeholders don’t feel they can gather necessary information
- Meeting feels very repetitive and agenda does not really change much
- The same faces show up again and again
- Boring presentation style in which people simply just read from a couple of slides
Furthermore, while there might be a good level of attendance, stakeholders might feel disengaged and therefore won’t prompt any questions. Whether that’s because they don’t feel the need or freedom to speak up is something that should be investigated and fixed, as it creates fruitful discussions and insights.
Unfinished business. The dev team presents work items that don’t meet the definition of done, thus creating a false sense of accomplishment.
Lack of preparation. Team members finishing up slides minutes prior or stakeholders not knowing about the purpose of the event can be some of the factors that can hamper the effectiveness of the meeting. Again, this could culminate in stakeholders not showing up next time or simply being disengaged during the meeting.
Anti Patterns During The Sprint Retrospective
Getting personal. Team members attack each other during the retro, ultimately causing friction and discomfort. As defined by the Scrum values, teams should treat each other with respect while not losing their courage to speak about the underlying issues.
Rushing or skipping retro. The team either rushes through or skips the retrospective altogether. This is often a sign of the lack of understanding for this meeting’s importance. Furthermore, teams won’t be able to reap its extensive reflective benefits.
Scrum Masters should try and make the retro worth the team’s time. We can spice the meeting up through a multitude of ways – where it be change of location and techniques or simply ordering some donuts and coffee along the way.
No actions taken. Despite calling out persisting issues and coming up with action plans, no one actually follows through with them. This could be due to several factors, including:
- No one in the team feels accountable
- The Scrum Master or agile coach is not capable of reflecting and following through with the discussed action points
- No one is taking notes and therefore does not remember what’s been discussed
Snitching. Members of the team share the discussed points with external stakeholders. This creates a huge breach of trust and fear for ramification. Team members will therefore loose their courage to ever speak up.
Lack of openness. Whether the company lacks a suitable venue for the retro or there’s outside stakeholders (e.g. line managers) invited to the meeting, a lack of openness completely defeats the purpose of the retrospective. This often leads to passivity with no one feeling the need to speak up.
Scrum Master Anti Patterns
Apart from the ceremonies, there’s a multitude of anti patterns both the Scrum Master and product owner can suffer from.
Wearing multiple hats. This often takes place in organizations which are used to a waterfall style of delivering work. Examples include former line managers or team leaders becoming Scrum Master while continuing to manage their day-to-day duties. This simply doesn’t work – both from a time and self-organization perspective.
Avoiding conflict. As humans, we tend to avoid uncomfortable situations wherever we can. Instead, we strive for security and stability, especially in settings that involve groups. Seeking outside guidance, for instance through coaches or psychologists, can help guide the Scrum Master on how to effectively solve conflicts.
Too much freedom. Just because Scrum is based on independent teams and self-organization, it should not mean that its members have a free ticket to do whatever they want. Rather, he coaches everyone involved on how to be self-organizing in the realms of the ceremonies while steering the organization towards effective Scrum adoption.
Competition as motivation. Using the performance of other teams to challenge and motivate can be detrimental to team morale. This may come at the expense of delivering high quality increments, causing team members to stress and putting everybody in the organization on the spot. The Scrum Master should motivate his/her team through a sense of achievement, not the fear of being worse than someone else.
Lack of experience. We can only repeat ourselves: Scrum is easy to learn, but hard to master. Having an inexperienced Scrum Master can lead to a failure in adopting and executing on agile methods. Having said that, as long as your team makes progress, having a little more patience may suffice.
Product Owner Anti Patterns
Inaccessible PO. The Product Owner is not consistently accessible to the team to answer questions whenever they arise. This may be due to several factors, including:
- The org decided to only employ a part-time PO
- The Product Owner manages multiple products (big no no!)
- The Product Owner takes on other roles (e.g. Scrum Master) at the same time
- A group of people (i.e. committee) represent the PO role to be able to focus on their day-to-day work
In any of these cases, both the development team and organization as a whole are missing a constant guiding force that steers them into the direction of product value maximization.
Poor backlog management. Again, bad product backlog management comes in many shapes and forms. Examples entail:
- Oversizing the backlog, causing the team to not be able to deliver on time
- Outdated items that are simply not relevant anymore
- Items are not refined and don’t include detailed descriptions of the user story (e.g. only adding titles to each user story)
- The user story is missing acceptance criteria (Definition of Ready)
- All user stories are estimated weeks in advance, which may cause unnecessary additional work for all team members (as these user stories may become outdated over the course of the following sprints)
.. and many more. In any of these cases, it is advisable to have a strong Scrum Master that can guide and teach the PO on effective backlog management.
Selfish PO. The Product Owner takes all the credit for his/her team’s achievements. This will indefinitely affect team morale and hamper the positive influence the PO can have on team performance.
Unreflective PO. The Product Owner does not critically reflect on his/her work over the past sprints. They interpret failures as conspiracies against them because “How could it potentially be my fault if I’m not doing the work?”
Lacking vision. The PO does not think beyond the realms of what is possible and employs a vision that is a) uninspiring, b) not unique, c) avoiding any risks, d) missing steps on how to achieve the vision or a combination of these.
Great product people are able to rally their troops behind a common and unifying vision that is compelling, attainable (but somehow bold) and overall inspiring.
