More and more often in the IT world, especially among developers, I observe some kind of “scorn” and dislike for Scrum and Scrum Masters.
I, as a Scrum Master, am not particularly happy about it, but I try not to fight it myself, but rather understand the other party and only then react. Scrum starts to be massively popular, and I do not associate massive popularity with quality, so maybe it is worth facing the music and changing something in yourself? I recently created a simple survey and asked three bakers of the Scrum cake, i.e. Developers (previously known as development teams), Product Owners and Scrum Masters to answer one open-ended question: What mistakes, failures and sins are on the conscience of the Scrum Master you are working/have worked with?
My “research group” was quite small as it consisted of 33 people (7 Product Owners, 7 Scrum Masters, 19 Developers), so the study cannot aspire to be called scientific. However, the feedback I got is very interesting.
Pride and distrust
In the past, Developers, Product Owners and Scrum Masters sometimes felt that the heroes of our article were full of pride. There were accusations that they patronized the team and imposed their own solutions due to lack of trust, not allowing them to show initiative and organize their work. This is a serious accusation and a grave violation of Scrum values. Of course, a Scrum Master can sometimes propose solutions that should result from their experience, but remember that the team should self-organize, even self-manage and from time to time even be allowed to make mistakes. Why? Because humans, just like teams, learn from their mistakes.
Lack of soft skills
According to the respondents, there are Scrum Masters who have considerable difficulties in building relationships with people. Difficult personality, poor communicability, lack of empathy of a Scrum Master can sometimes lead to a crisis in the team. One of the surveyed people gave an example of a Scrum Master unknowingly (due to the lack of soft skills) causing great tension between the Developers and the Product Owner and a crisis. Let’s not kid ourselves, Scrum Masters, like all people, have better or worse social skills, but it is impossible not to notice that this should be a role that unites people, not tears them apart. I do not mean unnatural resolving of conflicts, because sometimes conflicts are good and can be constructive.
Submissiveness and lack of assertiveness
A sin that is the opposite extreme to the one that has been mentioned first (it means that not all SMs commit the same sins). In the answers appeared Scrum Masters who were so helpful, did so much for the team, were always at their disposal… and as a result, the team walked over them. They became a pushover and their position of a “leader who helps” turned into a true servant who is no longer a leader. “SM becoming a proxy and behaving like a secretary” is the quintessence of this sin. There are also accusations of lack of assertiveness, allowing sprints to be planned by PO, and not the team. How is such a Scrum Master supposed to protect the team from being given impossible deadlines, how is such a Scrum Master supposed to provide the lazy ones with negative feedback? How is such a Scrum Master supposed to go on leave when no one is prepared to run daily or planning meetings?
Factual errors
This is a grave sin. Let’s be honest – such sins destroy the entire Scrum Masters market. Fortunately, there were not many such answers, but they appeared and let’s take them to heart. Unfamiliarity with Scrum, giving way all the time to be nice (scrumbuts) or pretending at the DEMO (deception of reality) are totally unacceptable.
Lack of agility
A lot of answers were related to this accusation. “Too much emphasis on the Scrum/Agile process” was one of them – making Scrum an idol, instead of striving for creating an autonomous team. Unfortunately, the people we work with as Scrum Masters sometimes see us as people who value the process more than the benefits that it should bring. It happens that we stick rigidly to the process, focus on mechanisms such as scheduling meetings in our calendars and playing with JIRA – all without looking at their value to the team. We forget about the most important element – team support, e.g. in understanding and achieving sprint goals. In addition, constantly extending meetings that lead to nothing and have no agenda can put the team off their stride.
Overbearing attitude
The list of comments here was quite long. There were many examples of Scrum Master’s controlling too many areas, ordering the team around and micromanaging – being a coordinator, controller, assigning tasks and limiting the self-organization of the team. And also, playing the actual role of a Manager. Let’s not be like Managers (I have nothing against Managers!) – stop controlling everything, let the team develop and trust them.
Imposing own ideas, manipulating the team and questioning their competence are not OK. Remember that Scrum is about a flat structure. There are times (especially when teams are created) when the Scrum Master is more active and sometimes proposes more solutions, but you need to distinguish between management and support. The Scrum Master is there to support.
Negligence
A good Scrum Master is a committed Scrum Master. If, for example, there is no follow-up after a retrospective, let’s not be surprised that no Developers are “fans” of these meetings. If all we do is administer Jira, calendar and meetings, then let’s quit. Unfortunately, a lot of comments related to the neglect of teams by Scrum Masters: lack of presence, lack of care for e.g. refinement, lack of intervention in difficult moments, lack of support for the team and Product Owner when needed.
Summary
After listing the above sins, a rather negative picture emerges, but it is difficult to get an optimistic message when it comes to sins. So I’ll add fuel to the fire and say there are more sins! However, instead of keeping our heads down and contemplating, I propose to treat these opinions and examples as a starting point for a kind of self-reflection based on the analysis of mistakes that we all certainly make sometimes.
What to do with this knowledge? We’ll grumble and that’s it? I leave it to everyone to consider.
If I can suggest something to Scrum Masters (also to myself), I advise you to constantly be in your listening mode and encourage the teams to be transparent. It will certainly help to notice and reprocess any negative feedback before it gets to us when it’s too late. The trust of the team is like a forest – growing slowly but burning quickly.
What do I recommend to people working with Scrum Masters, i.e. Developers, Product Owners and others? Make sure the Scrum Master is aware of your needs and worries. A leader who supports you will not be able to do so effectively without this knowledge.
I wish all teams great Scrum Masters!
PS I talked about it at a meetup some time ago. We did a short retrospective session after that and those were the key indicated mistakes:
- SM’s lack of assertiveness
- Process more important for SM than pragmatic approach
- SM does not understand the Scrum spirit/idea/logic and repeats and implements thoughtless schemes
And we came out of this meeting with such conclusions: “what should we say to Scrum Masters openly”
- Accusation: lack of assertiveness:
- Accusations: process more important than pragmatic approach & lack of understanding of the Scrum spirit/idea/logic, repeating and implementing thoughtless schemes:
