Scrum Master or Agile Project Manager?

Why have a scrum master when you could have an agile project manager instead?

Welcome to the Amazing Apps Show podcast for Microsoft business application creators who want to build amazing business applications that everyone will love.

Hi, I'm your host, Neil Benson. My goal on this podcast is to help you slash your project budgets, reduce your delivery timelines, mitigate technical risks, and create amazing, agile Microsoft Dynamics 365 and Power Platform applications.

Just before we get started with the show, I wanted to give a quick shout out to Phil Ellingham. Phil is a Dynamics and Power BI [00:01:00] consultant at the S.R. Group in the U.K. Phil recently completed my Scrum for Microsoft business applications course and went on to achieve his Professional Scrum Master certification. Well done, Phil.

The question in this episode comes from Carolle. Carolle Bruce is the director of Information Technology and AVCorp Industries in Vancouver. Alexa, please read Carolle's question.

"What's the best argument for when senior management says, 'All of this agile stuff is great, but I don't see why you'd have a scrum master on your project when you could have an agile PM instead.'?"

Thanks for your question, Carolle, and thanks for reading it, Alexa.

The role of the scrum master in the scrum team is often misunderstood, especially by managers who think it's just a project manager role with a funky title.

In an agile project, when your team has adopted the Scrum framework, there is no project manager.

In a waterfall project, a project manager [00:02:00] is responsible for the success of the project by controlling and directing the resources and ensuring the project produces the required deliverables within the agreed timescales and budget. That's my own definition because when I visited the Project Management Institute to find their definition, I couldn't find one. They have a great definition for 'What is a project?', and then they seem to define a project manager as someone who does all that project stuff. But I couldn't find their definition of a project manager.

The PMI defines five phases of a project: initiating, planning, executing, monitoring and closing. And 10 knowledge areas: integration, scope, time, cost, quality, human resources, communication, risk procurement and stakeholder management. Unfortunately, they don't mention inspection or adaptation. There doesn't seem to be any room for empiricism in a traditional project and few, [00:03:00] if any, opportunities for learning and adjusting your plan based on what you learn through the course of your project. Principally because in a traditional project, there are no results until the very end of the project.

The role in a Scrum team that's closest to the role of a project manager is not scrum master, but actually the product owner. The product owner is responsible for maximising the value of the application that the development team is building. She does this by providing a clear vision, working with her stakeholders to understand their requirements, prioritising those requirements in a product backlog and working closely with the development team to turn some of those requirements into features in each increment.

The product owner engages the stakeholders and is, herself, usually a stakeholder. She controls the scope not through Gantt charts and work breakdown structures, but by prioritising the product backlog. She's [00:04:00] responsible for the cost of building the application, which is usually easier than in a traditional project.

Because we've got a fairly constant burn rate for the internal recharges or the external consulting fees of the development team. There's a working version of the application available in production much earlier than in a traditional project. Sometimes there's a basic version with a few features deployed after a couple of sprints. This makes it easier to manage costs than a traditional project where nothing gets deployed to production until near the end of the project. That's because in a Scrum project if your budget is drying up and you need to close the project earlier than expected, you'll still have a working application with the most valuable features available in production. If your budget dries up in a waterfall project and you have to close the project early or you'll be left with is a bunch of documents and half-built features that haven't been tested yet.

The product owner manages the risks [00:05:00] and, with the help of a development team and stakeholders, manages those risks to minimise their impact on the application. The development team within the Scrum team is self-organising, which means they don't rely on a project manager to assign them work or report their progress to stakeholders. They can do that themselves. Imagine that! Placing so much trust in highly paid professionals that you don't need to micromanage them. Instead, give them the freedom and autonomy to figure out how best and who best to do the work, hold them accountable for the quality of the work and inspect it with them every week or two.

Finally coming around to the Scrum master, what are the similarities and differences between scrum master and project managers?

Let's get this out of the way first, I'm not a big fan of the label 'scrum master'. There's been a fair bit of debate within the Scrum community about this phrase. And it seems like Jeff Sutherland [00:06:00] and Ken Schwaber, who publish the Scrum guide, aren't going to change it. On the one hand, scrum master sounds like a guru, one of the best in the world. Like a chess grandmaster who has achieved a level of enlightenment that few others will achieve.

This is obviously not the reality. There are thousands of people out there who are first-time Scrum masters, and those of us who are still learning and growing in our craft. Scrum master sounds like a pinnacle that's been reached when in fact it's a journey that we're all on.

A 'master' also implies ownership. As if the scrum master is the boss of the team and they are there to serve him. In fact, it's the opposite. In Scrum great scrum masters help their teams improve their performance by serving them, not by being served.

And to me, that's the biggest difference between a project manager and a scrum master.

A project manager plans, controls, manages, assigns, executes, directs, performs, validates [00:07:00] and monitors. (That's according to the Project Management Institute.)

On the other hand, a scrum master serves, coaches, guides, assists, trains, leads, exemplifies and uncovers.

It's not just about the responsibilities of the project manager and scrum master that are different, but it's their entire philosophies. Whether you call it a scrum master, agile project manager, an agile coach, a delivery lead or some other title, as long as the person in the rule applies the philosophy of scrum mastery, of servant-leadership, and the values of agility, then I think you can be successful with Scrum.

I hope that helps, Carolle.

If you're interested in adopting an agile approach to building Microsoft business applications and would like to learn the basics and benefits, I have a free course, Agile Foundations for Microsoft Business Apps that you can complete in about an hour. It's got five [00:08:00] videos and quizzes and lots of Lego figures. You'll love it. You can join for free at customery.com/foundations.

You'll find show notes for this episode and a transcript at customery.com/013.

And if you have a question about building agile business applications, you can send me a voicemail by visiting customery.com and clicking on the 'Send Voicemail' button. Leave your name, where you live and work, and your question in the message and maybe you'll appear on a future episode of the show.

Thanks for joining me in this episode. I really appreciate you. Until next time, keep sprinting.