This post has been written as documentation for the Agile Ottawa Meetup 101 session held on October 8, 2013.

The Scrum Framework

In order to dig further into our Scrum Master role, let’s get a short reminder of Scrum. Scrum is an iterative framework that has a fixed period called Sprint which is shorter than 30 days. At the beginning of the Sprint, the team plans their Sprint so they can get to a Common Goal. Every day, the Dev Team meets for maximum 15 minutes to plan their day. At the end of the Sprint, they hold a Sprint Review, a Retrospective, and a cycle back to the Sprint Planning. The iteration delivers a potentially shippable product to the client. There is a Product Owner, a Scrum Master, and a Dev Team; a total of 5-10 members. Scrum also holds some artifacts: The Product Backlog; The Scrum Backlog; The Product Increment.

Scrum – The Framework

That’s all we have to know, for now.

Like his name strongly suggest, the Scrum Master owns the framework of Scrum. He makes sure everyone in the team, and beyond, respects the framework and its values. Here are 5 things a Scrum Master is:

Different Stances of the Scrum Master

Shield

The Scrum Master is a shield to the team. Just like Captain America who jumps around to protect his team members from incoming threats. The Scrum Master also has to be prompt and quick to intercept external or internal sources of distraction. It is important to clarify the focus of the Sprint and to set the expectations when those distractions arise.

Sensor

It is an art to intercept those distractions in a timely fashion. This is why the Scrum Master has to be like a sensor. He has to feel, listen, look, and observe. Although we could identify some categories of distractions and how to tackle them individually, it is an art to properly intercept them and to re-enforce the Sprint Goals while promoting the Agile values.

Ambassador

The Scrum Master is an Agile Ambassador, promoting the values, ideas, and sharing the knowledge that relates to Scrum and Agile. He has to identify when to teach or when to mentor team members and move obstacles away from them.

Bulldozer

While the team is working through the different challenges of implementing the sprint goals, they have the help of the Scrum Master to remove their obstacles and blockages. That way, they can produce the product increment at a constant pace. It can be as simple as pointing out the Big Pink Elephant in the room. Identifying the impediments is the first and perhaps hardest step to improvement. The Scrum Master has a different perspective than the Developers and it is, therefore, easier to identify the impediments.

Facilitator

He is asked to facilitate when needed. The Scrum Master needs to develop the skillset of getting all voices and promote consensus decision making. The Scrum Master will work closely with the P.O. to make sure the Product Backlog is transparent, meaningful, ordered, and estimated. He also ensures everything is visible to the team, so they can have a clear view of what’s next. The Scrum Master also facilitate the values and mindset throughout the organization, outside of the team.

Enabler

Once the impediments are removed and the team is properly shielded and empowered, the quality of their work would increase and their estimates may become more accurate. At one point, the rhythm of Scrum should provide the foundation for the Team to continuously learn and grow. Developers and P.O. can seek new knowledge, techniques, and technologies to become faster, better, and smarter. Now that their environment is safe to learn, do mistakes, adjust, anything is possible. Try a “lunch and learn”, “group katas” or other games to promote learning, and continuous improvements.

What Scrum Master doesn’t do

Does not give orders, or Assign tasks

The Scrum Master has no power, he owns the framework of Scrum and that is all. Therefore, the only decisions he can make are in relation to the framework. He cannot assign any tasks or dictate anything to the team. He cannot ask them to work in pairs or to use a specific tool. He is not a Product Owner assistant or a scribe during meetings.

Holding multiple hats is risky

The Scrum Master should not code. Or at least, he should not impact the Sprint, either by distracting the developers or by coding half of a task. He cannot commit to Coding because he is already committed to helping the team in all the other areas of the framework of Scrum.

What is the impact of sharing two roles? Once you get in the “Zone” of coding, you lose the right perspective. You will lose your sensitivity and your sensor will malfunction. You won’t be able to jump around and redirect distractions. You may even become a distraction to the team.

The impediments won’t be identified or solved. The meetings won’t be as productive and no one will know why. Frustration will grow and won’t be addressed. The overall production will decrease silently, along with the quality of the software.

For me, that sounds like a waste of effort and money.

There is no formal prescription on this. Holding multiple roles is risky as you will need to switch context. There is only one Scrum Master, who will look over this when you’re not?