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.

Visualisation of “Very very important tasks”

“I have this very important task that needs to get done. Who will do it?”
This is a phrase often heard, and every ScrumMaster eventually will have to deal with. A mature agile team will have it’s work agreements and processes to deal with this type of request in an efficient manner. However, not so mature agile teams, and teams in a early state of their agile journey, should be very alert when hearing this sentence, as it maybe a symptom of an underlying and more serious problems.

But why should we be alert? It’s just <someone> who wants to get this task done, what is wrong with that?

There is nothing wrong with the desire to get things done. After all, this is what companies live from. But there are many underlying problems that this particular sentence can be a symptom of.

In a software development team of mine, we faced failed sprints. Every 2 weeks. Mostly due to this type of requests. Ever changing priorities was one reason for not meeting sprint goals. The solution to this, according to the “Scrumbook”, is obviously to lock scope of work for a sprint, and move the incoming requests to succeeding sprints. This just didn’t work for us. Developers felt this was the same as saying “No, your tasks is not important”, and product management did not like to hear that. It worked for nobody. We did not have a full time product owner, which was also a part of the problem. I have written about this subject in another blog post https://agilereflections.dk/2016/10/12/lack-of-product-owner-what-to-do/

All tasks are important, otherwise it won’t be a task in the first place. Therefore the argument “I have this very important task” is not an argument for getting the task first in line. Believe it or not, adding another “very” or even “very very very” doesn’t make the argument better. So let’s stop discussing if a task is important, let’s discuss how important is it compared to the other task we have, seen from a company perspective. This may sound simple, and result in what we know as a “prioritised backlog”, but it can prove to be difficult to understand for some – even people with agile training.

It was a big issue being part of a team who got “slammed in the face” every other week with “The sprint failed – Again”. So to keep our motivation up, we decided to kill “sprints”. With that decision our board turned into a plain kanban board, where the highest priority was on top. This gave instant advantages such as:

  • As developers we could say, “We can do the task, it will be placed on our board”
  • Product management no longer felt their tasks was not taken seriously.
  • Priorities became very visible, and a constructive dialogue instantly began.

Even though the amount of task on the board exploded, it was a relief for the team, because, we were able to focus on the task on the top of the board, and we could be flexible. As product Management experienced that the tasks on the top of the board got done quicker that the others, they began discussing priorities from a company perspective rather than a personal perspective.

The visualisation of work was the first step towards managing the flow of work, rather than managing people to do the work.

 

 

 

 

 

 

Doing Scrum – Leading the way – Learning agile

“I have heard Scrum is ‘the thing’, please google it and implement accordingly!”. This was the exact words from a previous boss of mine, when he wanted me to make our team deliver on time and with the desired quality. This was the beginning of my career in “doing Scrum”.

I have learned quite a few lessons since. In this blogpost I will deal with a few of the hardest challenges I have faced. You will most likely not learn from my mistakes, but being aware of them, may help you overcome them faster when you face them. Continue reading “Doing Scrum – Leading the way – Learning agile”

Let’s call off Scrum!

A software development team, had been “doing Scrum” for years, since it was decided that Scrum was the “way to go”. A classic. All meetings were conducted, but gave no or little value. It was just accepted like “that’s what happens when Scrum meets reality”. Failed sprints were the standard, frustrations were building and unfortunate leadership mecanisms were “needed” to get things done.

When I was appointed as the ScrumMaster, I quickly realised that I had to do something drastically to gain the team’s trust to Scrum, and to build the team’s trust in me, as a ScrumMaster. Especially because I do not have a developer background. I had to relaunch Scrum in a way I had never tried before…

So I said: “Let’s call off Scrum!”

Continue reading “Let’s call off Scrum!”