00:00:03

Jonathan Smart is the head of ways of working at Barclays. Uh, he's spoken at every DevOps Enterprise summit that we've had here in the uk. I fed him, I first met him in 2016 when we were organizing our first UK conference, and he apparently had a reputation of doing things in his group that were very different than traditional norms inside of an organization, uh, at Barclays, which has probably one of the most highly evolved bureaucracies on the planet, evolving over centuries, uh, to perfect itself. Over the years, I've come to tremendously respect and admire how savvy he is at introducing different ways of working that improves the lives of not just developers, but also business stakeholders, QOA and operations. His presentation last year included the work they did on Lean portfolio management, which changed the way they allocate capital and release capital to software teams. This year we asked them to share more about that part of the journey, specifically about how he changed the interactions with the project management office, which is probably one of the most powerful orthodoxies in modern enterprises. So, uh, we were delighted that he would is also presenting with Morag McCall, Barclay's International Portfolio Management, where among other things she's responsible for go risk and governance objectives. So, uh, come on out, John and Morag.

00:01:21

Good morning.

00:01:23

Morning. Morning.

00:01:25

Um, so my name's Jonathan Smart. Um, I'm head of ways of working at Barclays.

00:01:31

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

00:01:38

So our talk, as Jean said, is on the topic of the PMO is dead long live, the PMO, and 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 are the very first, the last remaining original constituent of the Dow Jones Index 1896. The index was created. Today they leave the index and it's fascinating that Jean spoke about Carlotta Perez because I was planning to do exactly the same thing and I didn't know Jean was gonna talk about Carlotta 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 in 2015 years ago, 2003 was the number one company for market capitalization in the world. 15 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, we are living a turning point right here, right now, and all of you are on the right side of the change.

00:03:18

So a bit of context. Barclays is a financial services firm. We're a universal bank. Um, 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 600 billion pounds 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 3000 change initiatives running. We have a production change every 18 seconds. So what's that? About four minutes, four times. We've had about 12 production changes just since I've been talking. And we have 8 million hits a day on our artifact repository. And so this, uh, this context is relevant to this talk in terms of timeline. Pre 2014, we had islands of agile, 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 created, we started creating a number of communities of practice.

00:05:11

The agile community of practice grew to be the biggest with two and a half thousand people. And this was done entirely voluntary. Nobody asked anybody to create this community of practice. Nobody asked anybody to participate. This is, these are the people who would, you know, who would give up their evenings and weekends and work extra hours to participate in an agile community of practice. And we had two and a half thousand 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, and 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,

00:06:35

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

00:06:47

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, oh, awesome job. You know, Hey John, 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.

00:07:10

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 deploy, be deployed together. So we have to wait for integration. Okay, so when you've done integration testing, you're 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? Uh, 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? Um, 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.

00:08:10

Well, integration testing is monthly. Acceptance testing is quarterly, and releasing is quarterly because it's hard. So we do it less often. And Morag, what happens prior to the work getting to the dev team?

00:08:25

Yes. So before it gets onto the dev backlog, then there's a product backlog. So there's analysis that needs to happen. It 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 outlying business case, which needs to go to steering. And before you get to an outlying 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 idea triage might be monthly and your right line business case and steering, that might be quarterly, but with annual funding approval, detailed business case might be annual. So, uh, it's taken quite a long time, John.

00:09:21

Yeah. Uh, but he speaks to the dev teams and they say, we're so freaking agile. Yay <laugh>.

00:09:28

This isn't bar case

00:09:32

High five, but customer, customer needs identified to customer needs met. Nah, this agile thing, this DevOps thing, I'm not seeing it. Um, and this is, I've heard this multiple times in the organization. Well, you, you said that Agile would fix everything and DevOps would fix everything. No, I'm not seeing it still taking just as long. Um, 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

00:10:21

<laugh>,

00:10:24

It's gotta be, why isn't it done already? Go it, you take too long, you can't move as fast as the business. But actually who's, 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 gotta 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, I'm gonna build on this and articulate some other anti-patterns that we have seen over time. So this anti-pattern is overcommitting. And in this anti-pattern, you keep saying yes to the customer. Um, you don't really know what your throughput is, you don't really know, uh, your, 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 are starved of work, but unlike physical manufacturing where the downstream machines cannot produce any more goods, humans can.

00:11:57

So you know, so an evolution of the goal is what happens is the humans, especially agile teams, got this cadence running, coming up 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, you have 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 horse. This is generally on the whole not okay in my experience, anti-patent 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, um, sweating. Um, and then we have unsustainable working

00:13:22

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 that this previous anti-pattern, maybe there's some feature factory stuff going on. Um, 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 lifecycle. That was one of our biggest impediments at the beginning. So we focused on our continuous delivery lifecycle, 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.

00:14:15

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. Okay. That's about 50% I think roughly half. Well 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. 60%, sorry, 6% of people said that PMOs are taylorist commander control constructs. And 4% of people thought other, not quite sure what they were thinking. But anyway, um, and it really surprised me that 40% of people thought A PMO should not exist at all in a large agile organization.

00:15:42

Alright, what's your view? Oh,

00:15:44

It doesn't really surprise me, John. I've got 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, wanted to be able to deliver faster. Uh, a number of, uh, 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. I'd already, I'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 antipas that John has taken us through, the perception might be, go ahead though, do DevOps. But with the PMO, we want things to stay the same. Keep doing your rag stasis, keep providing your Gantt charts, keep doing your predictive milestones as long as nothing changes. So is it, is that really the only way or is there an alternative

00:17:07

Perhaps <laugh>? 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, waterfall environment. And the next role that I took, I was heading up the portfolio management team. I knew I needed to get better understanding of how agile 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.

00:18:14

And I was able to work with the project managers to help them and advise them on how in an agile environment they would be still be able to demonstrate progress through delivery and achievement of value. So jump forward, and I started at Barclays about nearly three years ago. And at the time when I started in the portfolio management team, John's team, as he is told you, a big, 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 antipas that John took us through. So we knew that we, 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 took the, the toddler years. We knew that we had a significant transformational change in our ways of working, both essentially in the portfolio management team, but for the PMOs working with the programs.

00:19:37

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 John'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 agile coach, act 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 use of tooling so that we've got virtual visibility of our weekly sprints in our backlog. Um, 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 standups. And then if people were not attending or feeling to attend the ceremonies, we use poo emojis for that.

00:21:09

So what next Chapter two, we call the age of enlightenment. And this was very much working with John's team and working with the various product teams. Pivoting to the concept of long lived products is the advent of the value stream. John's going to talk more about that in his next few slides. Um, but essentially products deliver one or more business services. So we were shifting from a project centric view to 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 John's team's, coaching, use of link control tools, uh, the long lived product teams themselves being an enabler to helping us to achieve that. So we moved 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. <laugh> though we've maybe got 899 years to go. Um, 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 John went through earlier. But limiting what's in progress, we focus on the strategic objectives that senior management want to see progress on son.

00:23:00

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

00:24:01

Thank you Morag. So in terms of how we organize the work, so Morag spoke about limiting portfolio work in progress and about outcomes. So the key unit of work is a business outcome. This is the, these are the terminologies that we are 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 unit of, this is the main unit of work. And this is also the unit of work, work for our control, our GRC, our compliance conversations, conversation around information security, information risk management, GDPR and so on and so on.

00:25:00

And it's continuous everything. This 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, limited 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, 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, and you have continuous delivery, continuous deployment for some teams. So this business outcome is being delivered potentially a hundred times a day in tiny, tiny steps achieve big through small.

00:25:58

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, uh, in the US Barclay card 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 with 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 gonna have marketing, we're gonna have sales, we're gonna have everything. That could be the definition of the portfolio epic.

00:26:47

And for large organizations, that's not gonna 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 Barclay card, 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 now into, 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 a, an individual on a product team doing a two hour task, and you've got strategy alignment.

00:27:50

You can see how your two hour task aligns up to one of the CEOs top five priorities. And uh, and this is, we have this in place. We have the tooling to support this. We're doing this, uh, we've got about 7,000 people who are 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. Um, 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.

00:29:00

So now there should be no differentiation between greenfield and Brownfield. Everything becomes green brownfield because you are, 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, to a spacecraft, I don't know. Um, so and, 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 a tuckman model. So you end up staying together as a team and you get to, um, appreciate the unarticulated needs of the customer because these value streams are centered around the customer. And then we map the work, which I've 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, uh, high cohesion, low coupling so that we try to not have too many dependencies. Uh, uh, a tip, the brake dependencies don't manage dependencies. We started out trying to manage dependencies, don't break them.

00:30:25

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

00:30:32

Finance. So finance like PMO can be an enabler, can be an inhibitor. Uh, we're very early on the journey with finance. We still have a lot of work to do. Um, in terms of some, some things that we've done so far. Quarterly rolling wave outcomes significantly enables financial agility. We have some value stream capacity funding. So it's, uh, as per that previous diagram, it's both. 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, um, 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.

00:31:20

So behaviors that we need to see from. And two examples, it's moving from being controlling to advisory, less checkboxy to advisory, moving from predictive milestones to that rolling wave outcome roadmap, your quarterly outcomes. Moving from a project centric view to product centric view, we have, 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 and benefits in 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 in 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. So building agility, becoming an enabler with the help of teams like John, um, and John's team helps us to be more agile on our delivery.

00:33:08

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. Um, and it'll be us asking you. Thank you.

00:33:31

Thank.