Comprehensive software reviews to make better IT decisions
What Is the Role of the PM/PMO on Agile Projects?
Info-Tech members who are moving to Agile are frequently unsure what the role of project managers (PMs) and the project management office (PMO) is in an Agile environment. Any organization that is used to following traditional (Waterfall) project management practices will need to make some sideways adjustments in support of Agile or risk losing the benefits it would otherwise bring.
Note: This is a companion piece to Explaining Agile to Management and Your PMO (How to Foster Their Buy-In and Support) – consider reading it first for a better understanding of Agile benefits and how it differs from Waterfall. For the purposes of this tech brief, we will limit ourselves to organizations that are large enough to have an established and traditional project management process in place (typically Waterfall or Phase-gate) and want to understand the altered role PMs and PMOs play on an Agile project.
Let’s begin by saying that Waterfall and Agile are not simply two sides of the same coin. They are very different approaches, and so they must be project managed very differently. To do otherwise is folly. As an example, any organization that imposes a rigid Waterfall project gating process on an Agile project risks erasing any benefits the organization may have realized from Agile, up to and including risking failure of the project. Your organization’s project management approach will need to adjust in a way that is supportive of Agile’s strengths if you hope to succeed with it.
These required adjustments can be most simply described by comparing/contrasting the high-level responsibilities of PMs and PMOs under Waterfall and Agile as shown below:
What follows are generalized explanations and recommendations about how the role of PMs and PMOs should be altered to support an Agile environment (it is not presented as an exhaustive or complete explanation of the changes required). Organizations are encouraged to adopt and adapt these changes to their individual circumstances. For more specific guidance about how to apply this to your organization, arrange for an Analyst Call with an Info-Tech representative.
The PM’s Role in Agile
Strictly speaking, there is no defined role for a PM in Agile projects. Agile methodologies (like Scrum) rely on self-organizing cross-functional teams who are empowered by the organization to make key project decisions and to problem solve as they go. Scrum teams consist of a Product Owner, Scrum Master, and Development Team, and they deliver projects without following a detailed project plan like those commonly used in Waterfall projects. Together, the Product Owner and Scrum Master roles fulfill a majority of the functions that would normally be done by a PM. However, organizations can and should still assign a project manager to Agile projects, albeit with modified responsibilities.
In a Waterfall project, the PM plays a key leadership role in delivery by orchestrating the activities of all project team members through a detailed project plan. On an Agile project, the PM’s role is diminished but is still vital to the overall success of the project. Instead of providing leadership, a PM on an Agile project plays a role in supporting and monitoring the project and acts as an escalation point to the PMO and senior management (as a side note, don’t make the mistake of substituting either the Product Owner or Scrum Master with a project manager – their skills and responsibilities differ significantly).
Here is a little more detail about the PM role in Agile:
- At the beginning of an Agile project (often called project initiation) the PM’s role is unchanged (i.e. they will do very similar project initiation work for either a Waterfall or Agile project).
- Once an Agile project is approved, a PM’s role will change. There will be no detailed project plan to create or report against, and the day-to-day leadership/management of the project falls to the Scrum Master and Product Owner. The PM’s primary responsibility morphs into acting as a bridge between the Agile project team and the needs of the PMO. The PM role becomes one of support, monitoring, and escalation.
- Support: The PM’s support responsibilities have two main components. Firstly, it involves being able to explain Agile (its approach and its benefits) in a digestible way to the PMO, senior management, and the remainder of the organization in order to foster support for the “different way of working” that Agile represents. Secondly, it involves acting as a liaison and coordinator of activities for non-Agile areas of the organization that are interacting with the Agile project team (securing resources, commitment, and buy-in as needed). The PM will also need to manage any Waterfall projects/subprojects (using the traditional approach) that are related to the Agile project (e.g. any [Waterfall] hardware development done in support of an Agile software development project).
- Monitoring: Because Agile represents a different way of working, a different way of monitoring will be required. The PM will still provide regular status updates to the PMO on Agile projects but will do so using metrics aligned with Agile practices (think: Sprint velocity and burndown charts as opposed to % task completion or lines of code written), and will also monitor/report on project risks in an Agile way (think: simple prioritized list of potential risks to the project and a yes/no indication of whether they are currently of concern as opposed to an exhaustive risk mitigation plan). As a side note, the use of effective Agile management tools (like Jira, VersionOne, or Helix) and automated testing tools (like Parasoft, Selenium, or TestComplete) will make Agile project monitoring easier by automatically generating Agile project metrics with little to no manual effort.
- Escalation: Most importantly, the PM needs to act as an effective escalation point for project roadblocks or critical issues that need the attention and support of the PMO and/or senior leadership within the organization. A well-functioning Agile project team is a self-organizing, self-managing entity that has been empowered to deal with obstacles as they see fit because they are in the best position to grasp and deal with them. However, an Agile team can encounter problems that are “too big” for them to conquer on their own and so must have a fast track to the PMO and senior management to solicit their help. This PM function is critical to the success of Agile projects.
The PMO’s Role in Agile
One of the primary responsibilities of your PMO is to provide governance and oversight of project activities. This is typically accomplished by use of a traditional (think Waterfall or Phase-gate) project gating process (PGP). But it is important to know that a traditional PGP will not work for an Agile project because it relies on a rigid linear approach that is at odds with the Agile approach. In fact, forcing an Agile project to follow a traditional PGP will, with almost absolute certainty, cause it to fail.
To avoid this risk, an organization’s PGP must be repurposed for Agile projects. Thankfully, this can be done without changing the PMO’s primary governance and oversight role. For Agile projects, this can be accomplished by altering your PGP to focus on verifying that the project is following good Agile practices instead of good Waterfall practices.
Here is a little more detail about how to adjust the PMO/PGP role in Agile:
- First and foremost, eliminate any aspects of your PGP which impose a Waterfall approach on the project (remove anything that forces Define, Design, Build, and Test activities to be done linearly by the project – in some organizations, this might mean the bulk of your PGP!).
- Now, restructure your PGP to ensure that projects are following good Agile practices, and have the support they need to be successful. Think:
- Have adequate and fully available Development Team resources been assigned to the project, and does the team have adequate cross-functional representation?
- Has support, understanding, and buy-in from the rest of the organization been established for the Agile project’s “different way of working”?
- Have effective Agile tools been selected and adopted by the project team?
- Has a Product Owner with good subject matter expertise and high availability been assigned to the project and empowered to make critical prioritization decisions quickly with appropriate stakeholder involvement over the life of the project?
- Has an experienced full-time Scrum Master been assigned to the project, and do they understand the nature and importance of servant leadership?
- If this is the project team’s first Agile project, have all team members been trained on Agile? This is important and necessary but not sufficient, so has an experienced Agile Coach also been assigned to assist the project? And do at least some of the team members have previous experience with Agile to help mentor and guide their first-time-Agile team mates?
- Is the project team adequately following good Agile process practices (e.g. are Scrum Ceremonies being performed regularly and effectively)?
- Specifically, are Sprint Retrospectives being performed in a healthy fashion so as to create an environment which fosters nonjudgmental identification of project problems and a collaborative approach to eliminating them quickly and effectively?
- Has the project team been adequately empowered by the organization to take ownership and responsibility for successful delivery of the project and given appropriate authority to execute the project?
- Is the project team properly executing its role of ownership and responsibility for the project?
- Are stakeholder and end-user/customer needs being properly captured and expressed to the project team and are these needs being addressed?
- Do the stakeholders and project team adequately understand the organization’s goals and priorities and their applicability to the project?
- Have any barriers to success of the project been identified due to resistance to change or use of Waterfall approaches by the rest of the organization? Has senior leadership stepped in to correct this problem?
Making these PM/PMO role adjustments will help to raise your organization’s probability of success with Agile adoption while ensuring effective and appropriate project oversight takes place (which is the primary reason for having PMs and PMOs after all!). Once again, for more specific guidance about how to apply this approach to your organization, arrange for an Analyst Call with an Info-Tech representative.
Want to Know More?
Is it true that everything that can go wrong will go wrong? Don’t bet on it to not.
While Microsoft is not a prominent player in the RPA space now with its Power Automate solution, compared to Blue Prism, UiPath, and Automate Anywhere, its latest acquisition of Softomotive, maker of WinAutomation, demonstrates Microsoft’s dedication to mature and expand its RPA offerings.
Test data management tools offer you the ability to provision, mask, and govern the access and use of your test data, alleviating these manual, laborious and error-prone tasks from your testing, operations, and DBA teams.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
Agile systems delivery (implemented through Scrum) is quickly becoming an accepted norm in IT. But using Scrum successfully in an organization requires a deep understanding of how it works and why. For example, many of our members don’t understand the importance of selecting a Product Owner who has three ears.
Reeling from the pandemic response executed by governments all the over world, companies are accelerating their implementation of low-cost automation. That bodes well for UiPath – a leader in RPA aiming to go public this year.
Thor, the Norse God of Thunder, tells Jane Foster, the woman he’s trying to impress, that on his home world of Asgard, the realm eternal, science and magic are two sides of the same coin. Had Jane been a part of the operations teams at Google (or other mature online service providers), she would have immediately realized we have a similar technology right here on good old Earth. We call the science site reliability engineering (SRE), and service level objectives (SLO) is the magic behind it. SRE is a powerful concept for organizations that are serious about keeping their customers happy. It is therefore important for them to develop well-thought-out SLOs and make certain that management is intellectually equipped to derive valuable business perspectives from them.
Hell hath no fury like a customer not being able to access an online service when they want to. They expect the online services to always be on, always be accessible, and always treat them like there’s no one else in the world who matters more. Thank heavens then for giving these online services the ability to use site reliability engineering (SRE) to keep their customers happy, engaged, and most importantly, feeling valued.
GitHub has announced that, effective April 14, 2020, all of its core features will be free for everyone. This will include private development within organizations that have previously paid for some subscription plans.