Is Agile killing the PMO?

I’ve grown very fond of Agile (the noun) in the last dozen or so years and I incorporate these concepts into my work and personal life. I try to be agile (the verb) in whatever I do. I am also the leader of a Program Management Office (PMO) in an enterprise with hundreds of employees. We are working to utilize more and more Scaled Agile concepts in our day-to-day operations and throughout more functions of the enterprise. We have more than 20 Agile teams that are all delivering valuable things in Scrum every 2 weeks all around the world.

Frequently I get asked questions like –

• What is the difference between an Agile Practice and a PMO?
• What is the difference between Agile Practitioners and Program Managers?
• Who is “on point” (a.k.a. responsible) for the delivery of this project?
• How should an Agile team interact with non-Agile teams in the enterprise?

I think these questions demonstrate a healthy tension that Agile is causing in most functions of an Enterprise today – the PMO included. Agile sometimes makes people nervous but it shouldn’t. Learning to adapt to these (not so new) ideas will make project process more effective. Things like alignment of priorities, discovery of problems and transparency of progress are built into Agile processes. They also make for happier teams. These are all great things for a PMO.

Agile sometimes makes people nervous but it shouldn’t. Learning to adapt to these (not so new) ideas will make project process more effective.

Agility isn't just a work thing

First, let’s level-set. The idea of Agile isn’t a new one and is commonly credited to have gotten its start in assembly-line manufacturing. Honestly though, successful people have been doing agile things long before there was a “name for it” so it’s probably been around as long as humans have. Agile however was more formally born in February 2001. 17 people met at a lodge at Snowbird Ski Resort in the Wasatch mountains of Utah and created an “Agile Manifesto for Software Development”. There are 4 primary values that this Agile Manifesto proclaims:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

They go on to say: “That is, while there is value in the items on the right, we value the items on the left more.” I made the items on the left bold to accent their point.

They value people and personal interactions. They value something that is functional and operational even if not yet complete. They prefer working together on the most valuable tasks as one team. They value adapting to what is needed right now over what was in the original agreement.

There are then 12 principles that are derived from these basic Agile values -

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Sure, this is focused on software development. But using this as a framework, I think we all want to deliver quality and value with anything what we do. We want to adapt to changes in our lives instead of fighting them. We want to enjoy the people we spend time with and collaborate with them. We want to live our lives at a comfortable pace. We want things to be simple and fun.

We want these things at our jobs sure, but these aren’t just work things. These are life things. If you follow these ideas, you are Agile. Be valuable, adapt, enjoy others, make things easier and set a sustainable pace. You can apply these ideas to anything you do. You too can be more Agile.

We want these things at our jobs sure, but these aren’t just work things. These are life things. If you follow these ideas, you are Agile. Be valuable, adapt, enjoy others, make things easier and set a sustainable pace. You can apply these ideas to anything you do.

PMO responsibilities

Let’s bring it back to professional life. A PMO has certain responsibilities. I’ll generalize a little and this depends from company-to-company of course, but here’s my take:

A PMO should –

• Help the organization have clear and aligned high-level goals
• Help the organization determine strategically important projects
• Help the organization get the right resources (budget, people, skills) to execute projects
• Track and manage an inventory of said resources (budget, people, skills)
• Create and own tailored process and provide guidance in how to enable project success

In other words –

• Figure out what projects we should do
• Figure out if we have what we need to do the projects we should do
• Figure out how to make sure projects succeed if we are going to do them

Now, I’ll take that one step further on the last point. If we are going to execute a project, then that will mean some teams executing stuff and a bunch of cross-functional activities to support the teams in what they deliver.

I’d suggest that Agile process is the best way to form and execute in teams (see previous section). So if we are going to do Agile, how do we make sure that we do it well and continue to improve? We do that with an Agile Practice.

The job of the Agile Practice is to own the Agile Operating System (OS) for the organization. They teach people how to do it, they step in and help, they facilitate, etc. They do whatever is needed to make sure that if the company is going to do Agile, then they do a great job of it.

So if we are going to do Agile, how do we make sure that we do it well and continue to improve? We do that with an Agile Practice.

Agile Practitioner vs. Program Manager

So then, what is the difference between an Agile Practitioner and a Program Manager? I see it this way: Agile Practitioners are focused on internal team indicators. Program Managers are focused on cross-functional external indicators.

Agile Practitioners are guardians of the Agile OS. In addition, they are paying attention to things like team output, the dynamics within the team and how to get the team into a high-performing state. They are “with the team”. That doesn’t mean that they are always physically co-located with the team, but it does mean that they are the advocate for the team. They are part of the team and doing what is best for the team so matter where they sit physically.

Program Managers on the other hand are “with the business”. They are facilitating the Agile team as they integrate and interact with the entire enterprise. They scan for dependencies and risks and are a single point of contact for the project. Their external focus makes sure that whatever the Agile team delivers is able to be consumed appropriately by the rest of the business.

Now these are not necessarily distinct. There is overlap between the roles and many times a person will serve both roles – I know I certainly have. It ends up looking like a Venn Diagram with the overlap in the middle.

Seeing it in action

As an example, let’s say the organization is building a software product to sell in their market. The PMO helps the company determine if they should build that software to meet the needs that are intended. Assuming that makes sense to do so, then the PMO will determine if the organization has all the things that they need to execute this project. Do they have the right people, the right skills, the infrastructure and budget to make it happen? If yes, then how should the project be executed? Spoiler alert: I personally believe an Agile team will do the best job.

Now if we are going to do this an Agile way, then we have Agile Practitioners to make sure that the team is as optimal in regard to process and that they are accountable, transparent and happy – improving and adapting to provide the most value with each iteration.

At the same time, we have the Program Manager to make sure that if another person or group needs to interact with that team, that they do so in the best way for the stakeholder and the least disruptive for the Agile team. The Program Manager uses Agile concepts (remember it’s a way of working) to scan ahead for risks, plan for the integrations, provide overall status and make sure that everything is running as smoothly as possible. As an example – they might run a “daily standup” with a representative member of each of the different groups of the organization that interact with the team. They themselves are not a Scrum team, but by providing this ceremony, we keep everyone informed and information transparent. In addition, we find impediments as they pop up - within 24 hours. That is pretty agile.

The PMO helps the company determine if they should build that software to meet the needs that are intended. Assuming that makes sense to do so, then the PMO will determine if the organization has all the things that they need to execute this project. Do they have the right people, the right skills, the infrastructure and budget to make it happen?

What about scaled Scrum?

You might ask me now – what about in a Scaled Scrum model? Using Scrum@Scale as an example, which is the model we currently follow in my PMO – then we have a way to identify problems every day through Daily Scrum, Scrum-of-Scrums and then ultimately the Executive Action Team (EAT). We also have a way of adapting organizational priority through an Executive Meta Scrum (EMS) backlog artifact.

What if every employee in our organization was part of a Scrum team? What if all of our problems were exposed and escalated daily? What if our organization’s priority was inspected every 2 weeks and updated and cascaded through the backlogs of all Scrum teams ensuring that every team and thus every person was working on the most important item in the organization? This is a great idea and I am on board – but this process takes a long time to transition to. Maybe even years for an existing enterprise. It doesn’t have to of course if the company is in crisis, but most companies aren’t in that state. They just want to do a better of job of executing their deliverables. 

If this were the case - that the entire company was running in a scaled Scrum model that was fully implemented, then we might be able to live without a traditional Program Manager. I would however suggest that even then - if we had Program Managers on point to scan for risks and assist with cross-functional activities - it would be almost impossible to miss anything. Project success would be virtually guaranteed.

So in closing, I think we need both Agile Practitioners and Program Managers. I think we need an Agile Practice as part of the PMO. I think Agile Practitioners keep the Agile teams top-notch and the Program Managers integrate the Agile teams into the rest of the organization smoothly with less risk. I think these are all different pieces of a PMO puzzle that can be used to make sure that the right projects are getting done well, with value, in a repeatable and sustainable way. All of these things are critical for an organization going through a transition to full agility. A transition that likely never ends, but instead continues to adapt to what is needed.