Inspire, develop, and guide a winning organization.
Create visible workflows to achieve well-architected software.
Understand and use meaningful data to measure success.
Integrate and automate quality, security, and compliance into daily work.
Understand the unique values and behaviors of a successful organization.
LLMs and Generative AI in the enterprise.
An on-demand learning experience from the people who brought you The Phoenix Project, Team Topologies, Accelerate, and more.
Learn how making work visible, value stream management, and flow metrics can affect change in your organization.
Clarify team interactions for fast flow using simple sense-making approaches and tools.
Multiple award-winning CTO, researcher, and bestselling author Gene Kim hosts enterprise technology and business leaders.
In the first part of this two-part episode of The Idealcast, Gene Kim speaks with Dr. Ron Westrum, Emeritus Professor of Sociology at Eastern Michigan University.
In the first episode of Season 2 of The Idealcast, Gene Kim speaks with Admiral John Richardson, who served as Chief of Naval Operations for four years.
New half-day virtual events with live watch parties worldwide!
DevOps best practices, case studies, organizational change, ways of working, and the latest thinking affecting business and technology leadership.
Is slowify a real word?
Could right fit help talent discover more meaning and satisfaction at work and help companies find lost productivity?
The values and philosophies that frame the processes, procedures, and practices of DevOps.
This post presents the four key metrics to measure software delivery performance.
September 5, 2018
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.
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.
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.”
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.
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.
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.
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.
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.
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.
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.
Now let’s look in terms of how we all organize the work.
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.
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.
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.
No comments found
Your email address will not be published.
First Name Last Name
Δ
We had an amazing conference in Las Vegas this August — I learned so…
Quiet down, everyone. It’s pop quiz time! But don’t worry—there are only two questions;…
Organizational transformation is more than just a buzzword—it's a necessity for survival and growth.…
In recent years, the concept of minimum viable product (MVP) has gained widespread adoption…