Last week I was able to attend the excellent Thomson-Reuters/PMI Project Management “Unconference”, held at Exeter University. I also volunteered to host a couple of the bar-camp sessions, one on Coaching for PMs and the other Stakeholder Management.
The event offered plenty of opportunity for discussion during the breaks, and it struck me in particular how much Agile came up as a topic of debate. This was even more remarkable because it wasn’t particularly a subject on the agenda. Even in my bar-camp sessions if I spoke about coaching, I got asked about best practice as an Agile Coach. If I spoke about stakeholder management, I was asked about stakeholders in Agile projects. It is clearly a hot topic!
One thing that seems to be happening is that project managers are concerned about their role in the Agile world. Quite a few are going on Scrum Master training courses, and are confused because there is no explicit PM role in Scrum (which is, of course, just one flavour of Agile – but seems to be the one that most are going for).
Here are the three roles defined in Scrum (source: The Scrum Alliance):
- The product owner decides what will be built and in which order
- Defines the features of the product or desired outcomes of the project
- Chooses release date and content
- Ensures profitability (ROI)
- Prioritizes features/outcomes according to market value
- Adjusts features/outcomes and priority as needed
- Accepts or rejects work results
- Facilitates scrum planning ceremony
The ScrumMaster is a facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.
- Ensures that the team is fully functional and productive
- Enables close cooperation across all roles and functions
- Removes barriers
- Shields the team from external interferences
- Ensures that the process is followed, including issuing invitations to daily scrums, sprint reviews, and sprint planning
- Facilitates the daily scrums
- Is cross-functional
- Is right-sized (the ideal size is seven — plus/minus two — members)
- Selects the sprint goal and specifies work results
- Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal
- Organizes itself and its work
- Demos work results to the product owner and any other interested parties.
So where has the PM gone? The answer, of course, is that the responsibilities have been redistributed.
If we start from The Seven Essentials being the basis of project management, how do these map onto the Scrum roles?
- Benefits – clearly the responsibility of the Product Owner
- Scope and Quality – also Product Owner, since they define the features, and accept or reject
- Stakeholders and Communications – not really mentioned, but external communications (to senior stakeholders) will also be handled by the Product Owner
- Plan – This one is split. Scrum Planning (i.e. high-level planning) is facilitated by the Product Owner. The Team organises its own work (detailed planning).
- Team – Scrum Master looks after the team.
- Suppliers – Not explicitly mentioned, but both the Product Owner and the Scrum Master have a role here. The Scrum Master in particular has a responsibility to remove barriers, which could indeed be due to suppliers.
- Risks – Again, not mentioned, but there is a touch of risk management in everyone’s role. The Product Owner will be concerned with external and commercial risks, the Scrum Master with risks to the team’s efficiency, and the Team itself organises its work accordingly.
So, to summarise in table form:
Now can you spot the PM?
I’m not saying that Project Managers shouldn’t retrain as Scrum Master. I’ve done it myself, and the training will teach you a lot about Agile. And the Scrum Master role itself can be interesting, demanding, exciting… I’m sure it would suit many former project managers. But if you’re a “seven essentials” sort of PM and you want to continue to develop those skills, then you should think about moving towards becoming a Product Owner.
Update March 2015
I’ve been reading Essential Scrum by Kenneth Rubin. Interestingly the book contains a very similar table, but using the PMI’s 9 knowledge areas from PMBOK Version 4 (since superseded by a slightly different set in Version 5). Here is Ken’s analysis:
[table id=2 /]