How to defend against the 10 things that drive your ScrumMaster crazy

During my time as ScrumMaster I collected an interesting list of bad behavior in Scrum teams called the „10 things that drive ScrumMasters crazy„. At the same time I started thinking about what I could do about it and how to stop the dysfunctional behavior in my team. I searched for the causes of the different behaviors and I found a lot. But what you tend to see at first is only the surface and not the real reason. That’s why I began to dig deeper to find the real cause. In the end I found out that everything can be condensed to four root causes. I call them „The four evil root causes from hell“:

• Ignorance
• Fear
• Indolence
• Apathy

Ignorance

I met teams were the only Scrum training they got was the link to the Scrum article on wikipedia.org. It’s no wonder that they don’t know how to implement Scrum if there’s nobody to train or coach them. Sure, there are some rare teams were wikipedia may be enough but most teams new to Scrum, especially in bigger organizations are in need for some initial training and at least somebody who has some experience with implementing Scrum. E.g. if a team member is doing tasks that are not part of the Sprint Backlog because Harry Smith* told him it may happened because nobody told her that it is the job of the ScrumMaster to stop these disturbances. It’s the same with hidden impediments. Most of the time they are not hiding their impediments on purpose they just don’t know that they can bring it to the team or ScrumMaster. There are several other things on the crazy list that are caused by ignorance.

Overcoming this root cause is relatively easy: Train and coach the team! When I start with a new Scrum team I’m using a special recipe. You can read about this recipe here: „How to kick off your new Scrum team„.

Fear

Fear is not only a problem in software development (Oh, really?). Fear can be a problem in any domain or private life. In software development it’s primarily the fear of change, the fear to learn something new or the fear to lose control. If a team member don’t want to work on a task because it doesn’t fit in what he was doing in the past it’s mainly a fear to leave his comfort zone. If the team member doesn’t want to split his tasks into smaller ones it’s maybe because he has the fear to be tracked. Or if a team member always asks the ScrumMaster what to do next she may have the fear that she won’t be able to solve any of the tasks in the sprint backlog, Fear can be the reason to a tremendous amount of dysfunctional behavior. And that’s why fear is one of the evil root causes.

A few years back I was working for Volkswagen. After one year as employee my manager told me that I’ll attend a training called „Self organization and self management“. When I talked to other Volkswagen employees about this training I was faced by a lot of rumors. They told me that this is a real tough training and that several attendees canceled the training because they could not stand the psychological pressure. Now I was curious 😉 The first day of the training started and nothing special happened. But in the evening of day 1 they came up with the rules for the next 3 days: Everybody has to do something which is out of their comfort zone. The procedure was like this: When you think you are ready for your „Performance“ you have to stand up and say load „Performance“. After that the other attendees are clapping their hands. Then you start doing whatever is challenging for you. It was up to the attendees when they start their „Performance“. Interestingly most of the attendees did their „Performance“ before lunch. We had people praying with us, reading books (everybody laughed at him in school), dancing and so on. And now guess what I was doing? I did a presentation in English. At this time it was a real challenge for me and completely out of my comfort zone. But after the 3rd presentation in English I started to feel comfortable. I increased my comfort zone. If you like I’m a living example that this method worked. This is why I still believe that this methods work. So kick your team mates out of their comfort zones 😉

Indolence

Ever tried to move a car were the motor is broken? You have to put a lot of energy into pushing the car to get it moving. It’s the same with indolent people. They are sitting at their desk or standing at the coffee machine and are just doing nothing. They don’t have the energy to get themselves started on a new task and instead they are procrastinating all day, week, month or even year. These people are late at meetings, won’t start to work on something new or doing any other stuff but their work. If you have such people in your team it won’t take long until other team members will complain about him. You have to find a solution to start their engines on a easy way to get them working with the team.

The following methods have been proven to work:

Get their commitment

It’s not only a phrase if the ScrumMaster asks the team in the sprint planning if every team member commits to the sprint goals. But sadly this is sometimes happening. Comments from team members are ignored or everybody is just nodding their head without really being committed. Get their real commitment, this is important. In new teams you could write an informal contract with the sprint goals that every team member has to sign. Put the contract on the wall of the team room so that everybody can see it.

Rotate the moderator role

In Scrum there is no rule that the ScrumMaster has to moderate all meetings. Instead rotate the moderator role. The sprint retrospective is a great meeting to start with this approach. Try it you’ll be surprised by the results.

Use Avatars

Every team member should have an avatar on the sprint backlog. With this approach everybody can see who is working on what. This helps the team to recognize if somebody is working on the same task for days and gives them the chance to check what’s the problem with it.

Involve them

I saw a lot of e.g. sprint plannings were one or more people didn’t really participate. They were just sitting around listening (or playing with their phone) instead of working with the team. If you recognize this behavior involve these team members. Ask them what’s their opinion on the current backlog item. Avoid that only 2 or 3 people are working on a new story. Involve everybody!

Apathy

Apathy is the most evil and most dangerous evil root cause of all. If their’s one team member getting apathetic you have to immediately do something about it otherwise it will spread like cancer. A apathetic team member is easy to recognize. He talks bad about the company, the project or the management. He doesn’t participate and nothing matters to him. It doesn’t matter for him to be late it doesn’t matter to him what is defined in the DoD and it doesn’t matter to him what the feedback is like in the sprint review.

Even if apathy is IMHO a root cause in most cases their is an additional cause which leads to this state. Often this isn’t an easy one. Start doing face-to-face interviews with every apathetic team member to find out what’s the problem. After you collected the data from everybody decide what to do next. If the reason is technical debt schedule a workshop to define how to cope with it. Build a vision describing how to solve the problem so that everybody sees that a real chance to overcome the problem. If you find out that their is a insulating layer between management and the developers I wish you good luck 😉 No serious, that isn’t an easy one and I can’t really tell you how to overcome this because this could mean a complete mind shift in the whole company which isn’t simple. It really depends on the management and if they are willing to change something.

You can also try to introduce an FedEx-Day or 20% time like Google or Atlassian. At Google every employee has one day in the week were he can work on whatever he likes. In this 20% things like GMail, Google Maps, Google Buzz or the Google Wave were created. If 20% sounds to much start with 10% (e.g. Friday afternoon) and try it for e.g 6 weeks. Do a retrospective after this time to find out if it had some benefit. You can read more about this in Daniel Pink’s book „Drive“.

Conclusion

There are no silver bullet solutions for the 10 things that drive ScrumMasters crazy or any other dysfunctional behavior. But their are some things you can try. Let me here if you had success with one of the suggestions above or if you solved on another way. Every feedback is welcome…

Here is a short ligntning talk I did a few moth ago about this topic. Enjoy!

How to Defend Against the 10 Things that Drive Your Scrummaster Crazy from ACE! Conference – Best Practices on Vimeo.

Here are the slides of my talk. Unfortunately Slideshare doesn’t like the color of the font:

Want to rate my talk? Go here: