The Value of a Scrum Master

Have you ever wondered what value a Scrum Master may bring to your product, team, or organization? Or maybe your client has asked you why they should pay for a person who does not write any single line of code? We have already gone through that journey. Keep reading…

Prologue

A few months ago I joined a project for one of our clients. Before that, a discussion about hiring a Scrum Master had been going on for quite a long time. The client had not been able to understand what value this role might bring to the project. And it is not very surprising, as a role of a Scrum Master is very often misunderstood and undervalued.

Somehow my company managed to convince the client for a three months experiment to prove a Scrum Master is a valuable member of the organization. However the client insisted on providing metrics to see the value. The metrics included:

• A list of impediments that affected effectiveness of the teams.
• Net Promoter Score to measure dev teams’, product owners’ and stakeholders’ satisfaction at start of the experiment and after 3 months.
• A feedback from people who worked with SM on how such a support affected their work including client’s product owners and our dev teams.

Based on metrics, the client wanted to make a decision about extension of my contract.

Now deal with it

When I joined the project I spent two weeks mostly looking at how people around were working. I also spent some time talking to people about their pain points.

The biggest client’s concern was that they were not able to plan product development as the teams were not predictable. Frequently they did not use to deliver what they planned. On the other hand, dev teams complained about their size, they were too big to communicate effectively, plan work precisely and collaborate easily when doing their work. As a result, the teams’ morale was low.

In the meantime I also observed:

• Requirements and priorities coming in from many different people.
• Product owner having no time for the dev team.
• Scrum events moved freely from one day to another.
• Sprint ending on Wednesdays and planning next sprint taking place on Fridays.
• User stories refined during the sprint planning.
• Teams not defining sprint goals.
• Product owner not being a part of a team.
• Dev teams not reflecting on how their progress during the sprint.
• Product owner working with multiple teams.

While walking around I measured how people were satisfied with their work, being a member of the project or a team. I asked them how likely they would recommend working for the project to their colleagues. This was the base line for me.

Based on the observations listed above we did the following actions:

• We divided dev teams into smaller units.
• We asked the client to provide a single product owner for each team.
• Teams agreed on their event’s schedules.
• Product owners and dev teams started crafting sprint goals.
• Dev teams started to inspect the work towards the goals during the sprint.

It all sounds easy but in fact bringing a new structure required a lot of work, multiple sessions in small or big groups to discuss and agree on details. Many people, many points of view. But definitely focusing on real pain points helped us a lot. We focused on impediments distracting people from doing their work effectively.

So what? Tell me more about the value.

All teams worked in a new setup for a month and a half now. I was very curious how the changes impacted team’s results. Did they become more predictable so our client could plan their product development more precisely? Were teams happier? How did I help them to do their work better?

To measure predictability I dove a bit to data gathered by our work tracking system. I just compared a number of delivered story points with a number of planned story points during one month and a half before and after the changes were introduced. Taking this data it occurred the predictability has increased by 31%. On average, new teams were able to deliver almost everything they planned at the beginning of a sprint. I was a bit suspicious and wanted to check if the teams just started pulling less work into their sprints. It was a great surprise when I found average velocity of the teams has increased by 7%.

Did it make people happier? When I asked teams about their Net Promoter Score I noticed it had raised by 24%!

So, taking all the facts described above into consideration, I can say that smaller development teams with a dedicated product owner and better organized workflow are faster, more predictable and happier.

Teams also mentioned that a Scrum Master helped them to:

• Address cross team issues & understand where problems are.
• Organize work better so they don’t have so many meetings and can focus more on product development.
• Discuss issues before making decisions or taking action steps.

Epilogue

I have achieved the goal. We have managed to show to the client a Scrum Master brings a value to the team.

For me it was a pleasure as all changes introduced during the experiment where identified together with teams during loud discussions.

As Winston Churchill said once: „Now this is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning”. It is time to introduce other improvements to bring more value to the client. Stay tuned!