Many companies have decided to keep the Project Manager role more or less intact while adding the new role of Scrum Master.
Is this good? Is this what the founders of Scrum intended?
In general I think the answer is no and I will elaborate a bit on why I think so. But first of all, let’s go back to the source. A lot of the discussions on this topic seems to come down to something like “Scrum is not mentioning the Project Manager – and we obviously need that role. So we just added the Scrum Master to what we had”. But I remember quite clearly that Jeff and Ken are saying that they named the Scrum Master role with a completely new name to make it very clear to everyone how different the role is from the traditional Project Manager role – not with the intention of keeping both roles! Some of the traditional Project Manager responsibilities goes to the Product Owner and a lot goes to the team. And some is scrapped. In this blog post, Agility and PMI, Ken says “In Scrum, we have removed the project manager”. Quite clear if you ask me.
Some of the reasons I think it can be challenging and bad to have both roles are:
- Overlap between the roles
- Conflict between the roles
- Communication and synchronization issues
Of course we can still have one person playing both roles in which case the above is not applying.
There must be some overlap when you have both a Project Manager and a Scrum Master. For example, if the project is risky (and they tend to be when we use Scrum) – who will facilitate a risk analysis workshop?
Some would answer that risk analysis is not mentioned in Scrum so either you don’t do it anymore – or it clearly goes to the Project Manager because they have that in their responsibilities and toolbox. Personally I think that Scrum is not telling you everything you need to know or do – it is just a very simple framework to help you get started. But if a risk analysis workshop is something that will be valuable for the team – then of course you can facilitate one as a Scrum Master.
If the Scrum Master and the Project Manager is not agreeing on something who will decide? If the answer is the Project Manager you can forget Scrum and ideas of a self-organizing team.
Unfortunately there often tends to be conflict in organizations that has chosen this path – since the Project Managers might still be stuck in a much more traditional view of projects.
Communication and synchronization
Even if we have a happy couple of Project Manager and Scrum Master who are working well together – they will still have an issue with lots of communication and synchronization to deal with. Which is always introducing a risk of misunderstandings.
One of the ideas behind lean, agile and Scrum is to reduce waste. To make as large part as possible of the work to be value adding. It is very hard to see how adding yet another role can help accomplishing this. Especially since a large part of the former work of Project Managers are taken over by the team, the Scrum Master or the Product Owner.
In many organizations the Project Manager position is a high status role for senior persons. Sometimes they add the Scrum Master role seen as a less senior position. The situation that arise when a senior Project Manager is appointing a Scrum Master to do the “dirty work” because he or she don’t want to lower their status can never be healthy.
Arguments for needing the Project Manager is commonly that the Project Manager has broader responsibilities than the Scrum Master. Let’s look at some of the more frequently mentioned additional responsibilities:
- High-level plans
- Hiring / firing
- Contracts and budgets
Ok, so we need to buy something within the project.
First of all – if the need to buy something is for the product – then the overall responsibility should go to the Product Manager if you ask me. Of course they will often delegate more technical stuff like for example a new server. But the purchasing decision should go to them. And they may well delegate the purchase to the team who can self-organize on who will do what part of the purchasing process.
If the purchase is needed for the project and not for the product the situation becomes more fuzzy. But in many cases the decision goes to a line manager.
A common argument is that the Scrum Master is only concerned with the current sprint (and possible preparing the next) so we need a Project Manager to look at the big picture.
I don’t agree with this, if there is a need to plan more than one sprint ahead of course we will do that. For example, if you have a release every three months and you need to have a good idea on what you will deliver the Scrum Master will facilitate release planning together with the team – in a very similar way to sprint planning.
Hiring / firing
I think (at least when it comes to Software development organizations in Sweden) it is rarely the case that the Project Manager role makes hiring / firing decisions. There is usually a line manager who has that responsibility.
So if this comes down to bringing on / off people on the team, the question is if a Scrum Master who knows the inside out of the current team with their strengths and weaknesses or a more outward facing Project Manager will be the best person to facilitate this?
Contracts and budget
Of course someone needs to work with this – and to make sure budgets are not overrun. But how we ideally want to form contracts and work with budgets are completely turned around from what traditional project managers are used to.
The handling of this in a traditional way is often a key reason why projects can not become agile – it was prohibited already when budget and contracting was made.
To sum this post up, I believe that in general it is better to stick with the intention of getting rid of Project Manager as a role (Project Manager can of course switch to being Scrum Masters instead). And expand the responsibilities of the Scrum Master (if it is necessary to having everything written down).
Things may occasionally make this complicated. For example it is much easier to do for internal development than for a company working with external customers.
This post is mainly considering the fairly simple set-up when there is only one team. In a large project with multiple teams the Scrum of Scrum Master will often not be able to be Scrum Master in any of the teams. Then that person’s responsibilities are closer to a part of what a traditional Project Manager does. In that setting it could make sense to call that role Project Manager.
Another option could be to only call things projects when there is value in following an Agile Project Control Model. And in that case we would have far fewer projects – and only when things are really tricky. Then we could have Project Mangers lead those initiatives – usually with the help of multiple Scrum Teams and Scrum Masters. But there might be a danger in having a role that has some kind of self-interest in making things more difficult and complex than they might be just to have work to do.