Project management methodologies and agile frameworks have some similarities and lots of differences. So, when taking your first steps to using Scrum – the most popular of the agile frameworks – what are some key differences between the role of the Project Manager and the role of Scrum Master to be aware of?
1. A Project Manager is responsible for the project's outcomes. A Scrum Master isn't.
The Project Manager is responsible for organising and controlling projects[1]. They do this by selecting people to do the project work and ensure it’s done properly and on time. Project Managers also draw up the project plans that describe who the project team is, what the project team will be doing, and when they expect to finish.
Scrum Masters don’t create delivery plans. The Development Team creates its plan for delivery each Sprint in Sprint Planning by selecting items from the Product Backlog. Their plan is made transparent in the Sprint Backlog. Over time, sustainable pace creates predictability and enables the Product Owner to define future objectives and forecast when things will likely be done.
Scrum Masters facilitate and support these activities, but they certainly don’t have responsibility for organising and controlling. Their role instead encompasses:
- Coaching the Product Owner on empiricism
- Providing the Product Owner with tips on managing the Product Backlog
- Supporting the Development Team to self-organise by facilitating Scrum events (e.g. Sprint Planning) and helping them to resolve impediments to the delivery of work (not resolving impediments for the team).
- Coaching stakeholders on agile so they can optimise their interaction with the team.
2. Project Managers direct and approve work. Scrum Masters don't.
Project Manager to group work activities together in the work of work packages and assigns the work to a team to produce its deliverables.
Scrum Masters don’t assign work. They don’t monitor the progress of work. And, team members certainly don’t report the status of work to the Scrum Master at the Daily Scrum.
Instead, the Development Team is designed to be self-organising and the Scrum Master supports them to do this. Self-organising, though, as David Marquet, famed author of “Turn the Ship Around” highlights “If you’re picturing a lot of people out there doing crazy things and a bunch of arrows going in a bunch of different directions you have the wrong picture”.
Self-organisation requires rules that sets constraints and expectations on how the team operates. Scrum provides these boundaries and accountabilities so that self-organisation is effective and responsibilities and expectations are transparent to everyone. These boundaries are:
- Timeboxes – All Scrum events (i.e. Sprint Planning, Daily Scrum, Sprint Review, Retrospective, and the Sprint) have a maximum time to get work done, including the Sprint itself.
- Artefacts – The team must keep their Sprint Backlog transparent and reflective of all of the work needed to create an Increment at the end of the Sprint.
- Potentially Releasable Increment – The team must produce an Increment of work by the end of the Sprint.
- Work must adhere to the quality, standards, and the security and compliance requirements set out in the Definition of Done.
Who approves the work then?
The team are required to demonstrate to the Product Owner and stakeholders that their work is potentially releasable at Sprint Planning. Because the Product Owner is the change authority, they can be thought of as “approving” that the work is done and can be released. If stakeholders or the Product Owner has feedback (the actual intent of the Sprint Review), if there are minor variations needed to the product, or even new large features now need to be done, then this feedback is captured in the Product Backlog and re-prioritised by the Product Owner.
What if the team can’t self-organise?
Many teams struggle with self-organisation when they begin to use Scrum. The Scrum Master’s job is to support them. Sometimes they may have to be more directive at the beginning, so understanding the capability of the team and its agile maturity is key to understanding what stance the Scrum Master should take when supporting self-organisation.
3. Project Manages are responsible for reporting. Scrum Masters aren't.
What reports do projects use?
Project Managers report to Project Boards, so Project Managers tend to be responsible for project reporting. For large projects, Project Officers might undertake this role. Traditional reporting typically includes written communications on status, progress measurements, and forecasts (PMI, 2008, p. 266) to many different stakeholders [2]:
- Internal stakeholders, including the project team, project manager, functional line managers, top level executives, and assurance review teams.
- External stakeholders, including the project partners, national agencies, local government representatives, non-government organisations, media representatives, and authorities.
A multitude of reports is often needed because, as a project is essentially an outsourced activity with the output handed over to stakeholders when the project concludes, people not involved need to understand what is going on so they can make governance decisions regarding how people, budget, and other resources are managed. Unsurprisingly, this can lead to long lead times for decision-making.
Furthermore, stakeholders are invited to attend the Sprint Review and participate directly, face-to-face, to understand what work has been done, what work isn’t done, and to provide feedback and discuss the work for future Sprints. Feedback is captured in the Product Backlog. Again, this reduces the reporting burden.
What reports does Scrum use?
Scrum, though, is agnostic in terms of what types of reports to create and who should do them. Decision-making authority on how the budget is spent and what scope is delivered is invested in the Product Owner, not a Project Board. All decisions about what to deliver and when is made transparent in the Product Backlog. Ultimately, this tends to reduce the reporting burden.
The agile team is stable over time and typically fixed in numbers (3-9 being optimal). This results in reducing the need to shift people from team-to-team or deliverable to deliverable, so its associated reporting reduces as well. The impact is a fixed budget for people for the team (i.e. costs per Sprint become fixed), so budget forecasts are simpler which results in a reduction in the reporting complexity and overhead.
The resultant decrease in complexity of the system of work that Scrum creates means that reports typically include:
- A Roadmap – A forecast of what will be released in future Sprints.
- Features – When certain key features will become available for end-users.
- Budget vs Features – If there is a fixed capital budget, when will the budget run out and what features can be delivered in that time.
Above: Typical product roadmap showing forecast of features per quarter and release milestones:The Product Owner does this work, not the Scrum Master
Importantly, it’s typically the Product Owner who is responsible for producing these types of report. Afterall, the Product Owner is responsible for making decisions on when to release value, the budget, and the items that will add the best outcome to the product.
Product Owners should be inviting stakeholders to the Sprint Review, not solely communicating and managing by reporting
Rather than rely almost exclusively on written reports, the Product Owner should invite stakeholders to the Sprint Review and participate directly, face-to-face, to understand what work has been done, what work isn’t done, and to provide feedback and discuss the work for future Sprints. Feedback is captured in the Product Backlog. Again, this reduces the reporting burden.
The Scrum Master isn’t the Jira or Board manager
Because the Scrum Master isn’t responsible for delivery, or the work the team does, or even the output of the Sprint, Scrum Masters aren’t responsible for things like keeping the Scrum Board or the team’s digital tools up-to-date. The Scrum Master doesn’t manage Jira or Microsoft Azure on behalf of the team because the team are self-organising, so they’re expected to do this themselves.
It’s probably your Product Owner who should do the reporting
Product Owners, though, are responsible for the forecast of what will be done and when by managing their Product Backlog. It’s logical to assume that when it comes to reporting, they’re the ones to brief stakeholders at Sprint Review regarding what features are ready to release and what work still needs to be done in the future. This type of governance meeting supersedes the need for specialist Project Board meetings and, importantly, reduces the wait time for decision-making.
Conclusions
Many organisations look to create a translation matrix between their old roles and new, agile roles to help them transition to contemporary ways of working. Scrum, though, isn’t a project management methodology. It is a product management framework, and so uses different roles and responsibilities to optimise the delivery of value in the shortest time possible. This still requires someone to be focussed on delivery, but the speed of decision-making is optimised through empowering the team to be self-organising.
One of the most critical responsibilities for the Scrum Master is to support self-organisation, and not to direct, control and approve work. For many organisations, transformation takes time. For those who’ve achieved this result, the outcomes are typically double the amount of output and significantly improved time to market.
References
- PRINCE2. https://www.prince2.com/aus/prince2-methodology#:~:text=The%20Project%20Manager%20takes%20on,when%20they%20expect%20to%20finish.
- PMI (2011) Are you overwhelmed preparing too many reports? A smart approach to project reporting.
