Scrum Anti-Patterns

According to Scrum guide:

Scrum is:

  • Lightweight
  • Simple to understand
  • Difficult to master

If we look at the Scrum guide it is a simple 17 page guide that contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together. Scrum is not a process that you can follow to create complex products rather it is a framework which gives us tools to play around with. We experiment, fail, learn, adapt and then experiment again till we succeed.

Scrum Gameboard

22/05/2020, virtual team Sprint Retrospective meeting

“Now I would like to ask each individual what we could have done better?” asked Girish the Scrum master.

“I think we need to work on acceptance criteria, as at times scope is not very clear to the developers.” said Gaurav, a member of the development team.

Did it ring a bell?

Often Scrum teams come with similar improvements calls during the Sprint Retrospective meetings. What was wrong? Product Owner, Scrum Master and Development Tech Lead were having regular backlog refinement sessions, still, there was a call-out from one of the developers. Were we giving enough time to product backlog refinement sessions?

This is an example of Scrum Anti-Pattern and we experience many such examples while working with Scrum teams.

Scrum Anti Patterns

Anti-Patterns in Scrum are behaviors 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, Product Owner or developers) may suffer from some of these shortcomings themselves. This makes it all the more complicated to them.

Ken Schwaber (Scrum co-creator) says, “Scrum is like your mother-in-law, It’s constantly pointing out your shortcomings.”

According to famous Agile coach, Stefan Wolpers – In Scrum, anti-patterns are observed at various levels:

1. Scrum Events Anti-Patterns

  • Backlog Refinement
  • Sprint Planning
  • Sprint
  • Sprint Review
  • Sprint Retrospective

2. Scrum Role Anti-Patterns

  • Product Owner
  • Scrum Master
  • Development teams
  • Stakeholders

In the next section, I will talk about some of the key anti-patterns that we observe very often and then discuss how to timely detect Scrum anti-patterns.


Scrum Anti-Pattern examples:

  • Over-sized and outdated backlog – The Product Backlog contains items that haven’t been touched for six to eight weeks or even more. PO doesn’t have time to work on the product backlog or have delegated the responsibility to Scrum master or development team.
Outdated story in the product backlog
  • Dominant PO- The Product Owner creates user stories by providing not just the ‘why’ but also the ‘how’, and the ‘what’. This generally happens when a product owner comes from a technical background.
Title says it all
  • Missing acceptance criteria- There are user stories in the product backlog without acceptance criteria. This happens when not enough time is spent on backlog refinement or the requirement is too vague/complex.
  • Capacity Issues- The development team overestimates its capacity and takes on too many tasks. They don’t consider to space some time for planned leaves, public holidays or mandatory sprint ceremonies.
Working beyond capacity
  • Flow disruption- The Scrum Master allows stakeholders to disrupt the flow of the Scrum team during the Sprint. Stakeholders could be anyone be it Product owner or line managers of the developers or even a senior member of the leadership team.
  • Variable Sprint length- The Scrum Team extends the Sprint length by a few days to meet the Sprint goal.
  • Death by PowerPoint- During Sprint review, participants are bored to death by PowerPoint. Development team often comes up with a PowerPoint presentation rather than a demo to the actual increment itself.
  • No stakeholders- Stakeholders do not attend the Sprint review. (There are several reasons why stakeholders do not participate in the Sprint review: they do not see any value in the event, or it is conflicting with another important meeting. They do not understand the importance of the Sprint review meeting).
  • No-Retro- There is no retrospective as the team believes there is nothing to improve or the development team decided to utilize the time for pending development work to meet the Sprint goal.
No time for Retrospective meetings
  • Team leads- The development team does not come up with a plan to deliver on its forecast collaboratively. Instead, a ‘team lead’ does all the heavy lifting and probably even assigns tasks to individual team members.

How to detect Scrum Anti-Patterns?

Sprint burn-down charts and retrospective meetings are the best detection mechanism of Scrum anti-patterns. The Sprint Burn-down chart makes the work of the Team visible. It is a graphic representation of the rate at which work is completed and how much work remains to be done over time.

Burn-down charts are by no means tools to punish or reward a development team. Rather these are used by the development team to keep themselves focused towards the Sprint goal. They are equally well suited to provide additional insights into all kind of impediments, both at a team level and at an organizational level.

Following key anti-patterns can be detected by just looking at the Sprint burn-down charts:

  • External dependencies not properly managed or complex (too big) stories picked during sprint planning
  • Late acceptance by the Product Owner
  • Increase in scope during the course of the sprint
  • Team accomplishes sprint goal way earlier than expected
  • If the graph is located above the line of the expected progress for the complete sprint length, it indicates slow progress of the development team.
Sprint Burn-down chart showing increase in scope during the Sprint

It is a good idea to use Sprint burn-down chart patterns for the next retrospective meeting as they easily identify team problems or systemic dysfunctions. Team can then discuss identified issues and come up with the improvement action items.

Conclusion

As I said before, Scrum is difficult to master, so in case you identify these anti-patterns, don’t worry. Most of these anti-patterns are relatively simple to fix and each is an ideal candidate for continuous improvement. Don’t be afraid to challenge your own thinking about bad behaviors that can lead to anti-patterns, and be proactive about coaching your team on how to avoid and stop anti-patterns whenever possible. In bigger organisations, Agile coaches play a vital role in addressing these anti-patterns.

Hope you like the blog..!

Images courtesy: Age-of-product.com, DZone.com