London 2018
Download Slides

The PMO is Dead, Long Live the PMO

Barclays started focusing on continuous improvement in enterprise-wide agility and DevOps in 2015. As per the Theory of Constraints, focusing on the biggest constraint to flow, we have been shifting left in the end to end value stream, into Portfolio Management and the PMO teams. In this talk, Jon and Morag will share experiences and lessons learnt on 'Lean Portfolio Management' and agility in the PMO.

"Sooner Safer Happier: Antipatterns and Patterns for Business Agility"

By Jon Smart (with Zsolt Berend, Myles Ogilvie, and Simon Rohrer)

—Learn more about the book here:


Jonathan Smart

Head of Working Ways, Barclays


Morag McCall

Investment Bank Portfolio Management, Barclays



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 to perfect itself. Over the years, I've come to tremendous respect and admire how savvy is at introducing different ways of working that improves the lives of not just developers, but also business stakeholders, QA 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 him 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 more McCall Barclays, international portfolio management, where among other things, she was responsible for risk and governance objectives. So I'll come on out, John and Maureen.


Good morning. So my name's Jonathan smart. I'm head of ways of working at Barclays.


Hi, I'm more AGMA called. I also work at Barclays and portfolio management team, and I'm responsible for risk and governance.


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 or the very first is 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 gene was going to talk about Coulter 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. That 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.


So 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 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. So you've got 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, this context is relevant to this talk in terms of timeline, pre 2014, we had islands of agile islands of agile and dev ops. 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 dev ops. And in 2012 we created, 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. 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, who would give up their evenings and weekends and work extra hours to participate in an agile community of practice. We are 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 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 dev ops. It's about what business outcomes are you trying to achieve? One of which is survival, better products, faster, safer, happier 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, oh, awesome job. You know, Hey John, we've halved our lead time, high five fantastic job. And they do 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 all need to deploy, be deployed together. So we have to wait for integration. Okay. So when you've done integration testing, and you then good, 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?


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. Acceptance. Testing is quarterly and releasing is quarterly because it's hard. So we do it less often and more ag. What happens prior to the work, getting to the dev team?


Yes. So before it gets on to the dev backlog, then there's a product backlog. So this is analysis that needs to happen, needs to be prioritized and the product backlog. And then before it gets onto 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 idea's charge. And then if we look to see what's the cadence, what's the frequency of these things? Well, the idea triaged might be monthly and you write like business case and steering that might be quarterly, but with annual funding approval, detailed business case might be annual. So it's taken quite a long time, John.


Yeah, but it speaks to the dev teams and they say, we're so freaking out job. Yay.


This isn't far faced


High five bugs customer, customer needs identified to customer needs met. Now this agile thing, this DevOps thing, I'm not seeing it. And this is, I've heard this multiple times in the organization. Well, you've said that agile would fix everything and dev ops 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, that'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.


It's gotta be why isn't it done already? You 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 to 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, I'm going to build on this and articulate some other anti-patterns that we have seen over time. So 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 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.


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 cam. So, 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-pattern three it's 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 dropped 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 and waiting for some more work to do. And again, we have that 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. 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 summit. And now we're shifting left and now we're looking at portfolio management and PMO. So the 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 heartworm, interesting path, half to 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 a scientific as the, 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, PMO should not exist. They're not needed 40% of people.


PMO support leaders and teams, 50% of people, PMOs plan and allocate work, 60%, sorry, 6% of people said that 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. Alright, what's your view?


It doesn't really surprise me. John. 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. I'd already, I've also set up a PMO function. And if he was at, 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 their anti-patterns that John has taken us through, the perception might be, go ahead though, do DevOps, but we're the PMO. We want things to stay the same, keep doing your rag. Stacy's keep providing your Gantt charts, keep doing your predictive milestones so long as nothing changes. So is it, is that really the only way, or is there an alternative perhaps perhaps a reasonable alternative, but perhaps not the PMO that you expected is over. 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 in 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 dev ops can enable foster delivery within an organization.


So the next organization, it was that 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, oh, 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 and how in an agile environment, it would be 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 the portfolio management team John's team, as he's told you a big, big focus and emphasis on agile dev ops, but the PMO, then we're still very much for the tumbleweeds.


Still very much being project centric, illustrating some of those anti-patterns that John to Castro. 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 that the cliff, the totally is, we knew that we had a significant transformational change. The, 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 John's team, where we had a coach, an agile coach working with those in the team to help us build up from basics.


So that within the portfolio management team, we've built understanding and knowledge, starting with the basics and building a sprung 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 two minutes so that we've got virtual visibility of our weekly sprints in our backlog and 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 thing. People were talking too much in the stand-ups and then if people were not attending or failing to attend the ceremonies, we use poo emojis for that.


So what next chapter two, we call the age of enlightenment. And this is very much working with John's team and working with the various product teams, pivoting to the concept of long lived products as 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, with 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 you actually lived until it was 900 years old. Look, we've maybe got 899 years to go. Um, so with BB 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 John went through earlier, but limiting what's in progress. We focus on the strategic objectives that senior management want to see progress on. We start finishing, we stopped 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, essentially under PMOs to be more advisory consultative and supporting our PMOs work with the value strings. 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.


Thank you, mark. So in terms of how we organize the work, so more 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're using in Barclays. The 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 where 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 worked for our control, our GRC, our compliance conversations, conversation around information, security, information, risk management, GDPR, and so on and so on.


And it's continuous. Everything it's just 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 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


And for larger organizations, there is a need to group them. So at the levels above we grouped 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 U S Barclay card or the card issuer, the credit card issue 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 going to have marketing and we're going to have sales going to have everything that could be the definition of the portfolio, epic and for larger 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 larger 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, when I went to were welling to 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 CEOs 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.


You can see how your two hour task aligns up to one of the CEOs, top five priorities. And this is, we have this in place. We have the tooling to support this. We're doing this, 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 more ag 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, to space craft. So, and we have long lived teams aligned to the long lip 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'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 high cohesion, low coupling, so that we try to not have too many dependencies, a tip, the break dependencies don't manage dependencies. We started out trying to manage dependencies, don't break them. So that's our, 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, 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 as per that previous diagram, it's both, it's about both of 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 two examples, it's moving from being controlling to advisory less checkboxy to advisory, moving from predictive milestones to that ruling 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 and can flow. We still have reporting status, but the focus has shifted. So we're focusing on the outcomes of benefits and the learning from those. And instead of gated reviews, we've 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 project management office. So here's five things to get. You started identify your long live 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 to portfolio work and progress. And you focus on reducing your lead time to achieving the value. So building agility become an enabler with the help of teams like John and John's team helps us to be more agile on our delivery.


So Jean 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 us, the speaker, and it will be us asking you, thank you.