“How does the PM role translate to Scrum?” is one of the more typical questions in my Scrum courses. Here’s the results of one such exercise that we did with the participants to find an answer. 

IMG_0602 2

As can be seen, a large chunk of typical project manager responsibilities become things Product Owners (green in the picture) are supposed to own, and another big chunk is for the Development Team (red). There’s a few splashes of blue (for ScrumMaster) and a sizeable number of items that Scrum is silent on (yellow). 

What is/was project manager anyways?

“Project” is an execution management structure. Projects are set up to deliver some target outcome, usually within specified timeline and budget. 

“Project manager” is thus a person who is supposed to manage the project. 

Since projects are about execution, the question of value is often secondary. Or if not secondary, but it’s typically given from the outside and assumed to be known (that is, that the person or board who granted the budget also evaluated the value and found it sufficiently high to warrant the budget). Therefore most of project management is about managing work and cost, because the improvement of value is usually not part of the assignment. Return-on-Investment (ROI) is optimised when the cost is minimized.

Project managers are also hubs of communication. Keeping track of information and status, using that to determine where the project is compared to expectations, and deciding on actions to possibly steer the project (and at least ensure that tasks are being worked on by the right people). Since the traditional project management is about task breakdown, definition and distribution, and then putting them together for releases, this kind of centralized coordination makes sense. Individual project members are experts in their own contribution and do not necessarily even understand all the elements of the big picture. Besides, communication is away from getting their own piece done.

What PO gets

Product Owner is a business role. A huge part of the role is the responsibility to understand what value means, and then communicating that to the Team through the Product Backlog, priorities, and milestones. They also get some responsibilities that relate to shorter term, but they often share them with the team.

As can be seen from the picture, the PO inherits all responsibilities regarding longer term progress and project purpose. PO is not a business analyst; the team can usually handle most of that, as long as they have clarity of what is the agreed scope of each selected story. 

“Project”, however, is a poor concept for PO’s in many cases. Even the role name says “product”, and implies that value is an integral part of the role. Unlike projects, products have a variable value element – it is no longer fixed. Increasing value and ROI during the project is one of the essential goals PO’s have when leading development. This is something most PM’s are not experienced in. 

So PO’s may have to be well versed in all kinds of things outside classical project management – sales, marketing, business management, product strategy, product innovation, customer development, etc. In some organisations, the reality of PO’s is quite far from that level of responsibility, so many PO’s can be effective without deep understanding in those areas.

It’s not surprising that many PO’s have titles like “product manager” and “service manager”, although “product owner” is becoming more common.

What Team gets

The Development Team is self-organizing, and that means that they adopt all responsibilities regarding the development of the product and the management of that work. This also includes all communication within the technical peers and other teams.

In many ways, the Team role is the most familiar for most organisations, but the challenge of self-organisation is, well, a challenge to most supposedly-self-organizing teams. Most teams struggle taking ownership of their own work management, and often benefit greatly from having a competent ScrumMaster or Agile coach working with them. 

What ScrumMaster gets

As seen in the diagram, the SM gets hardly anything. They do receive a supporting role in risk management, escalations and kick-off (according to the picture). Thus, the typical perception that PM’s become SM’s (or “Agile Project Managers”) is a bit unfortunate, since it does lead to quite a few negative behaviors. 

So most of the responsibilities of the ScrumMaster role come from outside the PM role. However, they often do spend significant time helping the PO and the Team learning their roles, so they do at least need to have an understanding of all the responsibilities and activities of those roles. 

All that said, there is one thing that unites the SM and the PM – they both deeply want the project (or product) to succeed. They just take a 180° difference stance on how to reach it. The traditional PM is expected to be right there in the middle and take ownership of taking the team to success. It is their hands that move. ScrumMaster instead sees that they have have find a way to get everyone else’s hands moving, and that in order to achieve that, they have to let go of direct personal responsibility. 

And the yellow stuff?

Scrum is silent on pretty much anything outside the immediate control framework, so it’s up to the users of Scrum to determine what they will do with those items. At least in consultancies, there are many things that just need to be done, and someone has to do them in order for the project to exist – contracts, invoicing, customer relationships, steering groups, reporting, etc. I call this set of activities the “project management service”. 

I’ve seen many solutions in organisations. Some teams actually have a project manager who does those things, but they let the PO, Team and SM take care of the content. In some teams, the ScrumMaster does those things, but they need to be careful not to become a PM in their relationship to the Team. Sometimes one of the team members, a senior probably, will take care of that “service”. Sometimes it’s someone outside the team, like an account manager. 

Whichever way it goes, it is important to recognize that a person doing those activities should not be granted formal authority over the team. They should see themselves an enabler and ally for the Scrum Team. They are managers of the things, not the people. And if they are granted organisational power over the Team, they must be very careful when to use it, in order to not break the self-organisation of the Team.