Product Management Blog – Pankaj Bisht

According to the Scrum guide:

Scrum is:

If we look at the Scrum guide (2020), it is a simple 12-page guide that contains the definition of Scrum. This definition consists of Scrum roles, events, artefacts, and the rules that bind them together. Scrum is not a defined process you can follow to create complex products or applications. Instead, it is a lightweight framework which gives us tools to play around with. We experiment, fail, learn, adapt and then experiment again till we succeed.

---

Cloud migration team Retrospective

“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, the scope is not very clear to the developers,” said Gaurav, a development team member.

Did it ring a bell?

Often Scrum teams come with similar improvement calls during the Sprint Retrospective meetings. What went wrong? The Product Owner, Scrum Master and the Development team were having regular backlog refinement sessions, but still, there was a call-out from one of the developers. Were we giving enough time to product backlog refinement and the sprint planning sessions? Why user stories were not correctly written?

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

Scrum Anti Patterns

Anti-Patterns in Scrum are behaviours that are frequently exhibited but overall ineffective or maybe even harmful. These anti-patterns occur throughout the Sprint and ultimately hamper the positive outcome (sprint goal). Furthermore, even agile practitioners (such as the Scrum Master, Product Owner or developers) may suffer from some of these shortcomings.

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

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

---

Scrum Anti-Pattern examples:

• Missing acceptance criteria- There are user stories in the product backlog without acceptance criteria. This happens when insufficient 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 spare some time for planned leaves, team training, public holidays or mandatory sprint ceremonies.

• Flow disruption- The Scrum Master allows stakeholders to disrupt the flow of the Scrum team during the Sprint. Stakeholders could be anyone, be it a Product owner, business stakeholder, line manager of the developers or even a senior leadership team member.
• 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. The development team often comes up with a PowerPoint presentation rather than a demo of the increment itself.
• No stakeholders- Stakeholders do not attend the Sprint review. (There are several reasons stakeholders do not participate in the Sprint review: they do not see any value in the event, or it conflicts 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 utilise the time for pending development work to meet the Sprint goal.

• Team leads- The development team does not devise 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.
• Dependencies – Internal and external dependencies are not discussed and addressed in advance. They are addressed at the last moment, thus creating a blocker situation for the Scrum team.
• HIPPO (Highest Paid Person’s Opinion) prioritisation – At times Scrum teams take the views of the senior/influential person too seriously and prioritise whatever is asked or demanded by him/her.

• Absent PO – Like the dominant PO, the absent product owner is also harmful. Though a product owner doesn’t need to attend daily Scrum, he should still be present to clarify any doubts and answer questions from the development team.

---

How to detect and address Scrum Anti-Patterns?

Sprint reports and events are the best detection mechanism for 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. Instead, 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 kinds of impediments, both at a team level and an organisational level.

The 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 for a sprint)
• 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.

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.

Similarly, observe whether some of the above anti-patterns have cropped up within your team setup and the best place and time is during the Scrum events. If you observe something is wrong, make a note, discuss it in the team retrospective, and devise corrective actions. Psychological safety is also essential; if team members fear speaking their minds, nothing will come out of retrospective meetings. The Scrum team (especially the new members) should be made aware of the Scrum framework via regular training sessions. The standard you walk past is the standard you accept; it becomes a norm.

Finally, the product owner’s role should be respected and given enough freedom to actually own the product outcomes; he/she shouldn’t just be a scribe or a note-taker. This happens in organisations where top brass don’t buy into Agile/Scrum or servant leadership and still prefer to work in a command and control environment. You may further read into how we can convince the top brass (C-Suite) in such situations.

Conclusion

As I said before, Scrum is difficult to master, so if you identify these anti-patterns, don’t worry. Most of these anti-patterns are relatively simple to fix, and each one is an ideal candidate for continuous improvement. Don’t be afraid to challenge your thinking about destructive behaviours that could lead to anti-patterns, and be proactive about coaching your team on how to avoid and stop anti-patterns whenever possible. Agile coaches are vital in addressing these anti-patterns in more prominent organisations.