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.
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:
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:
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.
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.
Many Info-Tech members are wrestling with how to best manage their software development productivity while working from home, especially for teams using a Waterfall approach. Sprinkling some Agile practices into their normal routine could improve transparency and show continuous value delivery.
When deciding on how to license your products or components, you don’t start with debating open vs. closed source code. It starts with asking simple questions around your overall goals.
Not all metrics are good and using poor metrics can have a serious negative impact on your organization. Maximize the value of your software development lifecycle (SDLC) metrics by using this thoughtful and judicious approach to ranking and selecting them.
RPA projects fail more often than one would expect. The ease with which RPA tools allow workflows to get designed and implemented makes it easy to avoid building a strong foundation for the work being done.
We live in a metrics-fixated world where having more metrics is always thought to be better than having less, and Software Development Life Cycle (SDLC) metrics are no exception. But the truth is that any badly chosen or managed metric will do more harm than good to your organization. To avoid these pitfalls, take ownership for SDLC metrics away from managers and put it into the hands of those who can best manage it: your development teams.
Robotic process automation (RPA) success is dependent on the right business processes to automate. Blueprint helps identify the right places to apply RPA with its Enterprise Automation Suite.