How to Avoid Common Scrum Mistakes

How to Avoid Common Scrum Mistakes

1. A status meeting is not a daily stand-up meeting

Since the pre-scrum days, the team has been working in a mode where they are accountable for their work to either their manager or the lead. They are used to working via status meetings. The daily scrum or stand-up meeting, on the other hand, is much different; the daily stand-up is for the team as opposed to an individual.

Even in some cases, there will be an individual who will be taking notes from the meeting. This kind of daily scrum facilitation elevates the sense within the team of being micro-managed and being with someone focusing to keep track of what everyone is saying. This not only discourages the team, but it also dilutes the essence of doing the daily stand-up.

2. Impediments not being reported early enough

One of the best things about Scrum is early addressal of impediments so that the team commitment is not hampered as Scrum is time-boxed. Most of the time, if the team member is blocked, they tend to wait or resolve on their own rather than raising a flag among the delivery team. It might work sometimes, but it is not an ideal approach. There may be cases where dependencies are involved.

Hence, raising the impediment upfront helps the teams and the team members adjust their workflow for minimal impact. The Scrum Master should maintain a log for impediments and track them to closure. The team should be provided with an environment to voice their issues without fear. Anything that is coming in their way of delivery should be raised immediately.

3. Processes and tools over individuals and interactions (mindset)

Nowadays, we have effective and efficient online tools to handle the backlog and the workflow, and the same goes for communication too. With such a vast variety of tools, the teams tend to rely more on them rather than individual interactions.  

The Scrum Master can set some working agreements with the delivery team to overcome such issues. The team will be defining how they want to work, and they would be setting their own rules. The focus should be more on collaboration and interactions rather than process or tool, but that doesn’t mean they can go away with it, it is still important!

4. Do we need a Scrum Master?

The delivery team consists of a Product Owner, development team, and the Scrum Master. Each role has its own responsibilities and their own boundaries. This gets thinned when the role of a Scrum Master is not taken seriously. In some of the teams, the team members play a dual role, for example, product owner plus a Scrum Master or Scrum Master plus developer.

It is really critical to understand that if someone with another role plays a Scrum Master, then they are hindering the person’s ability to focus on helping the teams, following processes or removing impediments. It is a very crucial role which helps the ship to sail through along with shielding the team from outer distractions.

5. Commitment based on assumptions

Another common mistake that I have noticed is around making the commitment for a sprint based on assumptions. Why? Because the team is hesitant to ask back, as per the Agile framework, there was no proper grooming done to make it free of assumptions. Most of the times, teams are asked to commit just because the requirement is on priority. They are not given enough time to think through or brainstorm, they just commit. This not only leads to carryover but also lowers the morale of the team.

It is important to clarify the queries with the product owner, talk about the dependencies and constraints. Continuous communication should prevail between the product owner and the development team throughout the sprint.

6. No outputs from the retrospectives

Retrospectives are considered the most important ceremony is Scrum because that is the time when the team inspects themselves and thinks through the actions to make it better next time. There can be several ways of conducting the retrospectives, but the most important part is the tracking of action items discussed in the meeting. If the action items are not closed, the trust on the ceremony gets impacted, the team will start taking it as no value add to the time being spent.

Hence, it is the responsibility of the delivery team to make sure the items discussed should get closed, here, the Scrum Master can help with the facilitation and tracking. Every retrospective should include the status on the last retro items. This gives the confidence to the team that they are being heard and they feel empowered too.

7. Inapt physical environment

Ideally, the Scrum team should be sitting together, all the development team member, Scrum Master, and the product owner should be in a single room or in a single bay. Focus is more on the individual and interactions and face-to-face communication, there are cases where the teams are not collocated.  

8. Missing DoR and DoD

As mentioned in point number 5, the existence of Definition of Ready (DoR) is important to ensure the team is committing the right work. The definition of ready has few parameters as set by the team, to say, when they are good to commit stories in a sprint. In the same way, the team should have Definition of Done, to say when the item committed in a sprint is ‘Done’.

Both DoR and DoD enhances the quality of the product being delivered. The Scrum Master should ensure the creation of this agreement happens before the start of the sprint and it gets revisited once in every three months or whatever frequency they are comfortable in. If the team has defined their DoR and DoD, the dependencies, risks, and unknowns are minimized.

9. Is it a team or a horde?

It is always easy to work with smaller groups, even the Scrum guide talks about having a team size of 7 (+/- 2). When you are working with a large Scrum team, communication becomes the biggest challenge. As the size is big, the ceremonies too will take a long time and with shorter sprints, these meetings become a pain for the team. If you have 3 people then you have 6 communication points. Everyone communicates with 2 others (32). If you have 5 team members then it's 20. For 9 member team, it’s 72.

This is a lot of communication and interaction points in a team. Even the information might get lost in the web of combinations created within the team.  

10. Thinking Agile means no documentation

“Is Agile about NO documentation?” in Agile, you do documentation but the focus is on ‘Comprehensive Documentation’. Even one of the points from manifesto talks about ‘Working Software over Comprehensive Documentation’.

Nowhere in Agile principles or Manifesto, we say NO to documentation. It doesn't mean that you should not create documentation; it means you should create documentation that delivers value and at the same time does not obstruct the team's progress.

‍
Ready to ace your exams? Access our top-notch practice exams for optimal results!

https://prepzo.com/categories/business/agile

‍