Are project managers useful in Scrum?

Question

There are three roles defined in Scrum: Team, Product Owner and Scrum Master. There is no project manager, instead the project manager job is spread across the three roles.

For instance:

• The Scrum Master: Responsible for the process. Removes impediments.
• The Product Owner: Manages and prioritizes the list of work to be done to maximize ROI. Represents all interested parties (customers, stakeholders).
• The Team: Self manage its work by estimating and distributing it among themselves. Responsible for meeting their own commitments.

So in Scrum, there is no longer a single person responsible for project success. There is no command-and-control structure in place. That seems to baffle a lot of people, specifically those not used to agile methods, and of course, PM's.

I'm really interested in this and what your experiences are, as I think this is one of the things that can make or break a Scrum implementation.

Do you agree with Scrum that a project manager is not needed? Do you think such a role is still required? Why?

Answer 1

Maybe you should present things like this:

The project manager did not disappear in Scrum. He is still there. There is three of them now!

• The Scrum Master: he manages the process and solve impediments. That was the responsibility of the project manager before.

• The Product Owner: he manages the backlog. That was the responsibility of the project manager before when he predicted everything in Microsoft Project.

• The Team: self manage its production. Who and how a given user story is converted into a potentially releasable product increment. That was the responsibility of the project manager when he assigned tasks.

Answer 2

For me this comes from a lack of understanding of what a Project Manager does and the rather generic nature of the PM title. I'm not an expert on SCRUM but I've always seen the SCRUM Master as replacing the development manager / team leader rather than the Project Manager.

Project Managers (as defined by methodologies such as PRINCE2 - which is pretty much compatible with Agile methodologies) really aren't anything to do with the development process, they're looking after the project from a broader delivery perspective covering more than just the IT build. There are lots of things that sit within the Project Manager role that aren't covered elsewhere within Scrum (managing and monitoring the business case, managing the business stakeholders, elements of the project outside of the IT build such as reworking business processes, support, training and so on).

If your PM is the guy who looks after the developers and doesn't do much more than that (for instance on projects which are largely IT only where the scope is pretty well defined) then it may well be that he's not going to be needed on a SCRUM project.

But before someone says you don't need a PM for SCRUM, I'd want a pretty clear explanation of how the non-IT elements of the project are being covered and in particular who is managing the business case (because the users wanting it and it being something that should be done are different things).

It may be that the PM ends up sitting more on the business side of the project - the Product Owner may well take on more of the PM's role than the Scrum Master but I think it's unlikely that he'll be gone entirely.

Answer 3

There are a few things that a Project Manager can do that a Scrum Master or Product Owner might not be able to.

• Project Managers usually have extensive experience in running projects (surprise!).
• They are aware of common pitfalls, and can spot them and help head them off before they happen.
• They are usually experienced negotiators, and can support other team members in discussions around deadlines, scope and conflicting requirements (very important if the PO is fairly new in the role).
• They can manage the money. They have the power to hire and fire, and can help if someone on the team is incapable of performing in their role (through arranging training, counselling out, etc).
• They can help ensure that the project fits effectively into a larger programme of work.
• They can get stuff out of the team's way.
• They can help guide company policies to be effective alongside Scrum (for instance, if testers are still being measured by the number of bugs found).
• They can manage governance.
• They can move the furniture.
• Their vocabulary is that of the larger enterprise, and they can discuss the project - and the Scrum approach - in terms of risk, impact, ROI, options and differentiation.
• They can explain to the board why the sudden transparency and occasional news of failure, coming through a sea of green reports, is good and useful to know.
• A good PM can help you feel safe, sound cool and look great.

Scrum doesn't mandate having a PM. But you might want to have one anyway.

Answer 4

In one of the projects I worked, when it turned into Scrum, our earlier project manager alternatively took the roles of Product Owner and Scrum Master. It sort of worked for the 6 months I spent with that team, although it was not ideal (for me). He was the kind of guy who wanted to keep things under tight control, but did it fairly well (i.e. letting the team do its job and make its decisions when it was appropriate).

The background of this was that the company was in a dire financial situation, although we (the team) got to know about it only some time later. So there was a reason to keep everything under tight control, to ensure that only the absolutely necessary stuff is being built, and the first version of the product is delivered on time.

Answer 5

I'd be fair and say that in my view what works for me is the Scrum master acting as the Project manager as well. Being a Scrum master isnt a full time job - once the team is mature the scrum master doesnt even need to attend the daily stand ups.
There are more and more vacancies that I see for a Project Manager/ Scrum Master where companies do not want to differentiate these roles - rather have the same person handle both roles - ie: an Agile project manager.

Answer 6

Project manager: a role within a traditional organization or enterprise.

Scrum master: a role within a software development team using the Scrum methodology.

Talking about project manager vs. scrum master is really talking about apples and oranges because the roles have different contexts. I've never heard of an organization that has "Scrum master" as an official title or pay grade. And project managers on any project, Scrum or otherwise, are often somewhat removed from day-to-day software development activities.

Exactly what a project manager does and how much his/her role overlaps with that of a Scrum master or project owner depends heavily on the size and nature of the project, but there are certainly tasks normally attributed to a project manager that aren't specifically part of the Scrum master or project owner roles. On a small project it may be possible to expand the duties of the Scrum master or project owner roles to include those tasks (hiring, firing, purchasing, contract management, interfacing with higher-level executives, etc.). On a larger project, software development is just one part of project management, and the duties of the project manager and those of the Scrum master are unlikely to overlap much at all.

A project manager should be the Scrum master's interface to the organization. The Scrum master should be the project manager's interface to the team.

So, are project managers useful in Scrum? No, project managers are useful outside Scrum. They're not part of the Scrum software development methodology, but they provide the resources that allow Scrum to work.

Answer 7

This question smells of Scrumbut.

Scrum is a subset of what is contained in a project management method (Prince2/PMP etc). In fact, if you look at the Prince2 process MP (managing product delivery), all the elements of Scrum can be contained there.

The Scrum Master does not want to get bogged down in meetings with vendors, personnel, legal, finance, suppliers, executives or BAU activity. They need to concentrate on removing impediments from the team on the current sprint, not negotiating how much an employment agency can cream off contractor rates in FY2011/12 or validating the escrow agreement with vendor x.

If your Scrum Master is doing the above, you are not running Scrum, you are running Scrumbut.

From experience the best combination is to have a Scrum Master for each team-lead and a project manager to coordinate the scrum masters in a Scrum of scrums fashion. Having a project manager in this role more effective due to reasons given above and their depth of experience. In turn, these project managers report into a Portfolio/Program Manager etc and all in the chain of command are at least certified Scrum Masters.

Remember that Scrum is a tool for managing product delivery, at a layer of abstraction it can be used to run projects, but there are already far better processes out there for that.

Answer 8

One of the main problems with the traditional project manager role is that it separates authority from responsibility. The PM has complete authority over the project organization - (s)he decides what tasks need to be done, by whom, in what order, etc. But (s)he's not held accountable for the completion of these tasks or the quality of software that is produced. The team members are the only ones responsible. This creates a huge communication overhead, as to put back authority and decision in sync with operational work, team members constantly have to report everything that is done to the PM in addition to the rest of the team. It also creates a feeling of dispossession, powerlessness and a loss of purpose with the team members, which is a large source of frustration and discouragement.

Agile somehow puts these notions back together - the authority over work organization is held by the team as a whole (through release, iteration and daily meetings) so that everyone feels like they can have a say in the matter, in return of which each of the team members has to take responsibility for producing quality software that works and make a strong commitment towards that goal. You could thus theoretically get rid of the project manager.

Once you've said that, there are still duties traditionally assigned to the PM which still need to be taken care of though - lunivore described them quite accurately.

As this article suggests, in truly multi-skilled teams, one thing you could do is discard the project manager role, redistribute its duties among the team members and have former PMs become regular team members.

Answer 9

The Scrum roles are quite well defined (if they seem vague it is because they are meant to be applicable in different types of organizations), and since Scrum teams are always (well, commonly) of about the same size - i.e. not very big - it is relatively easy to agree on what they encompass, even if that varies depending on the underlying organization.

Reading the question, answers and comments above, it seems obvious that the definition of the project manager role is much more difficult to nail down. I am sure that you can find a nice and compendious general definition of a PM's role, but what that actually means in real life is a totally different story.

Anyway, as it works at my job, the project managers are very seldom involved with the actual "Scrumming". They are not allowed to be Scrum masters (a local conflict-of-interest rule that we all are quite happy about), and they are only product owners in exceptional cases.

So where I work, the project managers are still there, doing pretty much what they always have done. Meaning that they keep the project on track, act as a filter against too much paranoia and micro-management tendencies from "above", solving problems that need a more clout than we posses to solve, and so on.

I'm sure that this is quite different at other places, but for us it works great.

Edit: Maybe I should clarify that for us, a Scrum team does not replace a project team. One or more Scrum teams are started to perform the actual development work for (and usually in) a project. The Scrum team(s) can (and probably always do) consist of the old team members, except for the project leader :-)