ScrumMasters are stupid

Are you a ScrumMaster? Have you chosen to build your career as a ScrumMaster? Yes? Well, that’s stupid! I mean: It is a job where you will always face resistance to change either from your team or from the organization around the team, or even both. They may not even understand the role. In the beginning you might not even truly understand it yourself. The successcriteria of a ScrumMaster is vague, and difficult to navigate after, so you will constantly question if you are doing a good job.

To some, a job like this is self-torture. It can be sometimes, but other times it is the most satisfying job – at least in my opinion. So if you are as stupid as me, and keep on trying, because you think it is the right thing to do, this blog post might be of help to you.

The purpose of this post is NOT making you capable of avoiding the traps I fell in, because I believe you must learn from your own mistakes. Instead I hope it will ease the fight of getting out of the traps, so the learning process for you, will be shorter than it was for me. Or as a minimum you can identify with the challenges, making you aware, that you are not alone – which can give you some energy to hang-on and continue what you are doing.

Trap 1: Believing you have the skills to change the world after a 2 day ScrumMaster course

How could I be so naive to think that a 2 days ScrumMaster course would solve all the challenges I faced in my team? Writing this sentence seems so stupid, but nevertheless, I felt I knew everything, and I had it all figured out – If just my colleagues would do as I instructed them to.

Looking back now, it was not surprising that I faced a lot of confrontations, when I told businessowners, that have been in business for many years, to change their way of working, based on the 2 days course I have attended.

I learned, the hard way, that being a ScrumMaster is an area of expertise, and I didn’t have the skills at the time to change anything, so my ScrumMaster career could easily have ended there. But my belief, that this way of working would mean better products and higher jobsatisfaction, was still intact, and it kept me in business. I was longing to dig deeper into Scrum and other agile practices to gain knowledge, and experiment with my team to change the world a little by little – Starting with the “world of the team”.

Be humble and let your lack of skills, be the motivator to develop yourself.

Trap 2: Being afraid of “Scrum-buts”

I met the term “Scrum-but” on slide 2, on my Certified ScrumMaster Training. It could be due to my lack of knowledge at the time, or the communication skills of the trainer (or both), that let me to think that deviating from Scrum was dangerous. “Dangerous” like somebody would die. I went home from the training believing that I needed to implement the entire Scrum-guide, word by word. At any cost. When entering Scrum forums and debates online I also get the impression that some other people went home with the same feeling.

Guess what? Nobody dies from deviating from Scrum. In worst case you won’t get all the benefits from Scrum, if you’re leaving things out or doing it differently than prescribed. That doesn’t mean that deviating won’t be the right thing to do in your team. The team might not be mature enough to cope with a full implementation. If the team hate a specific ceremony, or don’t get it – then don’t do it. Show them you care about their valuable time. Introduce the ceremony again when the team feels a need for it, or it can help the team solve a specific problem.

Of course, you should know what Scrum is, and what is isn’t. And of course, you are not allowed to state that Scrum doesn’t work until you have tried a full implementation. And if you are stating it doesn’t work, you are most likely doing something wrong.

Don’t be afraid of Scrum-Buts – be aware. Don’t be afraid of deviating –  experiment, inspect and adapt.

Trap 3: Getting too excited about a tool

During the journey of building your ScrumMaster toolbox – I’m not talking about the physical box of sticky notes and markers, I’m talking about the toolbox of agile tools, practices, methods, theories, activities etc. – you occasionally run into a tool that inspires you so much that you cannot help introducing it to your team. Only to find out that the team hates it and/or find it useless and resists using it.

It is frustrating to see your teammates don’t “see the light”, and the backbone reaction of a ScrumMaster is often to try to convince them. I have done this several times, and unfortunately I don’t think I have done it for the last time. Preaching is not helping – You will waste your time like a Christian trying to convince a Muslim to convert (or vice versa).

The reason for the team not wanting to use the tool, could be either because they don’t see the problem, the problem doesn’t even exist or simply because they don’t think the tool can solve the problem.

Therefore, when trying out new tools, ask yourself: What problem is it going to solve? Does the rest of the team share the same problem?

If you can’t answer the first question, don’t even bother implementing the tool. If the answer to the second question is no, then either let it go, or help the team see the problem before experimenting with the tool.

Trap 4: Not acknowledging peoples thoughts or perspective

As a dedicated ScrumMaster you are most likely a few steps ahead on your agile journey compared to your teammates. This can easily end in a situation where you say: “Yeah yeah, I understand, but here is what you should do”. Your suggested action might be the correct one, but it slips over the head of your teammate and nothing happens.

In the beginning I was getting frustrated of why my teammates wouldn’t listen – after all I studied this subject, so I knew what I was talking about. I tried to explain solutions to problems I spotted. But I couldn’t solve the problems I spotted, and even worse, my teammates felt I wasn’t solving their problems either. After I started caring more for what they saw as problems instead of what I thought was the problem, it was a lot easier to help the team. Asking questions to my teammates rather than explaining solutions helped me identify and solve the real problems. It also helped me selecting the right tools to solve problems. I still see problems the team doesn’t see, but I tend to prioritize doing something about the problems the team sees. Simply because the effect is greater.

Acknowledge your teammates thoughts and perspective and care about them as if they were your own, will help you become a great ScrumMaster. If you spot a problem, ask you team if the see the problem too. If they don’t, acknowledge it and let go, for a while.

Final thoughts

If you made it so far reading this post, I assume that you are still hooked on a career as a ScrumMaster. That’s great. You have at least showed persistence to some degree – keep it up, you are going to need it. But I’ll tell you, the reward of seeing your teammates or organization benefit from your work, even in small scale, makes it totally worth the effort. I have even come to a point where I enjoy the resistance and see it as the next hurdle I need to jump – but it may also just be stupidity in disguise.