Are Scrum Masters Overrated?

Are Scrum Masters Overrated?

G’day and welcome to Amazing Apps. I’m your host, Microsoft MVP, Neil Benson.

I’m on a mission to help you master agile practices and build amazing apps on the Microsoft Power Platform and Dynamics 365.

Amazing Apps is a result of my curiosity and experiments with new ways of building amazing business apps and high-performing teams.

It’s full of advice from my guests, and examples from some of my work over the last few years leading business applications teams and practices.

If you enjoy this episode, head over to amazingapps.show for additional resources. You’ll also find more episodes of Amazing Apps, as well as videos, free workshops, ebooks, and my online training courses.

It’s been a hot minute since the last Amazing Apps episode. Several months in fact. If you’ve been a subscriber waiting for something to drop, thanks for your patience. I’m still going. If you’re new here: Welcome!

I’ve planning to continue with the Amazing Apps show, but I’ll let you into a little secret. I’m launching another show very soon. If you want to find out all about it, heading to amazingapps.show and subscribe with your email address and you’ll be the first to know.

Two things happened in the past couple of months that prompted me to question some of my long held beliefs about scrum masters.

First: Agile coach and author, Maarten Dalmijn, published a thought-provoking article on his blog called ‘Are Scrum Masters Too Much Overhead?’

Second: Matthew, an amazing scrum master at my ISV business Superware, has stepped away on an extended leave of absence and instead of finding a new scrum master, the team decided to run an experiment instead. More about the results of that in a moment.

Back to Maarten’s article then. Ultimate Frisbee is a competitive team sport, and it doesn’t have any referees. I played a bit of Ultimate Frisbee at university, and I’ve been to the Ultimate Frisbee world championships. (But I have not played at the Ultimate Frisbee World Championships! Actually, I’m a rubbish frisbee player.)

I can’t think of another professional sport that doesn’t have a referee or umpire or an official to enforce the rules. Perhaps the closest is golf, since most golf games are played without one, but professional games will usually have qualified referees on the course.

When I asked my scrum team, Michael our product owner, a retired ten pin bowler claims that ten pin bowling doesn’t have a referee. But Michael, is ten pin bowling really a professional sport?

In Ultimate Frisbee every player is empowered to hold every other player accountable to the rules. In effect, every player is a referee.

Maarten’s article puts forward his point of view that scrum teams, like Ultimate Frisbee teams, can play without a separate scrum master (or referee). Especially, in start-up and scale-up organisations where there are usually fewer organisation impediments that get in the way of delivering value.

Maarten likes scrum to be in the background. Meaning he wants it to be a platform which provide a few rules on top of which teams build their own rules and hold themselves accountable.

But, he argues, having a separate scrum master brings scrum to the foreground, because that’s the scrum masters job! He wants Scrum to simply be a way of working while we create valuable products, not a goal we aim for in itself.

Every frisbee player knows the rules of Ultimate Frisbee. That’s why they don’t need a referee.

If everyone in the scrum team intimately understands scrum, would the team need a scrum master?

Maarten argues they would not.

But in many scrum teams, especially in our Power Platform and Dynamics 365 projects, there are lots of people who don’t know scrum. They’re developers who never used scrum or received any training, or they are our customers’ product owners and subject matter experts who’ve never been involved in any software development team let alone a scrum team before. And we’re often working in large, complex organisations where there are lots of impediments to resolve to maximise the team’s value delivery.

I found Maarten’s article challenged my thinking, but ultimately I think a lot of our business apps projects benefit from having a scrum master.

Back to our latest scrum master experiment in one of my scrum teams. Our scrum master, Matthew, has stepped out of the role. Most of the team has been working together for nearly seven years and over two years with this customer. It’s fair to say that they know the rules of the game. Although, there are always folks in our team and on the customer’s side that are new to scrum.

The team decided to run an experiment. Instead of recruiting a new dedicated scrum master, one of the developers has stepped into the scrum master accountability and we hired another developer.

Sapan, our scrum master/developer has been working with Dynamics since 2006 and with Scrum since 2018, maybe even earlier. And he’s also Superware’s COO responsible for the successful delivery of all our projects. There isn’t anyone better in our business to take on the scrum master role while still contributing to the team’s velocity as a developer.

We probably wouldn’t try this experiment with all our teams, especially when working with a new customer or a customer new to scrum.

But so far it’s working really well. We discussed it in the sprint review today after running this team configuration for a couple of sprints now.

Sapan doesn’t include his capacity in the team’s forecast when we’re planning our sprint. Any items he works on are considered a velocity bonus because his first priority to the team and to the customer is as a scrum master, not a developer.

We’ve been able to hire an early career Power Platform maker into the team as a new functional consultant. After a couple of sprints, she’s now up to speed and picking up and completing sprint backlog items and contributing to the team’s velocity.

Overall, by replacing the dedicated scrum master with a hybrid scrum master/developer and adding another developer, the team’s velocity has proved to remain steady and we expect it to creep up a little over time, and the customer’s project manager is satisfied with the support she’s getting from Sapan as scrum master so is our product owner.

I don’t recommend combining the scrum master and developer roles for most scrum teams though.

It’s working for this Superware team. Perhaps it’s because most of the developers in the team have many years’ experience working together as a scrum team. Perhaps it’s because the customer’s product owner has stepped into his role very comfortably. Perhaps it’s because our team is not charged with transforming the entire organisation to an agile way of working. Or perhaps it’s because the customer’s organisation isn’t completely dysfunctional.

If those conditions exist for your team, I’d encourage you to try it. Always be willing to experiment with new practices. That’s what Scrum is all about. I know Maarten Dalmijn will agree with me on that.

Thanks for listening. I hope you enjoyed this episode of Amazing Apps and found it useful.

If you did, please join our Amazing Apps group on LinkedIn where you’ll be able to leave comments about the episode, ask questions about using agile practices to build amazing apps, and find out about our live events. If your team is running with a scrum master-develop combo or has tried it, please join the group and leave a comment under this episode.

Until next time, keep experimenting.

-Neil