These are 5 mistakes I have seen many times and of course, I've made them myself in different magnitudes and variations. So what I'm trying with this article is first to remind myself what I believe I must avoid doing and maybe help others from doing the same.
1. We act as a proxy for communication between teams
This is the first and most frequent mistake scrum masters make. Scrum Masters should encourage the team members to speak directly to team members of other teams.
The impact of not doing that and act as a communication proxy is that when the scrum master is not around, they don't do it by themselves. Because they think that it is the Scrum Master responsibility to do.
What a scrum master should do is to make sure the team members not only talk between them but also with other people outside the team. This is essential for agility in team and organizational levels. Inefficient communication and collaboration were (and still are) the number one reason for failing to become more agile.
Therefore building autonomous teams means also make the team seek communication and help when they need it.
There is an invisible line between removing impediments outside of the team for the team and communicate as a team representative or being a proxy. I will gather my experience on a different article on what remove impediments means but for now try not to be a proxy for essential information.
2. We promote "us and them" culture without realizing it
Every agile transformation has enormous challenges. One of them is different speeds in the adaptation of new ways of working in different silos in an organization. A classic case is that the engineering teams start to use scrum and nothing changes for months in the rest of the organization towards agile mindsets.
This, of course, will create friction between the teams and the rest that are used to work in a different way. The common mistake that many scrum masters do in such cases is to see the team as the most important thing in the world to focus and whatever gets in their way in one way or another as the "enemies" that prevent them to succeed. This sometimes drives the scrum masters to present themselves as allies of the team against "the others".
That behavior, which sometimes is driven by a need of a scrum master to feel accepted from the rest of the team, leads to more "toxic" environment and bad culture, blocking, even more, the transformation towards agility.
Instead, what a scrum master should do is to understand and have empathy on every "side" or perspective in the organization since this will get him closer to exercise influence. Being an "enemy" with someone doesn't let you think clearly and also prevent you to apply an influence strategy to improve collaboration and common goals.
Simply putting, you cannot influence if you don't have the opportunity to influence. Many such opportunities are lost simply because our "eyes" see enemies instead of humans with different perspectives and beliefs.
3. We forget the number 9 agile principle
Principle number 9 in the Agile Manifesto says: "Continuous attention to technical excellence and good design enhances agility." This sentence alone includes a huge number of practices and mindsets regarding technology and ways of working in systems and code.
Scrum masters that forget this principle tend to focus only in Scrum and they are not paying attention to how agility is affected by not considering also the technical practices. A problem that contributes to that is that unfortunately, scrum guide doesn't say anything that derives from this principle.
Instead, what a scrum master should do is to start reading and seek for understanding regarding software craftmanship and even other well-established practices derived from XP and the DevOps movement.
4. We forget the 3rd Scrum Master service mentioned in scrum guide
Copying from the Scrum Guide, one of the three major services of a scrum master in an organization:
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:Leading and coaching the organization in its Scrum adoption;Planning Scrum implementations within the organization;Helping employees and stakeholders understand and enact Scrum and empirical product development;Causing change that increases the productivity of the Scrum Team; and,Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
Not focusing also on that, tends to limit the effectiveness of a transformation or in general the never-ending struggle to become more agile. Especially in a multi-team environment trying to find new ways of working, it is necessary for the Scrum Masters to lead that change and help everyone else understand and contribute in the right way.
That goes back in an article I published in 2015 for the details of that responsibility. Long story short, the Scrum Master with the help of other Scrum Masters or Agile Coaches should lead the change.
5. We do not study frameworks for agile at scale and other ways (XP, Kanban etc)
One last mistake I have seen and of course made in the past, is the wrong assumption that scrum is just the best among dozen of other frameworks. And particularly because scrum is the most common it must be the best one so why bother learning and practice others. The impact of this wrong assumption is to study and practice only scrum which leads to mistakes like the 3rd one I mentioned above.
The reality is that many things between practices in frameworks are complementary and not only overlapping. XP for example, give guidance on how to approach the writing of the code and testing which enables agility. DevOps movement gives you the way to remain agile by fast delivery and feedback along the way to production exploiting the lean principles in both process and technical matters.
The list does not stop to technical of course. Practices on other crafts such as UX (for example Lean UX) and management should be studied to understand the challenges of becoming and remain agile in a broader sense.
Finally, scaling and remain agile is a huge challenge. Many practices are already out there such a LeSS, Scrum@Scale etc, which give quite many ways of approaching these scaling challenges.
So this mistake is not only for scrum masters but for every agile coach that starts from a practice or a framework. Because scrum is the most "famous" the majority of people who start to understand agility begins from there. The reason that scrum is the most famous is not that it solves all problems, but because is a thing that management understands better and can easily be replicated.
The true struggle comes with complex things such us XP and DevOps. If software was only a management problem scrum would have been enough. Unfortunately, it isn't.