The most common Scrum mistakes and How to avoid them

Since the time I started my Scrum journey, I have witnessed a lot of teams moving to Scrum and trying to work around the framework. They try to crawl like a baby in the initial days and start walking along the path but I haven’t come across any team adopting “SCRUM” as the way of working. At every corner, you can sense the non-scrum patterns and everyone putting the failure scenarios on the process or framework. It is really important to inspect the problem area and ways to move forward successfully. I have tried summarizing few areas which can be identified as the mistakes that the team might fall for:

1. The Daily stand-up meeting is not a status meeting

From the pre-scrum days, the team has been working in a mode where they are answerable either to their manager or the lead for their work. They are in the habit of working through the status meetings. However, Daily scrum or the stand-up meeting is far different, the daily stand-up is for the team as compared to an individual. I have noticed the daily scrum being directional, more of a status reporting to the lead or the Scrum Master.
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.

Source: https://www.scoop.it/topic/l-d-capability-and-role/?tag=Scrum

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. I was surprised to see a development team member dropping an email for the issues in the code after testing, this is not what we want, right? We need to understand the background and why do they prefer written communication over face to face interactions. Are there any trust issues?
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!

Source: https://www.derekhuether.com/blog/tag/Agile+Manifesto

4. Do we need a Scrum Master?

As prescribed by Agile and Scrum Guide, 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, I have observed, 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. In my last project, there was a team, where the product owner was on the south side of the globe and the delivery team on the west.
And the story is not ending here, and even the team members were divided into two different locations in the west. Ahhh! It gets difficult to work with this big distributed team. It not only impacts the collaborative efforts, but it also hampers productivity. Hence, there should be efforts to help the team move together.

Source: http://webipedia.es/2018/06/28/scrum-la-metodologia-agil/

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.

Source: http://biksimg.pw/

10. Thinking Agile means no documentation

In every boot camps or training, I get this question asked: “Is Agile about NO documentation?” We, in Agile, 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.

Conclusion

As a final note, we have been hearing that ‘Scrum is lightweight, easy to understand but hard to master’ and it is true. Here I have just talked about 10 mistakes that we do, but there are many and differs from case to case. It just requires someone to identify and help the teams walk on the right track. You might have come across some mentioned above. And I really appreciate that you identified it, I would be happy to hear from your experience, the mistakes you encountered.
Get ahead. Get Agile Certified.