Projects Managers vs Scrum Masteres

Intermediate

difficulty

Stage 1

Agile IQ® Level

Guardrails

Practices

Scrum

Framework

Introduction

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.

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 the product, making decisions on when to release value for the product, the product’s 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.

Actions

Do you still use project managers?

In a Retrospective, use the 1-2-4-All pattern from Liberating Structures to delve into your rationale for needing a project manager.

Timebox: 1 minute. Ask the team to silent brainstorm on sticky notes all of the tasks and areas of responsibility of a Project Manager.
Timebox: 2 minutes. Pair people up to share what they’ve written.
Timebox: 10 minutes: Put pairs together and ask them to share their sticky notes and to re-sort them against the Scrum Master and Product Owner role in Scrum.
Timebox: 15 minutes debrief. Where did the Project Manager’s tasks and responsibilities end up? What conclusions can you make regarding the responsibilities of the Project Manager role in project management versus the responsibilities of the Product Owner and Scrum Master in agile product management?

Questions to consider

If the Product Owner is accountable for the success of the product:

Does that mean they also have the responsibilities of a traditional delivery manager?
Should they be writing reports to stakeholders and committees on the state of delivery?

If the Scrum Master is accountable for coaching:

Should the Scrum Master be reporting on the strength of the agile capability of the team?
Should the Scrum Master be held to account for creating capability improvements that yield improved throughput?

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.

All fields are required.