The PMO Is Dead. Long Live the PMO.

The following is an excerpt from a presentation by Jonathan Smart, head of Ways of Working at Barclays, and Morag McCall, who works in Barclays’ Portfolio Management Team and is responsible for risk and governance, titled “The PMO is Dead, Long Live the PMO.”

You can watch the video of the presentation, which was originally delivered at the 2018 DevOps Enterprise Summit in London.

Let’s begin with a bit of context

Barclays is a financial services firm. We’re a universal bank. We were founded 328 years ago, in 1690 in the city of London. Four years before the Bank of England existed, and about 90 years before the United States of America existed. We have 80,000 employees in 40 countries, and we have 29,000 staff in technology. We have an annual revenue of £20,000,000,000. We have 48,000,000 customers. Every day, we process 30% of the annual UK gross domestic product, so that’s £600,000,000,000 a day is flowing through our systems.

In terms of technology statistics, we have over 6,000 applications, the majority of which are in-house developed. We have more than 3,000 change initiatives running. We have a production change every 18 seconds, and we have 8,000,000 hits a day on our artifact repository.

In terms of timeline, pre-2014 we had islands of agile and DevOps, only our island has “help” written on it. I was running one of those islands of agile, and I had a pretty good idea who else was running an island as well.

In 2012, we started creating a number of communities of practice. The agile community of practice grew to be the biggest, with two and a half thousand people. This was done entirely voluntary. Nobody asked anybody to create this community of practice, nobody asked anybody to participate. These are the people who would give up their evenings, weekends and work extra hours to participate in an agile community of practice.

lean portfolio management & the role of the PMO in an agile organization

If you could wind the clock back two or three years, this is how a regular conversation would go with the development teams.

I’d say, “Is there anything else that you need to do after dev is done, and testing is done, to get this into production?”

And they’d say, “Yes, we need to wait for integration testing because we’ve got lots of dependencies, we haven’t decoupled the architecture, and we’ve got three or four or five systems that all need to be deployed together. So we have to wait for integration.”

Okay, so when you’ve done integration testing, are you then good? Are you then ready for production?
“Well, no, because we then have to wait for acceptance testing.”

Okay, fine, so you do your acceptance testing, and then anything else before you can then put that into production?
“Actually yes, because we batch up releases. So we have to wait for the release cadence, we have to wait for that to happen and for IT ops to be happy to do the release.”

Okay, is there anything else after that in order to reduce the time to market?
“No, after that, then we’re done.”

And so then I’ll ask, “Okay, so what’s the cadence on this, what’s the frequency?”

And it’s something like, “Integration testing is monthly, acceptance testing is quarterly, and releasing is quarterly. Because it’s hard we do it less often.”

But that’s not all, what happens prior to the work getting to the dev team?

Before it even gets onto the dev backlog, there’s a product backlog and it needs to be prioritized there.

But before it can get onto the product backlog, there’s a detail business case, and that needs to wait for approval.

Before that there is the detail business case, there’s an outline business case which needs to go to steering, and before you get to an outline business case, there’s an ideas triage.

What you end up with is something like this:

If we look to see at the cadence, the idea triage might happen monthly, and your outline business case and steering might happen quarterly. But with annual funding approval, detail business case might happen annually.

But if you spoke to the dev teams and they would say, “We’re so freaking agile, yay!”

Nope.

There’s a pretty big gap between customer needs identified to customer needs met. I’ve heard this multiple times in the organization. “Well, you said that agile and DevOps would fix everything, but I’m not seeing it.” This is perhaps not the best for end-to-end performance.

Here’s another important observation

When the work is in that ‘fuzzy front end’ of portfolio management, it’s sitting there for 18-months, or longer.

Up to this point, it’s not urgent, but as soon as it hits the dev team, becomes urgent. It becomes, “Why isn’t this done already?” or “God, IT, you take too long, you can’t move as fast as the business.” But actually, you ended up with an urgency paradox. Fuzzy front end, take your time, and then all of a sudden, “It’s gotta be done!” Which leads to unsustainable working, even when teams are within more modern ways of working.

Now, here are some other anti-patterns we’ve seen over time

1 — Anti-pattern: Over Committing

In this anti-pattern, you keep saying ‘yes’ to the customer, but you don’t really know what your throughput is, you don’t know what you can achieve in your system. As you keep on committing to the customer (who could be internal or external,) all the work backs up. Every month the backlog of work is growing by another month.

2 — Anti-pattern: Starvation and Overproduction, which may sound like an oxymoron.

With starvation and overproduction, the portfolio management process or the financial process is not sending anymore work down the pipeline. As a product team, you’re starved of work, but unlike physical manufacturing where the downstream machines cannot produce any more goods, humans can. What happens, is the humans, especially agile teams, have this cadence running, grooming the backlog, and eventually, they start creating fake work, and you end up with a feature factory.

I’ve seen this happen often and I’ve heard stories from other companies where this happens. You have the feature factory of the work still coming off the assembly line, but 75% of software features are never used. People keep producing stuff, disconnected from the strategic focus of the firm.

3— Anti-pattern: Feast and Famine

In feast and famine, we have a great, big batch of work coming down the stream. Again, this could be because of portfolio management processes, it would be the steering committee, it could be the approval process, it could be the financial process, etc.

But the poor team is throwing their arms up in despair, sweating, and unsustainable working environments. Then there’s famine. This is when there’s nothing, there’s fake busy, “Actually I don’t really have anything to do, I’m waiting for some more work to do.” which is like the previous anti-pattern, maybe there’s some feature factory stuff going on. And then we have feast again when the next big chunk of work comes down the pipe.

This is not a sustainable flow.

As an organization, as per the theory of constraints, focus on your biggest constraint. For us, we did a lot of work in the beginning around our continuous delivery lifecycle. That was one of our biggest impediments originally. Now we’re shifting left and looking at portfolio management and PMO.

the question: is there a role for a PMO in a large, agile organization?

We asked Twitter, (obviously, this is ‘highly scientific’) “What do you think the role of a PMO is in a large, agile organization?”

And Twitter said:

It really surprised me that 40% of people thought a PMO should not exist at all in a large, agile organization.

Morag McCall

I have some personal experience of this nature. A few years ago I was a program manager in a large financial services organization. Senior management wanted to go agile and to deliver faster. A number of consultancies were brought in to assist with this, and there was a big push to switch to an agile environment. The view was, “We don’t need project managers, program managers. We’ve set up a PMO function.” And the view was that these were impediments, and as a result, I was made redundant.

Unfortunately, what happens, as we can see from the anti-patterns, the perception might be, “Go ahead then, do DevOps, but with a PMO we want things to stay the same,” so they keep doing their RAG statuses, keep providing their Gantt charts, keep doing their predictive milestones, so long as nothing changes.

Is that really the only way, or is there an alternative?

Perhaps there is an alternative, but it may not be the PMO that you expected.

If we go back to my own experience, to be honest, I didn’t get agile then, or DevOps. I was used to working in a very waterfall environment. With the next role that I took, I was heading up the portfolio management team. I knew I needed to get a better understanding of how agile DevOps can enable faster delivery within an organization.

At this next organization, there was a big push again, coming more from the dev community to deliver agile. This time, I was able to actually gain sponsorship from the top down to ensure it wasn’t just dev, but we had the business, the product owners, we had the project managers, we had the PMOs, to receive training and become more knowledgeable about how agile can work.

I was able to work with the project managers to help them and advise them how it would still be able to demonstrate progress through delivery and achievement of value.

So jump forward, and I started at Barclays nearly three years ago, and at the time I started in the portfolio management team, where there was a big focus and emphasis on agile and on DevOps. But the PMO then was still very much with the tumbleweeds. It was very much project-centric, illustrating some of those anti-patterns, and we knew that we needed to change.

What did we do?

Chapter one: the toddler years.

We knew that we had a significant transformational change in our ways of working, both centrally in the portfolio management team, but for the PMOs working with the programs. We kicked off a program of work to look at improvements in our ways of working, but we knew that we needed to do this differently.

How did we do that?

We wanted to build agility in the PMO. We had an agile coach working with us in the team to help us build up from basics so that within the portfolio management team, we built understanding and knowledge starting with the basics and building a scrum.

Our agile coach acted as the scrum master, and we were able to start, at first with lots and lots of Post-Its and boards. Then we grew, we were now over five global time zones, we introduced the use of tooling so that we had virtual visibility of our weekly sprints in our backlog. We improved the way we delivered and delivered improvements faster.

We became a self-optimizing team. We would tell each other if things were not going so well. We bought a bell from Amazon to ding when people were talking too much in the stand-ups, and then if people were not attending we would use poo emojis for that.

Chapter two: the age of enlightenment

Pivoting to the concept of long-lived products, this is the advent of the value stream. Products deliver one or more business services. We were shifting from a project-centric view to a product-centered view. The value of long-lived product teams enabled us to look at how we optimized our portfolio, to fewer programs, and to focus on the strategic objectives which were what senior management wanted to have visibility of.

Chapter three: the Yoda years

We’re not Jedi masters yet, but we have seen a change. We have limited the portfolio of work in progress, and we’ve focused on the strategic objectives that the senior management wanted to see progress on.

We start finishing, we stop starting.

We shifted our focus to outcomes and value rather than output and activity. We’re not looking at predictive milestones, we’re focusing on the concept of business outcomes. This allows us as a team centrally and our PMOs to be more advisory, consultative, and support. Our PMOs work with the value streams. The focus is on dependency management and release management working across the different value streams, but still aligned with the programs.

And it’s helped just to pivot to become a learning organization. We learn more about how we deliver and how we can improve how we deliver.

Jonathan Smart

Now let’s look in terms of how we all organize the work.  

1. The key unit of work is a business outcome. A business outcome is three months, if it isn’t regulatory and mandatory, it’s written as a hypothesis. Such as, “We believe that doing this work will lead to this outcome, we’ll know we’re on the right track when: key measure one, key measure two, key measure three.” And that’s the articulation of value. It needn’t financial, or about obsessing over the customer, etc. This is the main unit of work, and this is also the unit of work for our control, our GRC, our compliance conversations, the conversation around information security, information risk management, GDPR, and so on and so on, and its continuous everything.
2. Within those business outcomes, which are limited, it’s decomposed into monthly features. They’re roughly monthly and they are vertical slices of value that are delivered. Some of these are experiments to test the business outcome.
3. Those are decomposed into stories. The stories are daily and will be what you will be doing in your iteration or single-piece flow. You have continuous delivery, continuous deployment for some teams. This business outcome is being delivered, potentially 100 times a day in tiny, tiny steps. Achieve big through small.
4. Then there is a need to group them. At the levels above, we group business outcomes into a portfolio epic. A portfolio epic is typically a calendar year, and it is a group of quarterly business outcomes. For example, in the US, Barclay Card is the credit card issuer for Uber. A business outcome for the first three months for Uber might be to do one transaction with one customer, for one journey. For the 12-month portfolio epic, it might be we’re going live with the Uber credit card, we’re issuing it in New York, LA, and San Francisco, and we’re going to have marketing, sales, everything. That could be the definition of a portfolio epic.
5. For large organizations, there are multiple portfolio epics. We might have some in the investment bank, or in Barclay Card, the retail bank, etc. As a large organization, there is also a need to group them. For example, a portfolio objective is a multiyear grouping of portfolio epics. This is where it gets into strategy now. The strategy here might be, we want to be the partner of choice for large companies who want to issue a credit card,” like Uber, like American Airlines, for example.
6. We have one final level of grouping which is another multi-year, strategic objective, the CEO’s top five priorities. Now you could be an individual on a product team doing a two-hour task, and you’ve got strategy alignment. You can see how your two-hour task aligns with the CEO’s top five priorities. At Barclays we have this in place, we have the tooling to support this, and we’ve got about 7,000 people who currently have this structure in place.

how do we map that to the long-lived products?

We view the long-lived products, the value streams as horizontal, and these are services.

For example, we might have anti-fraud, and we might have equity trading. Equity trading is further decomposed into some other services, for example, risk management, or market making.

Within those business services and given that organizations are a network of interdependent services, we have long-lived products and long-lived platforms.

We’re trying to get away from the days of projects, away from the days of build it, turn your back, build something new.

Now there should be no differentiation between greenfield and brownfield. Everything becomes green-brown field because it’s emergent. Everything is continuous. You’re upgrading your platforms, your products, your services from a biplane, to a propeller plane, to a jet plane, to a spacecraft.

We have long-lived teams that align with the long-lived products

You go through forming, storming, norming, performing, and you stay together. A Tuckman model. You end up staying together as a team. You begin to appreciate the unarticulated needs of the customer because these value streams are centered around the customer.

Then we map the work as you saw above, to that structure. Which gives us business outcomes on products and those business outcomes might be on one product, two products, three products, etc.

Over time, we try to decouple the structure of the organization to high cohesion, so that we don’t have too many dependencies.

Here’s a tip: break dependencies, don’t manage dependencies. We started out trying to manage dependencies, don’t. Break them.

That’s how the structure of work for all change that we do across Barclays.

here are five things to get you started

1. Identify your long-lived value streams and products. This takes time, you need to have the buy-in from the business service owners.
2. Once you’ve done that it helps you to identify what are your quarterly business outcomes?
3. That helps you to visualize your portfolio of work and start to limit your portfolio work in progress,
4. You focus on reducing your lead time to achieving the value.
5. Building agility and becoming an enabler helps us to be more agile on our delivery.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•