Confessions of a New ScrumMaster

An article I wrote was published on the Scrum Alliance site.
So, you just got out of your CSM class, overflowing with your newfound Scrum knowledge and renewed faith in software development practices. You’re ecstatic to share your new view of the world and show how Agile can benefit your organization, and you can’t wait to get started. But, in your first Agile project, you meet resistance, opposition, and worst of all, modified Scrum practices. What’s a ScrumMaster to do?

Don’t lose hope! You’re definitely not the first ScrumMaster to meet these barriers, and you’re not alone. I’ve encountered these situations in projects and have some tips to make the transition to Scrum easier on the team, the leadership, and you. Learning to overcome these problems will make you a better ScrumMaster and will help lead the team to the high performance levels you know it’s capable of.

1. Start slowly.

Agile/Scrum is a big change for most teams, companies (especially large corporations), and cultures. Just because you’re confident about the wonders of Scrum and Agile doesn’t necessarily guarantee that everyone else will feel the same way at first. Trying to implement everything at once can sometimes work, but only if you have the right team. If you’re at an organization where you can handpick your team, great. But if you’re like the rest of us, you get a team handed to you, and Scrum adoption can be hit or miss. So start slowly, address team concerns, build trust, and . . .

2. Be patient.

I can’t stress this enough. The team will not self-organize the first day, nor likely not even the first iteration. Agile tools likely won’t be updated daily by everyone to begin with. Stand-ups may go over 15 minutes or stray off the three-question format. Try to remain patient and coach your team by gently reminding them of Scrum principles. They’ll get there in their own time. Remember, the team needs to learn to work together, trust each other, trust the process, and trust you.

3. Stick to Scrum.

When the team is allowed (or urged, perhaps by management) to stray from Scrum practices, you’ll see an addition of unnecessary complexity. Your job is to coach the team in the fundamentals of Scrum, which have been proven to be successful, and protect the team from outside influences. As tough as it is, try your best to keep everyone on board and avoid modifying Scrum. If people and management are insisting that things in this project are different and Scrum practices need to be modified . . .

4. Ask, “Why?”

This simple word can yield big realizations about how things are done. Often the stated reason for straying from Scrum isn’t actually the underlying problem. By asking why, you can find the root cause and start to solve the real problem. And if you don’t get a good answer, keep asking; sometimes it takes a few “whys” to get to the bottom of things.

5. Explain.

When you let the team know the reasons you’re doing things, or the reasons they’re being asked to do things (note: I say asked, not told), they’re much more likely to do them for you. By confirming that the team understands why things are being done a certain way, they’ll feel more empowered because they have a clearly defined purpose and understanding.

6. Empower the team and yourself.

By empowering the team, you’re giving them the power to empower themselves. This is the first step to self-organization. By empowering yourself, you’re showing and encouraging the team to follow suit. Teams learn by action; when you eat, breathe, and live Agile, they’ll notice. Also, with self-empowerment you’ll feel better about what you’re doing and will be a better ScrumMaster.

7. Ask for help.

Let’s face it, the CSM course didn’t teach you how to handle every situation. There are going to be complications with the team, the stakeholders, and management. Don’t try to handle everything on your own. You expect the team to come to you for help removing roadblocks, and you should demonstrate your ability to bring up problems as well. By waiting too long to ask for help, you can put the team in jeopardy — the opposite of what a ScrumMaster is supposed to do.

8. Ask for and give feedback.

This goes back to the “inspect and adapt” principle. Feedback doesn’t need to be saved for the retrospective at the end of each iteration. If you see something that can be improved, bring it up in a constructive way so you can help correct it early. Ask the team to give you feedback as well. By showing them that you welcome their views, you’re creating an open culture and a great environment for continuous improvement.

9. Trust the team.

I’ve talked about trust a few times already, but it’s so important that it needs to be discussed separately as well. Trust is one of the most important elements, if not the most important element, that the team needs. Team members need to trust you, know you trust them, and trust one another. A team that has trust can deliver great things even while dealing with some of the obstacles discussed above. They trust that they’ll be led in the right direction, will develop the right things, will add business value, and will be successful. Most important, they trust that failure isn’t bad; they trust that they’ll do better and won’t make the same mistake again.

10. Get comfortable being uncomfortable.

Scrum is going to be uncomfortable at first. Things aren’t going to be perfect right away: Team velocity will be messy, team dynamics will take a while to develop, and executive support won’t always be there. As a ScrumMaster, you’ll run into a lot of unknowns, and it’s normal to feel uneasy. Furthermore, when a team is allowed to self-organize, it must be given control. Especially if you’re a traditional project manager-turned-ScrumMaster, this may make you anxious.

Additionally, it’s uncomfortable to tell people “no.” You need to be comfortable telling outsiders when they can and can’t participate. You need to direct superiors to the product owner to get things added to the backlog, and not let them add elements smack in the current iteration. You need to disagree with changes to the Scrum process, and you need to block non-Agile methods. Part of protecting the team is all about saying “no.”

Look back on all the previous tips to help combat this discomfort. Keep trusting yourself, Scrum practices, and the team to continue in the right direction: striving for high performance and delivering business value