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?
The Project Manager is responsible for organising and controlling projects. 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:
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:
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.
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.
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 :
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.
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:
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.
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.
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.
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.