Scrum Master In Name Only

What’s in a name?

What if that name is a title?

Names and especially titles, can mean different things to different people based on

• what they believe,
• what they’ve learned by hearing or seeing or reading, and
• what they’ve experienced.

Any one of these used in isolation to interpret a title may lead to an incomplete or worse yet, an incomplete interpretation with unintended consequences.

Scrum is a clearly defined and relatively lightweight agile framework developed and periodically updated based on a litany of empirical evidence. It describes the Scrum roles, events, and artifacts. As soon as you start messing with the framework, you’re no longer using Scrum as defined in the 13-page Scrum Guide. That’s not a criticism of what you are using or that it’s not effective for you. It’s just not Scrum as it was intended to be used.

In a recent coaching session with an aspiring Scrum Master, he lamented that 70% of his time was spent on 2 tasks:

1. Creating and updating work item tickets for the team
2. Scheduling meetings

That’s about 3.5 days per week doing solitary administrative tasks!

He said he felt like a secretary! Not that there’s anything wrong with that. Problem was he wasn’t hired to be a secretary. Little wonder he wasn’t developing as a Scrum Master.

The story gets worse. When he first joined as a newly minted Scrum Master, he sought the guidance of a more experienced Scrum Master and was led to believe those 2 tasks were what Scrum Masters typically do as part of their job. What started as an isolated case of role clarity looked like it was becoming a systemic affront to effective Scrum Mastery in this organization.

In both his mind and the team’s mind, they felt he was helping the team. He wasn’t. He was hurting both them and himself. Here are 2 reasons why.

1. He was neglecting his Scrum Master role.
2. The developers on the Scrum Team were developing bad habits.

The Scrum Master Role

What does a Scrum Master actually do? Are they like a Project Manager? These are the most common questions I hear in organizations adopting the Scrum framework. To begin with, the Scrum Master is not a Project Manager. They may have had experience working as a Project Manager and some of the those skills and experiences may help them as a Scrum Master but, there is no Project Manager role in Scrum. The Scrum Master role as defined in the Scrum Guide involves providing service at 3 levels.

1. Service to the team. The Scrum Master’s ultimate responsibility is facilitating the growth of the team into a high performing team. Including coaching the team members in self-management and cross-functionality
2. Service to the Product Owner. To provide counsel to the Product Owner on how to best engage with the team. Including helping find techniques for effective Product Goal definition and Product Backlog management;
3. Service to the Organization. To provide counsel and education to the Organization on how to work effectively with the Scrum framework. Including leading, training, and coaching the organization in its Scrum adoption.

The role of Scrum Master is a full time role, especially for teams new to Scrum.

So, with 70% of his time spent on purely administrative tasks, how effective would he be in carrying out his true role as a Scrum Master in the remaining 30% or 1.5 days per week?

What would be the chances of him developing into a formidable Scrum Master?

What would be the chances of him choosing to stay in the Scrum Master role?

Developers’ Habits

Being a member of a high performing team is like being in a happy marriage. You’re in it for better or worse. Working together on whatever comes their way to strengthen the bond between them. The developers on a Scrum Team as defined in the Scrum Guide are always accountable for the following.

1. Creating a plan for the Sprint, the Sprint Backlog;
2. Instilling quality by adhering to a Definition of Done;
3. Adapting their plan each day toward the Sprint Goal; and,
4. Holding each other accountable as professionals.

By essentially taking on all of the team’s administrative tasks, he was allowing the team to develop bad habits. Habits that enabled and amplified their helplessness when it came to collective ownership and accountability for all aspects of the work no matter how mundane the tasks. Creating a plan for the Sprint should include creating the necessary work item tickets. It’s the last mile of being a true professional.

I’m not suggesting we should apply the Scrum Guide dogmatically without any consideration for context and flexibility.

Like the Agile Manifesto itself, the actual roles of Scrum Master and Scrum Team will always be applied with a liberal splash of personal and cultural panache unique to the people playing those roles.

What I am suggesting is that trying to be successful as a new Scrum Master spending only 30% of time in the role will be a non-starter for both the Scrum Master and the Scrum team.

So, what could the Scrum Master do to get himself and the team back on track using Scrum effectively?

• Just say no. Whoever will be doing the work is best positioned to describe what is to be done in a ticket. Asking someone else to do it takes more time, invites confusion and demonstrates a lack of full ownership for the work.
• Schedule meetings if you will be facilitating. Stop scheduling meetings that you will not be facilitating and especially those you aren’t even participating in. In those cases, again just say no.

Like tough love, by saying no, you’ll be actually helping them and yourself in the long run. No more lamentations!