Lately I've seen SCRUM implementations where a project has a Project Manager, a Product Owner and a SCRUM team. In my opinion, SCRUM should never have a Project Manager. The role does not fit in the architecture of a SCRUM process. Not only because SCRUM is unsuitable for projects (SCRUM does not recognise projects, only products that are in a state of perpetual change) but also because all tasks attributed to the role are assigned already within SCRUM. The Queensland University of Technology states that the responsibilities of the Project Manager are:
- Manage the project taking into account integration across all areas.
- Engage with stakeholders.
- Develop Project Plan.
- Direct project resources.
- Monitor and manage the project schedule.
- Monitor and manage the project budget.
- Monitor and manage the project risk.
- Deal with operational issues.
- Organise steering committee meetings, including ensuring that minutes will be taken.
- Report to the steering committee, raising strategic issues.
- Prepare Project Status Reports and Project Change Requests for the steering committee.
- Ensure project meets requirements and objectives .
- Manage project team members.
- Negotiate and resolve issues as they arise across areas of the project and where they impact on other activities, systems and projects.
- Look after the interests of the project team.
- Organise and chair project reference group meetings, as appropriate.
- Communicate project status to project sponsor, all team members, and other relevant stakeholders and involved parties .
- Maintain project documentation.
If we start by eliminating the points that don't apply to SCRUM:
@4: "Project Resources" (or as we call them: People) will direct themselves. The concept of a manager telling people how to do things is outdated.
@9: Since there's no use for a steering committee, there's no use for steering committee meetings.
@10: Since there's no use for a steering committee, there's no use for steering committee reports.
@11: Since there's no use for a steering committee, they do not get a say in change requests.
@13: Team members do not need to be managed. They need to be supported. The concept of a manager telling people how to do things is outdated.
Now that we've got those three out of the way, lets look at SCRUM:
- The burndown charts (both sprint and product) can be used as reporting tools. Combined with the end-of-sprint demo this covers the "status reports" part of #11 as well as #17
- If used correctly, the Definition of Done will cover #8. The Definition of Done doesn't apply just to each backlog item, it applies to the product as a whole.
- Since we use a minimal approach to documentation, either the charts, demo and code will cover it all, or it becomes part of the Definition of Done making it a team responsibility.
Product Owner responsibilities:
- Produce the Product Backlog. This is actually a lot more elaborate than it may seem. Since a product backlog contains all information from the stakeholders, this covers #1, #2, #7, #12, #16
- Using the team velocity and the information in the Product Backlog to do release planning covers #3, #5, #6
SCRUM Master responsibilities:
- Eliminate impediments. This covers #14, #15
As you can see, all responsibilities of the "classical" Project Manager are covered in the roles, products and ceremonies of SCRUM. If we look at the way they are covered, the main items (Stakeholder management and planning) are covered by the Product Owner. I'm not saying that a Project Manager can be a product owner (since the Product Owner's main task: Product Vision isn't a classical Project Manager task) but if we look at a product using SCRUM and we want to know something we'd normally ask of the Project Manager, my advise would be to go talk to the Product Owner.