The traditional project approach has three core roles – the Customer, the Project Manager, and the Project Team. Similarly, Scrum has three roles – the Product Owner (PO), the Development Team, and the ScrumMaster.

It’s easy to see that the Customer and the Product Owner map rather nicely, since both have the money and the business need. Also the Project Team and the Development Team map nicely, since they are the people who have the skills to create the product needed by the business. 

The last one is a bit trickier. It’s easy to think that they map nicely, too. But they really map only in the goal of that role – both roles want the project to succeed. But other than that, they are the two opposite sides of the “project leadership coin”.

(and note, I’m taking a bit extreme look here, to properly highlight the essential differences of the two roles – see caveat at the end of the blog)

So the PM and the SM want the project to succeed. The traditional definition of the PM put the project manager in a very central position. They are like the spider holding all the strings, and monitoring everything, coordinating actions, keeping track of progress, and controlling the project variables in an effort to lead the project to desired outcomes, within specific boundaries. The Team is serving the PM and operates under their control, often feeling that they need to ask permission for everything. In this approach, also the Customer is constrained – their main control is the contract / plan made in the project. They do have ultimate power (because they control the money), but do not usually have engagement in the day-to-day activities.

Thus, we can say that the “project leadership space” is almost entirely controlled by the PM. This makes the role very powerful in a direct way. Good PM’s have a lot of experience in this kind of leadership, and often do have a huge contribution to the success of the project. That’s the attraction of the role – if you think you know what to do, you get to decide on doing it (instead someone else deciding things for you). 

ScrumMaster, on the other hand, takes a 180° different approach. They believe that the success is made by the Team and the PO, and that the best results are gained when those people play well together. Directly. They understand that if they act as a messenger between those people, the overall effectiveness will suffer. But of course, they also know that not anything goes, so they also know how to create effective teamwork and collaboration, so they promote those practices and facilitate effective organisation. 

Obviously, the PO and the Development Team must agree to play the game of Scrum, because it means they will have to pick up many of the traditional PM responsibilities. The PO must lead the product, prioritise the work, and manage longer term progress. The Development Team will have to self-organise and learn to lead themselves as a group, instead of waiting someone to provide them with instructions. These people must be competent enough to make good judgment calls, and willing to challenge themselves to learn new things. For a ScrumMaster, often the most difficult moments are those when the PO and Development Team struggle in taking sufficient ownership. 

To summarise,

Caveat: I know that many Project Managers act as something between classical PM role and SM role. They empower the team, and trust them to know what they are doing. These PM’s manage mainly just the overall picture, letting the experts in the Team shine and take ownership. These PM’s usually find it very natural to adopt the SM role in Scrum Teams. I consider these PM’s the best PM’s I’ve met (but I’m biased). To them, success is “we did it”.