Question: Advice to a beginning ScrumMaster

Question: “I am a beginning ScrumMaster in a tough situation. I have some ideas, but I am unsure what to do, and unsure what to do first. What can you suggest?”

Answer: I think this is common.

In reality, there is no end to the things a ScrumMaster can do to help the team. So, your question about what to do first is important.

First, take what you already know about Scrum, and remind the team what Scrum is, and why — what the values and principles are.

This can be done in a thousand ways. One example: Post the Agile Manifesto and the Agile Principles in the Team room. After each Daily Scrum, ask each member of the team to take two minutes to explain something about one line or one item from the list.

You will be impressed how well they explain the agile ideas to each other. Then, each time you can add an additional insight. Maybe something you think they could improve on.

Read or re-read “Agile Project Management with Scrum” by Schwaber to get lots of stories and ideas about how Scrum should work.

Second, get a better list of impediments. OK, let’s be honest — Start a list, a public list. Yes, of course collect the ones they tell you in the Daily Scrum and in the Retrospective, add the ones that you see, read this blog and steal some impediments that apply to you and your team.

You want a list of the top 20 things to improve, broken down into actionable things, where you can see, smell, notice improvement in two weeks or less. Yes, you often start with some epic impediments, but just start there — break it down.

An impediment is anything, ANYTHING, that is slowing down the team. Examples: Anything that stops a story, or just slows down the team. People issues, technical issues, organizational issues, the weather, I need coffee, I need a dentist, we need a different culture, whatever, whatever.

OK, we have to discuss two things that happen universally in the Daily Scrum, at least at first. They don’t divide the tasks into small pieces, and they talk vaguely about what they worked on, and do not focus on what was DONE (completed). The tasks must be mostly in the two to four hour range. They must say whether or not it was completed. If a four-hour task is not completed in one day, clearly there is some kind of “impediment” (e.g., “I cannot estimate very well”).

Then, they must give their biggest impediment (what slowed me down the most.) Time itself is not an impediment.

It might be: “I don’t know this area of the system that well.”

Or: “The servers were down briefly.”

Or: “Well, if the tests were automated, then I could have found the bad code faster.” 

Saying: “None” is not an option. Implying that “things are so good around here, that there is no way it could possibly get better” is also not an option. Things can always be better. Saying “I am perfect” is not an option.

Give them a challenge. Tell them: “We have to double the Velocity, in a way that we believe, and not by working any harder. So, what do we have to change to do that? Imagine anything could change. Anything.  That the managers will approve anything, if a good case can be made.”

For the Retrospective, see also “Agile Retrospectives” by Derby and Larsen for more ideas to uncover the real impediments. They have forgotten impediments because they have become used to them, or they can’t imagine that it could be changed.

Third, aggressively attack the impediments. Every day. Every hour. Take the top one, and go after it. If you can’t fix it yourself, that is fine, but get someone to.

I do not mean go crazy, use some common sense. If the cost is greater than the benefit, then solve it another way. Sometimes you can only mitigate the impact, etc., etc. But still, every day and every hour, attack the top impediment.

Fourth, tell them. Tell the right people what you will do, what you are doing, and what you have done. Mostly, you tell the team. How? In the Daily Scrum (you answer the questions, and tell them). In the Retrospective, in other ways that make sense.

Why? Well, not to brag as such, but you need to know they care. They want the “fix” that you will give, are giving, did give. Also, once they know things are getting fixed, they will get more creative talking about things you could fix.

Fifth, keep a list of “fixes installed.” All the things you did, or got done, to make their lives better. Why? So, when you are discouraged, you can look at the list and get some encouragement so that you can remind them of the value of a SM, and so you can justify to the managers why you deserve a raise.

Track the list, and make a reasonable guess as to how much of the improved Velocity of the team is attributable to the fixed or mitigated impediments. Typically 100 percent is effectively attributable to you.  Yes, Scrum itself did some (but you still take credit). Yes, the team did some things, but honestly probably would have done very little without you, or would have done it much later. You made it happen, you were the key. It does not matter that some improvements cost “extra” money. The benefits were huge, and mostly would never have happened without you.

Do not slack for even one day on this.

The team and the customers deserve everything you have to give. You too will be rewarded in ways hard to explain but very clear — by all the good things you make happen.

Sixth, to help you become a better ScrumMaster faster, start a ScrumMasters group with other SMs in your area. Learn from each other. Maybe have a brown bag once a week and present ideas and experiences to each other.

______________________

Those six ideas are just a start. There are many places and ways to learn. As you act, you will discover more ways to learn, and more things to learn about being a better SM.

Does that help?

 

« « Organizing a small-ish company to do Scrum and ‘regular work’ || Charlotte Apr 2014: Public impediments » »