22 Jun 2018
There is often confusion when organisations transition to an agile way of working, particularly with the mapping of roles. A common question is how do Project Managers work with Scrum.
Scrum does not have the Project Manager role. The work is completed by the 3 roles in the Scrum Team.
| Scrum Role | Project Manager Duties |
| Product Owner | Product Planning (Scope) Financial Planning Stakeholder Collaboration Tracking of progress at higher level |
| Development Team | Detailed Planning Tracking of progress with Sprint Quality Control |
|
Scrum Master |
Following the process Removal of impediments Team improvement |
The two paradigms are fundamentally different in their approach to work, however they have the same intent or business outcome in mind.
| Aspect | Predictive | Empirical |
| Risk | Detailed within the Risk Management
strategy.
|
Light touch, emphasis on “Done” and
frequent delivery reduces the overall risks. Focus on delivery is the key
minimiser.
|
| Work/Effort | Detailed tracking of individual effort. Expectation of working on multiple projects at one time. | Focus on minimal number of projects (preferably one) at a time. Cost tracked at Sprint level as a whole “Burn Rate” |
| Estimation | Detailed estimation to a granular level. Estimate then tracked and managed. | Forecasts are accepted to be within a level of tolerance, and coarser grained. Tracked against work remaining. |
| Timeframe | Usually fixed. | Fixed for a Sprint. Further Sprints are commissioned if the work is deemed to be of Value. |
| Release Planning | Planning tied back through estimation, often with fixed deadlines. | Releases planned when value can be achieved. |
| Value attainment | At the end of the product. Tracking risks primary means of managing delivery. | The whole intent is to deliver value every Sprint. A failure to deliver in a Sprint highlights the impediments for the team and organisation. |
| Compliance | Met with external reviews. | Captured and applied in Product Backlog Items and the Definition of Done. |
| Reporting | Many reports, depending on size of project.
Earned Value Analysis Tracking Reports |
The primary artefact is a working product.
Release and Sprint Burndown charts |
|
Tolerance Area |
Project Level Tolerances |
Stage Level Tolerances |
Work Package Level Tolerance |
| Time | Project Plan | Stage Plan | Work Package |
| Cost | Project Plan | Stage Plan | Work Package |
| Quality | Project Product and Product Descriptions | N/A | N/A |
| Scope | Project Plan | Stage Plan | Work Package |
| Benefit | Business Case | N/A | N/A |
| Risk | Risk Management Strategy | Stage Plan | Work Package |
1 http://prince2.wiki/Progress
Tolerance Area
| Product Level Tolerances
| Release Level Tolerances
| Sprint Level Tolerances
|
Time
| Product Roadmap Product Backlog
| Product Roadmap Product Backlog
| Fixed on outset
|
Cost
| Forecast by Number of Sprints and supporting costs
| Forecast by Number of Sprints and supporting costs
| Fixed for Sprint (Burn Rate)
|
Quality
| Fixed by Definition of “Done” reviewed each Sprint
| Fixed by Definition of “Done” reviewed each Sprint
| Fixed by Definition of “Done”
|
Scope
| Product Roadmap Product Backlog
| Product Roadmap Product Backlog
| Forecast agreed at Sprint Planning by Scrum Team Sprint Backlog
|
Benefit
| Product Vision Business Case
| Release Vision Business Case
| Value delivered
|
Risk
| Product Backlog Impediment List
| Product Backlog Impediment List
| Daily Scrum Sprint Review Impediment List
|
How progress is measured and communicated is different, as the approaches are different. The purpose is to review where progress is with respect to the initial plan, and a significant aspect is the level of detail and granularity in the plan.
In predictive management it is primarily the Project Manager who is responsible for tracking against the plan. This may be a tracking Gantt chart, with exceptions escalated. The Project Manager is the role that cascades the information.
Within Scrum the whole team is responsible for tracking at the various levels. The Daily Scrum and Sprint Review are events where there is a direct focus on progress, and how to get work delivered. This will be monitored with the Sprint Burndown, and Release Burndown.
The common factor is to make the visibility of progress highly visible, and this is the purpose of using the different reporting types.
Risks are managed very differently. In Prince 2 there is a Risk Management Strategy to identify and manage Risks. Within Scrum Risk is one of the many factors affecting the Product Backlog order. The primary way to mitigate risk is to resolve the risks by delivering a working product increment. Delivering working products will mitigate business, technical and market risks by making sure early in the project life that we are delivering what the customer has asked for. This mitigates risks by building functionality as quickly as possible to gain feedback in order to make any needed changes and by validating any assumptions made about the functionality.
Both processes will require a business case to start doing further work on the product. The model is based on the estimation basis.
| Predictive | Empirical |
| Budget Baseline defined on initialisation | Initial forecast, adjusted each Sprint |
| Return on Investment (ROI) forecast | ROI reviewed every Sprint |
| Variable spend dependant on people and resources in use | Steady spend based on stable teams, with Spikes from additional resource spend |
| Value delivered at the end | Value delivered every Sprint |
All the agile frameworks are designed to be flexible, and allow for a minimal cost to re-plan. The Product Backlog is the instrument of planning at the Product and Release level, with the Sprint Backlog as the instrument at the Sprint level.
Within predictive Project Management, changes are managed by a Change Management Process when the variability triggers an exception beyond the bounds of tolerance set for the required level. The cost is proportional to the size of the change.
The key is the style of interaction. Predictive Management tends towards a command and control model of status updates and direction. Scrum is based on facilitation and a “pull not push” model.
The Project Manager (PM) assists the Product Owner (PO) and the Scrum Master (SM) with their respective duties
For this to be effective the style of interaction needs to be collaborative, with the PM working within the framework. They should respect the process and not disrupt events looking for updates.
The PM can then support the wider organisation with understanding tracking artefacts from the Scrum process.
When the circumstances are appropriate and the Project Manager demonstrates the correct behaviours (pull not push, ask don’t tell), they could choose to become either a Product Owner or a Scrum Master. The choice would be based on what the person favours – the business value focus or the framework and problem resolution.
If they prefer the stakeholder collaboration and business value – move towards the PO role, alternatively the SM role.
If their preference is to remain working in the same way, they should remain working on predictive projects to manage projects that are deemed to be run in a predictive way. If the individual is not willing to engage with the people in an agile way, their behaviour can become disruptive - reducing transparency and undermining self organisation
Within many organisations undergoing transformation there is a misconception that the Project Manager is senior role to either the Product Owner or Scrum Master. This is not the case. For the agile implementation to function, the Project Manager may work as a shock absorber between the Scrum Team and the organisation. It is critical that they do not act as a filtering lens, distorting the view or watering down the transparency of how the team works.
Scrum does not have the Project Manager role. The responsibilities are completed by the 3 roles in the Scrum Team. So, where and how does a Project Manager fit within Scrum?
The key is the style of interaction. Predictive Management tends towards a command and control model of status updates and direction. Scrum is based on facilitation and a “pull not push” model.
It is naïve to think that to change to working with Scrum, first you need to dismantle the PMO and release all the Project Managers. That is wasteful, as these people are usually the ones who know how the organization really works, and have abundant experience in seeing work delivered. The focus should be on helping them understand the new work model, and enlisting their support in the transition.
The role of the PMO is to support the Portfolio, Program and Project work for the organisation. This will cover the execution and governance of work, as well as maintain a focus on effectiveness across the enterprise.
A well-functioning PMO will have an understanding of the work in flight, and have a significant amount of experience and political influence. For the transformation to be successful, the PMO needs to align with the new model, and support the change in process.
| Responsibility | Predictive | Empirical (Scrum) |
| Engagement Style |
|
|
| Focus |
|
|
| People |
|
|
| Pipeline of Work / Scope |
|
|
| Change Control |
|
|
| Finance |
|
|
| Risk |
|
|
| Training |
|
|
| Governance |
|
|
| Supplier Engagement |
|
|
| Reporting |
|
|
| Tools |
|
|
APD will help improve the way you build products in an iterative and incremental way. Get in touch today for a free 30 minute consultation.
Contact Us
