The first answer to that question is: Not the Scrum Master (as I wrote in The Scrum Master is not a Project Manager!).
Now that we got that out of the way, let’s acknowledge the fact that a LOT of people will scream now: “There is no project manager in Scrum!” – rightfully so. Because the Scrum Guide does not define a project manager. The word does not appear there.
But that doesn’t mean that the most common project management responsibilities just disappear in Scrum. They still exist – they are just not distributed to one single person who rules the project in a command-and-control manner.
Let’s dig a bit into the responsibilities that are traditionally assigned to a project manager. I would like to split these into two categories, which I will call, for a real lack of better terms, “environmental” and “internal” responsibilities. I am still looking for better words, but for now, these will have to do.
Environmental responsibilities: In this category, I place all tasks that are not directly related to enabling the value creation. These tasks can feed into the value creation activities or they can process their output, but they do not impact them directly. By this, I mean the project management tasks that relate to:
- Defining the scope of a project, the vision and the higher-level requirements as provided by the customers/stakeholders.
- Being aware of the project budget and how the value created by the Development Team relates to the budget.
- Evaluating the project’s business impact and viability.
- Prioritizing requirements for maximum business value.
- Discussing project progress and further plans with stakeholders and customers.
- Perform release planning to communicate planned release content to stakeholders and customers.
If you have the descriptions of the different Scrum roles in mind, it should be quite obvious where these responsibilities move to in Scrum: The Product Owner. So this answers the first half of the question. The Product Owner handles some of the traditional project management responsibilities. The Scrum Master assists with many of these tasks, but they are nonetheless the direct responsibility of the Product Owner.
The other side are the internal responsibilities: These are the tasks that directly enable value creation:
- Breaking down high-level requirements into detailed technical tasks and estimating the effort of all requirements and tasks in the project
- Planning the execution of the work
- Assignment of tasks to developers
- Monitoring the outcome and predicting the future progress
- Presenting work results to the customers/stakeholders.
Who handles these tasks in Scrum?
Yes, that might be a bit of a surprise to some people: These project management responsibilities are handled by the Development Team.
And that is the reason why so many people scream “There is no project manager in Scrum!” whenever that topic comes up – because the Development Team is self-organizing and the idea of a project manager seems to work against that. The developers in a Scrum Team do not have a manager. They manage themselves! But that statement actually leads to the more correct (and useful) answer:
The developers in the Development Team are the Scrum project managers!
I think this is a very very important revelation, because it explains a LOT about how Scrum is structured.
The great thing about Scrum is that it turns the developers into project managers without making them feel too much like project managers, because – let’s face it – most good developers do not want to be project managers. They want to create code. They want to be creative. They want to solve technical problems. They don’t want to deal with convoluted processes, management reporting, creating project plans, and so on. But Scrum takes the developers by the hand and surrounds them with a simple set of rules and constraints that automatically turns them into project managers.
And why? Simple: Because the developers are the best possible technical project managers for their area of work.
Like I said, this explains a lot about Scrum. Developers often ask why they have to attend daily standup meetings for example. Well, what do project managers do to get an idea of the project status? They ask the developers for a report. That is exactly what happens at the Daily Scrum: The developers report to the project management (= the developers).
I have heard many times that good project managers always have to challenge the estimates they are given by developers. So what happens during planning poker sessions? The developers come up with estimates and the project managers (= the developers) challenge the estimates. And in this case, the challenge comes from project managers who have a deep technical understanding of the product and the requirements. These are not project managers who challenge an estimate on principle, but project managers who do so because they have real technical objections.
So in my opinion, it is a big mistake to say that there are no project managers in Scrum. I think it is much more correct to say that the developers handle the project management (without forgetting the Product Owner’s important contribution from an environmental perspective, of course), because this motivates the way the Scrum ceremonies are structured. It answers a lot of the common “Why?” questions people ask about Scrum. And most of all, it reminds the developers of the great underlying respect and trust they are given when they are assigned to a Scrum Development Team.
AgileEvangelist 