Jonathan Smart

Good morning.

My name's Jonathan Smart. I'm head of Ways of Working at Barclays.

Morag McCall

Hi, I'm Morag McCall. I also work at Barclays in the portfolio management team, and I'm responsible for risk and governance.

Jonathan Smart

Our talk, as Gene said, is on the topic of "The PMO is Dead, Long Live the PMO."

I think this is very good timing for this topic. Obviously, this title takes inspiration from "The King is Dead, Long Live the King." And today, 26th of June, 2018, General Electric are leaving the Dow Jones Index.

General Electric is the last remaining original constituent of the Dow Jones Index. In 1896, the index was created. Today, they leave the index.

And it's fascinating that Gene spoke about Carlota Perez because I was planning to do exactly the same thing, and I didn't know Gene was going to talk about Carlota Perez. So we really are, today, in the inflection point. We are in the turning point.

Today, GE is no longer in the Dow Jones Index. GE, 15 years ago, 2003, was the number one company for market capitalization in the world. Fifteen years ago.

GE was still in the top 10 two years ago. So the DevOps Enterprise Summit had already been running since 2014, but GE was still in the top 10 only two years ago. They're no longer in the top 10, and they're no longer in the Dow Jones Index.

So we are living a turning point right here, right now, and all of you are on the right side of the change.

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, not far from here, 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 billion pounds. We have 48 million customers. Every day, we process 30% of the annual UK gross domestic product. So that's 600 billion pounds a day 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. So what's that? About four minutes, four times... So we've had about 12 production changes just since I've been talking. And we have eight million hits a day on our artifact repository.

And so this context is relevant to this talk.

In terms of timeline, pre-2014, we had islands of Agile and DevOps, and that island says "help" written on it. And I was running one of those islands of Agile, and I had a pretty good idea who else was running other islands of Agile and DevOps.

And in 2012, we started creating a number of communities of practice. The Agile community of practice grew to be the biggest, with 2,500 people, and this was done entirely voluntarily. Nobody asked anybody to create this community of practice. Nobody asked anybody to participate. These are the people who would give up their evenings and weekends and work extra hours to participate in an Agile community of practice, and we had 2,500 people.

In 2014, we spoke at the first DevOps Enterprise Summit on scaling DevOps.

In 2015, we started our enterprise-wide organizational agility initiative, which is what I'm leading.

In 2016, we spoke on scaling agility at the DevOps Enterprise Summit.

In 2017, we spoke on speed and control. And also in 2017, we pivoted how we frame what we do in the organization. So previously, I was running the Agile adoption team, the Agile COE. Then we pivoted to better products faster, safer, happier. Because it isn't about Agile for the sake of Agile or DevOps for the sake of DevOps. It's about what business outcomes are you trying to achieve, one of which is survival.

Better products faster, safer, happier, and that describes what we do.

And then in 2018, so DevOps Enterprise Summit 2018, we're talking about lean portfolio management and what's the role of the PMO in an Agile organization?

So in my role, wind the clock back two or three years, and I'm speaking to development teams. And they're increasing their agility, and I'll have a chat with them, and it's like, "Awesome job. Hey, Jon, we've halved our lead time. High five. Fantastic job." And they're doing a great job, especially compared to how teams used to work.

So then I'll say, "Well, so is there anything else that you need to do after dev done and test done to get it into production?"

And it's, "Well, yes, we need to wait for integration testing because we've got lots of dependencies. We haven't decoupled the architecture. 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? You're 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?"

"Well, actually, yes, because we batch up releases. Because releasing is hard, so we do it less often. 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?"

"Well, 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 again, this is going back two or three years.

"Well, integration testing is monthly. And acceptance testing is quarterly, and releasing is quarterly because it's hard, so we do it less often."

Morag, what happens prior to the work getting to the dev team?

Morag McCall

Yes. So before it gets onto the dev backlog, then there's a product backlog. So there's analysis that needs to happen, needs to be prioritized in the product backlog.

But then before it gets onto the product backlog, there's a detailed business case, and that needs to wait for approval. Before the detailed 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.

And then if we look to see, well, what's the cadence, what's the frequency of these things? Well, the ideas triage might be monthly, and your outline business case and steering, that might be quarterly. But with annual funding approval, detailed business case might be annual.

So it's taking quite a long time, Jon.

Jonathan Smart

Yeah. But you speak to the dev teams, and they say, "We're so freaking Agile. Yay! This is fast-paced. High five."

But customer needs identified to customer needs met? No, this Agile thing, this DevOps thing, I'm not seeing it.

And I've heard this multiple times in the organization. "Well, you said that Agile would fix everything and DevOps would fix everything." No. Not seeing it. Still taking just as long.

So this is perhaps not the best for end-to-end performance.

And another observation is when the work is in that fuzzy front end, when the work is in portfolio management, it's in that backlog, it's sitting there for 18 months or 24 months or longer. And so theoretically, it's not urgent.

As soon as it hits the dev team, it's urgent. "Why isn't it done already? God, IT, you take too long. You can't move as fast as the business." But actually, who's prioritizing the work on the left? Typically, it's your business partner, our business, collectively.

So you end up with this urgency paradox: fuzzy front end, take our time, and then all of a sudden, it's got to be done. So then that leads to unsustainable working, even when teams are working with more modern ways of working.

So I'm going to build on this and articulate some other anti-patterns that we have seen over time.

This anti-pattern is over-committing. And in this anti-pattern, you keep saying yes to the customer. You don't really know what your throughput is. You don't really know what you can achieve in your system. So you keep on saying yes to the customer, and you keep committing to the customer, who could be internal or external. And so all the work backs up. It all backs up like this, so every month, the backlog of work is growing by another month.

A second anti-pattern is starvation and overproduction, which sounds like an oxymoron.

So with starvation and overproduction, the portfolio management process or the financial process is not sending any more work down the pipeline. So as a product team, you're starved of work. But unlike physical manufacturing, where the downstream machines cannot produce any more goods, humans can.

So what happens is the humans, especially Agile teams, have got this cadence running, coming up with your stories, grooming the backlog. And actually, you start creating fake work, and you end up with a feature factory.

And I've seen this happen often as well, and I've heard stories from other companies where this happens. So you get this feature factory of the work still coming off the assembly line, and you go back to a problem that we used to have in the traditional world, where 75% of software features are never used. People keep producing stuff disconnected from the strategic focus of the firm.

Now, there are some contexts where this can work. There are some contexts, in a smaller context, more self-contained, this can be okay. Generally, in a large complex org, this is generally on the whole not okay, in my experience.

Anti-pattern three is feast and famine.

So in feast and famine, what's happening is we have a great big batch of work coming down the stream. And again, this could be because of portfolio management processes, it could be the steering committee, it could be the approval process, it could be the financial process.

So poor team throwing their arms up in despair, or arm, otherwise he'd drop his laptop, sweating. And then we have unsustainable working.

And then there's famine. Then there's nothing. Then there's fake busy. "Actually, I don't really have anything to do. I'm waiting for some more work to do." And again, we have this previous anti-pattern. Maybe there's some feature factory stuff going on.

And then we have feast again, where the next big chunk of work comes down the pipe. So this is not sustainable flow.

And as an organization, as per the theory of constraints, focus on your biggest constraint. For us, we've done a lot of work at the beginning around our continuous delivery life cycle. That was one of our biggest impediments at the beginning. So we focused on our continuous delivery life cycle, which I've spoken about in previous DevOps Enterprise Summits.

And now we're shifting left, and now we're looking at portfolio management and PMO.

So, a question: is there a role for a PMO in a large, Agile organization?

I'd like a show of hands. If you think there is a role for a PMO in a large, Agile organization, please put your hand up.

Okay. That's about 50%, I think. Roughly half. Interesting. Half, half. So half of you at the DevOps Enterprise Summit think there should be a PMO, and about half of you think there shouldn't. Interesting.

So we asked Twitter. This is highly scientific. This is almost as scientific as the State of DevOps Report. Not. Which is super scientific. So this is absolutely not as scientific as that.

We asked, "What do you think the role of a PMO is in a large, Agile organization?" And Twitter said, "PMOs should not exist. They're not needed," 40% of people. "PMOs support leaders and teams," 50% of people. "PMOs plan and allocate work," 6% of people. PMOs are Taylorist command-and-control constructs, and 4% of people thought "other." Not quite sure what they were thinking, but anyway.

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

Morag, what's your view?

Morag McCall

It doesn't really surprise me, Jon. I've got some personal experience with this nature.

A few years ago, I was a program manager in a large financial services organization. Senior management wanted to go Agile, wanted to be able to deliver faster. A number of consultancies were brought in to assist in this, and it was a big, big push to switch to an Agile environment.

And the view was, "Well, we don't need project managers, program managers." They'd also set up a PMO function, and the view was that they were impediments. And as a result, I was made redundant.

So I know from experience that there are the views out there. And as we can see from the anti-patterns that Jon has taken us through, the perception might be, "Go ahead then. Do DevOps. But with a PMO, we want things to stay the same. Keep doing your RACIs, keep providing your Gantt charts, keep doing your predictive milestones, so long as nothing changes."

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

Perhaps. Well, perhaps there is an alternative, but perhaps not the PMO that you expected.

So if we go back to my own experience, after I was made redundant, to be honest, I didn't get Agile then, or DevOps. I was used to working in a very waterfall environment.

And the next role that I took, I was heading up the portfolio management team. But I knew I needed to get better understanding of how Agile and DevOps can enable faster delivery within an organization.

So the next organization I was at, there was a big push, again, being pushed more from the dev community to deliver Agile. But 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, all to receive training and become more knowledgeable and understanding of how Agile can work.

I was able to work with the project managers to help them and advise them on how, in an Agile environment, they 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, Jon's team, as he's told you, were a big focus and emphasis on Agile and on DevOps. But the PMO then was still very much with the tumbleweed, still very much being project-centric, illustrating some of those anti-patterns that Jon took us through.

So we knew that we needed to change, and we were on a path and a journey to achieve that.

So what did we do?

Well, first chapter in the unfolding story: 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. So 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, and this was with the help of Jon's team, where we had a coach, 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. An Agile coach acted as the scrum master.

And we were able to start physical at first: lots and lots of Post-its and boards. And then as we grew, we're now over five global time zones, introduced the use of tooling so that we've got virtual visibility of our weekly sprints and our backlog, improve the way we deliver stuff and be able to deliver improvements faster on the way we work, and change the way we organized as a team.

So 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 or failing to attend the ceremonies, we used poo emojis for that.

So what next?

Chapter two, we call the Age of Enlightenment. And this was very much working with Jon's team and working with the various product teams, pivoting to the concept of long-lived products as the advent of the value stream. Jon's going to talk more about that in his next few slides.

But essentially, products deliver one or more business services. So we were shifting from a project-centric view to a product-centered view.

And the values of long-lived product teams enabled us to look at how we optimize our portfolio to fewer programs to focus on the strategic objectives, which were what senior management wanted to have visibility of.

Overall enablers with Jon's team's coaching, use of Lean control tools, the long-lived product teams themselves being an enabler to helping us to achieve that.

So we move to chapter three, the next step we've called the Yoda Years.

We're not Jedi Masters yet. Yoda actually lived until he was 900 years old, though we've maybe got 899 years to go, so we're baby Yoda.

But we have seen a change. We have seen a change. We have limited the portfolio of work in progress, and this is about flow, some of the slides that Jon went through earlier. By limiting what's in progress, we focus on the strategic objectives that senior management want to see progress on.

We start finishing. We stop starting.

And we shift our focus to outcomes and value rather than output and activity. So we're not looking at predictive milestones. We're focusing on the concept of business outcomes.

And this allows us, as a team centrally, and our PMOs to be more advisory, consultative, and supporting. 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 to the programs.

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

Jon.

Jonathan Smart

Thank you, Morag.

So in terms of how we organize the work, Morag spoke about limiting portfolio work in progress and about outcomes. So the key unit of work is a business outcome. These are the terminologies that we're using in Barclays.

A business outcome is three months. It's a quarter. And if it isn't regulatory and mandatory, it's written as a hypothesis. So 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, and it needn't be financial. It should be about obsessing about the customer. It could be social. It could be corporate social responsibility.

And so this is the main unit of work, and this is also the unit of work for our control, our GRC, our compliance conversations, conversation around information security, information risk management, GDPR, and so on. And it's continuous everything. It is continuous. It's just rolling wave quarterly planning with continuous everything.

Within those business outcomes, which are limited, you can see there's only two on the screen. So per value stream, limit it to two, three, or four business outcomes.

That's decomposed into monthly features. They're roughly monthly, and they are vertical slices of value that are delivered. Some of them are experiments to test the hypothesis, which is the business outcome.

Those are decomposed into stories. The stories are daily. So that will be what you will be doing in your iteration or single-piece flow. And you have continuous delivery, continuous deployment for some teams.

So this business outcome is being delivered potentially 100 times a day in tiny steps. Achieve big through small.

And for large organizations, there is a need to group them. So at the levels above, we group business outcomes into a portfolio epic. And a portfolio epic typically is a calendar year, and it is a group of quarterly business outcomes.

So for example, in the US, Barclaycard are the card issuer, the credit card issuer for Uber. So a business outcome for the first three months for Uber might be to do one transaction with one customer for one journey, and that's it.

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 and LA and San Francisco, and we're going to have marketing, we're going to have sales, we're going to have everything. That could be the definition of the portfolio epic.

And for large organizations, that's not going to be the only portfolio epic you have. So there are multiple portfolio epics, and we might have some in the investment bank, we might have some in Barclaycard, we might have some in the retail bank.

And as a large organization, there's a need to group them. So for example, a portfolio objective is the grouping of portfolio epics, and that will be multi-year. So this is to do with strategy now. We're well into strategy.

So 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.

And we have one final level of grouping, which is a strategic objective, which also is multi-year. And this is the CEO's top five priorities.

So 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 up to one of the CEO's top five priorities.

And we have this in place. We have the tooling to support this. We're doing this. We've got about 7,000 people who currently have this structure in place.

So then how do we map that to the long-lived products that Morag spoke about?

So we view the long-lived products, the value streams, as horizontal, which should come as no surprise. And these are services.

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

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

So we're trying to get away from the days of projects, away from the days of build it, turn your back, build something new, turn your back, build something new, slash and burn, build it again.

So now there should be no differentiation between greenfield and brownfield. Everything becomes green-brownfield because it's emergent. Everything is emergent, continuous everything.

So you're upgrading your platforms, your products, your services from a biplane to a propeller plane to a jet plane to a spacecraft. I don't know.

And we have long-lived teams aligned to the long-lived products. So you can see on the screen that we have Team Alpha, Team Bravo, Team Charlie. So you go through forming, storming, norming, performing, and you stay together, the Tuckman model. So you end up staying together as a team, and you get to appreciate the unarticulated needs of the customer because these value streams are centered around the customer.

And then we map the work, which I ran through on the previous slide, to that structure. So then we'll have business outcomes on products. And those business outcomes might be on one product. They might be on two products. They might be on three products.

Over time, we try to decouple the structure of the organization to high cohesion, low coupling, so that we try to not have too many dependencies.

A tip: break dependencies, don't manage dependencies. We started out trying to manage dependencies. Don't. Break them.

So that's our structure of work for everything that we do, all change that we do across Barclays.

Finance. So finance, like PMO, can be an enabler, can be an inhibitor. We're very early on the journey with finance. We still have a lot of work to do.

In terms of some things that we've done so far, quarterly rolling wave outcomes significantly enables financial agility. We have some value stream capacity funding, so as per that previous diagram, it's about both the vertical and the horizontal, not one or the other. And we do have some horizontals that are capacity funded to maximize the value on the funding.

We have a lightweight business case, so there's no need to fill out a detailed business case to get funding. You can start experimenting sooner.

And procurement have adopted Agile ways of working.

So behaviors that we need to see, from and to, examples.

It's moving from being controlling to advisory, less checkboxy to advisory. Moving from predicted milestones to that rolling wave outcome roadmap, your quarterly outcomes. Moving from a project-centric view to product-centric view.

We still have programs grouped into initiatives. So instead of thousands of projects, we keep a limited portfolio of what's in progress. Think of the flow.

We still have reporting status, but the focus has shifted, so we're focusing on the outcomes, the benefits, and the learning from those. And instead of gated reviews, we're moving to continuous engagement.

So key message. Portfolio project management office. Well, I think there is still a role for a group of people in an organization. Could be called the value instead of project management office.

So here's five things to get you started.

Identify your long-lived value streams and products. This takes time. You need to have the buy-in from the business, the business service owners.

Once you've done that, it helps you to identify what are your quarterly business outcomes. That helps you to visualize your portfolio of work and start to limit your portfolio work in progress.

And you focus on reducing your lead time to achieving the value.

Morag McCall

So building agility, become an enabler. With the help of teams like Jon and Jon's team, helps us to be more Agile on our delivery.

Jonathan Smart

So Gene has created a fantastic, mutually exothermic community, and so we would like to hear your stories about portfolio agility, reinvention of the PMO, and reinvention of finance.

So if any of you have done it and you've got stories you'd like to share, please come to Ask the Speaker, and it'll be us asking you.

Thank you.

Morag McCall

Thank you.

Jonathan Smart

Awesome.