Jonathan Smart

My name's Jonathan Smart. I'm leading on ways of working at Barclays.

I love this event. For me, this is the highlight of the year, because this is big, old, complex companies talking about transformation. This really is the highlight of the year for me, and a big thanks to Gene Kim and team for organizing it.

So, big, old, and complex. Barclays is 327 years old, founded in 1690, not far from here, four years before the Bank of England existed. We've got 120,000 staff in 40 countries, and we have 29,000 staff in technology. We've been on an organization-wide transformation since the beginning of 2015, so we're two and a half years in.

First of all, I'd like to start with a short video. These are real people at Barclays sharing some of their thoughts and experiences.

Boost has reduced onboarding lead time for private banking, business banking, corporate, and premier global clients by five months and slashed business costs.

Collaboration is at the heart of our work as we work closely with the business and customers. These are SMEs in the business and control functions. We work with continuous UAT, collaborating together.

The check imaging program is one that demands that banks move from paper checks to digital images. We managed to do this and trial a year ahead of the regulators' deadlines, winning three awards for our check imaging tool along the way.

We shifted from a traditional waterfall approach mid-project, setting up eight Pune-based feature teams and a UK product team. We wanted to make Agile a program-wide approach, from how we dealt with customer trials to the architecture and business teams. We wouldn't have delivered the quality we did at the pace we did without trying new approaches.

A key first step for us was to reduce the time and complexity involved in each of our typical work phases. So whether it's audit planning, fieldwork, or reporting, we're actively engaging stakeholders, and now we're removing blockers in days rather than weeks. Together, we've worked on the key people-first principle and have moved from a largely introspective function to one that's visualizing its work, working iteratively, and removing boundaries and barriers.

The first thing we did is we co-located our people. By doing that, we broke down silos. We brought together a team that was responsible for building the whole car, not just the constituent parts of doing it.

The second thing is we ripped up the Gantt charts, and we focused much more on a time-boxed approach to delivering software in shorter time periods in order for us to inspect and adapt more frequently. As a result, what we feel we're doing is working together in a much more efficient way, and we're realizing the outcome much sooner.

So, as you've seen there, our approach is not only in technology. It's firm-wide. You heard there from internal audit, who've adopted Agile ways of working to how they run audits, nothing to do with technology, and you heard from the business, equity electronics trading. So our scope is across the whole organization.

I'm going to share some lessons learned. So if I could go back in time to the beginning of 2015 and share some stories to myself and share some learnings, these are the things that I would go back and tell myself. And for those of you on a similar journey, hopefully you'll find something useful here.

I'm then going to talk about speed and control, and some work that we've done to balance both speed and control.

So first of all, on lessons learned. When we started in 2015, me and my team, we were called the Agile Adoption team. We've changed our name. We're no longer the Agile Adoption team. We are the Better Products Faster team.

When you start out, there's natural champions, and the A word, the Agile word, you attract the natural champions. But as you get through past the early majority into the late majority and the laggards, the A word comes with some baggage, and it comes with some barriers to adoption. It can come across as the Church of Agile. It can come across as cultish.

So Better Products Faster, you can't argue with. Whether you're waterfall or Agile, there are things that you can do to deliver better products faster, be it Agile, be it Lean, be it DevOps, be it Lean UX. There's lots of tools in the toolbox to apply to deliver better products faster. So this is the name of our team across Barclays Group. We're the Better Products Faster team.

The full expression is Better Products Faster, Safer, Happier. This is our tagline. This is the very short elevator ride pitch: Better Products Faster, Safer, Happier. Better, higher quality. Faster, shorter lead time, faster feedback. Safer, within control. As I'm going to talk about, we are operating in the most regulated industry in financial services, so it absolutely has to be control first, as British Airways have seen. And happier as well, so higher colleague engagement and higher customer happiness, net promoter score. So it's better products, faster, safer, happier.

But then thinking about this a bit more, and some recent conversations, it's actually from productivity to valuetivity. Obviously, valuetivity is a made-up word, but it isn't just productivity. Because when you look at the definition of productivity, productivity is producing more output for the same input. Obviously, it isn't just about output. It isn't just about churning something out, because we can produce rubbish quicker. And it isn't about producing rubbish quicker or carrying on to produce something very quickly when it isn't the thing that the customer wants.

So actually, it's better value faster. It's better value faster, safer, and happier. And this is what I would go back and tell myself two and a half years ago: focus on quality, value, speed, control, and happiness.

And to quote Peter Drucker, "There's nothing so useless as doing efficiently that which should not be done at all."

So there's a real focus here, and our focus is on two things: doing the right thing and doing the thing right, and constantly questioning those two things. Are we doing the right thing, and are we doing it right?

The second learning is whole enterprise agility. So as you heard in that video, internal audit have done a great job in adopting Agile principles and practices. They visualize their work. They have short iterations for audit reports. They have multidisciplinary teams who are not time-sliced on multiple audits. And there's a lot of very positive feedback coming back from audit.

A definition of enterprise agility, and credit to Dan North for 90% of this definition: the speed and effectiveness with which an organization can generate new insights, adapt, and respond to them. And in particular, that generating new insights. It's that ability to generate insights from your customers that's really important. Not just being Agile and pushing stuff out to customers or colleagues, but generating the insights. And that could be A/B testing is one way of doing that, customer focus groups, getting customers to come in to do UX testing, many different ways to generate those insights.

And really what we're trying to achieve is a purpose-driven, self-managing, shape-shifting organization. This is the goal. Purpose-driven, so high alignment and high autonomy, a very clear view of the strategy and the vision, so that teams can be self-managing. Teams understand what the true north is, understand what the strategy is and the vision is, and the organization is able to be a shape-shifter, a bit like the T-1000 in Terminator. Can change form.

So when there's a stressful event, like in financial services, a significant market event, the organization can reform to continue to exhibit flow and safety and happiness, and so on and so on.

And there's a word for this. A material has a property which is called thixotropic, which I recently found out, which is, for example, tomato ketchup. If you shake tomato ketchup, it goes more runny, and then when you leave it, it goes less runny. It goes more viscous. And organizations should be very much like tomato ketchup.

The third learning is: it's easier to act your way to a new way of thinking than it is to think your way to a new way of acting.

What do I mean by that? So this is from John Shook. John Shook was the first American manager at Toyota, and what he observed, and his elevator pitch, his learning, is that it is easier to act your way to a new way of thinking than think your way to a new way of acting.

So previously, what we would have tried to have done with an organizational transformation, be it Agile or Lean, is we would have tried to change the thinking to change the behavior. We would have put people on a training course and we would have said, "There you go. You've been on a two-day Scrum Master training course. Off you go. Go and be Agile." Or, "You've been on, name your scaling framework, certification. Go and be Agile."

Without changing the system of work, and that does not end in great results. Far better to change the behavior to change the thinking. Change the system of work. You have to change the system of work. And this is a big learning for me in the two and a half years. You have to change the system of work.

To quote Deming, "A bad system will beat good people every single time." That is true.

So we are changing the system of work at Barclays, and I'm going to be talking a little bit about that.

The fourth learning is: use the force, Luke. Use the force. Feel where your organization is and where your business units are. This is the Kubler-Ross curve. The Kubler-Ross curve is very much like the Gartner hype cycle. There's the peak of excitement and the trough of disillusionment.

And I know exactly where all of our business units are in Barclays on that curve. And those gold stars represent where our business units are. We've seen this trend time and time again. We see it in the employee opinion surveys that we run. We see excitement. We see, oh my goodness, this is actually really quite difficult. I'm not sure we can do this. And then we see people climbing their way up and out to enter the next J curve, the next Kubler-Ross curve.

And my advice is for anyone going through a transformation, when you're at the honeymoon period at the top, make the absolute most of that. Make the most with your senior leaders. Get them out talking. Make the most of it in terms of changing the system, training, coaching, because you will enter the trough of disillusionment, and people will find it hard. And some people will say, "Oh, should we do this? Is this right for us?" And then it requires patience and determination, and a lot of determination and resilience.

There's a quote I like, which is, "Obstacles are not in the path. Obstacles are the path."

And then climb your way up and out.

So I'm now going to talk about, as I said before, do the thing right and do the right thing. So efficiency and effectiveness. And I'm going to share what we're doing around what we're calling lean control and lean portfolio management.

Lean control. We operate in the most regulated industry in financial services. That may not be the case for much longer in the US with Donald Trump. But it's the case at the moment with Dodd-Frank and lots of other legislation. So as I said before, it has to be control first. We have to operate in control. We need to be agile, not fragile.

So first of all, lean control. Do the thing right. How are we doing this at scale? Like I said, we've got 29,000 staff in technology. We've got many business units. We're 120,000 staff altogether in 40 countries. So how are we doing this?

One way that we help bring people on this journey is we play the cows in the meadow game. So we invite our control professionals, our compliance professionals, compliance, legal, information risk management, information security, we invite them to play a game. And the rules of the game are to draw a beautiful summer meadow with blue and red flowers in green grass, with some cows and birds under a shining sun. And they organize into teams to do this, play this game.

Let's have a look at some of the output. There's two teams' output. Which one do you prefer the look of?

The left one there. Yeah. So the one on the left clearly is far better than the one on the right. As the teams do this, we have teams work in two different ways of working. The team on the left worked in an Agile way of working. The team on the right worked in a traditional way of working.

And so for the team on the left, they were a multidisciplinary team with the vision to implement. And as you can see, there's some perspective. The cow at the front is bigger than the cow at the back. The birds are in the sky. The cows are actually standing on the grass, and the law of gravity is applying, which is a good thing. We've got some blue flowers. We've got some red flowers. We've got some green grass. We've got some perspective with the birds. All is good with that picture on the left.

The picture on the right, hmm, doesn't look quite so good. We've got an upside-down cow who has been crossed out. Maybe it's going to heaven, perhaps. Someone's written, "Oops." We've got some birds which are standing in the sky. We've got some very small cows. Maybe they're calves. And we seem to have a whole bunch of flowers in the sky.

The team that did that were working in a traditional manner. They had role specialization. There was someone to do the blue flowers, someone to do the red flowers, someone to do the green grass, and their control professional did not engage with them until the very end.

So we had some stooges for this game. The control professional, compliance, legal, information security, for the one on the left engaged early and often with the teams as they were drawing the picture. And they said, "Oh, don't forget about a bit of perspective and a bit of scale. Get this the right way up."

For the team on the right, the control professional did what actually happens in reality, which is they stood at the back of the room and waited till someone went over and spoke to them. And then they were on their BlackBerry, and they kind of gave a one-word answer, which pretty much, no negativity intended to our control professionals, but they're so busy time-sliced in a traditional manner on so many different control projects, it tends to be a conversation at the end rather than the beginning. And you can see the quality of the output.

And this really helps bring it home to our control colleagues in the firm how important it is to engage early and often on control topics.

So we've created control tribes. So applying Agile principles to how we implement speed and control, we have control tribes: long-lived, early and often interaction, aligned to value streams. So for example, equity trading in the investment bank, we have a control tribe comprised of information security, information risk management, fraud, anti-money laundering, legal, compliance, and so on.

And now they're long-lived with equity trading in the investment bank. So they actually get to understand the customer proposition. They get to understand the customer need. Rather than being time-sliced, one minute into equity trading, the next minute on mortgages, the next minute on currency trading, they get to understand the customer proposition. Also aligned to the long-lived teams on the long-lived products for the given value stream, with early and often interaction.

And we've implemented a lean control tool to support the interaction. The lean control tool is tailored to context. So when you have a change initiative and you want to launch your new change initiative, your project, your investment, you key in the bare minimum of information. We have 21 questions.

The previous process was a waterfall software development lifecycle that had seven gates and 28 mandatory artifacts. There were 770 questions in the previous lifecycle that we inherited, and it would take three months of elapsed time to go through that software development lifecycle process, even if it was a Hello World project you were implementing.

So we've leaned it, and it's tailored to context. So 21 questions, not 770 questions. From that, you end up with some indication of where are the high-risk areas. Is information security a high risk, for example?

We have long-lived products and business outcomes. So in order to use the lean control tool, you have to articulate what your long-lived product is. So in terms of changing the system of work, and back to the John Shook model, we're changing the system of work because we require people to articulate their long-lived product, and we require teams to articulate their roughly quarterly business outcomes.

So not analysis done, development done, testing done, but actually straight-through processing increased by 10%, net promoter score up by 5%, number of mortgages sold up by 10%, or whatever the desired business outcome is. So from activity-based milestones to business outcomes.

We have a menu of risk stories. So with a large amount of regulation, and with pretty much one standard per year of our existence, it's very hard for delivery teams to know exactly what controls apply to them as they're implementing a new product.

So with the lean control tool, there's a menu of risk stories. You sit down, early and often interaction with your control member. They'll go through the menu and they'll say, "This one, this one, and this one is mandatory. These are release two, these are release three, these are release four." There's a conversation with your control SME, and the engagement health is captured in the tooling. So from a management control perspective, from an oversight perspective, we can see if there are any issues with engagement in any part of the firm.

And we have an engagement health indicator. So anybody can toggle that to needs attention. And it's a bit like an Andon cord pull. This is not a negative thing. This is an Andon cord pull like Toyota. This is a request for help. And effectively, a virtual light flashes for the next level up to go and help with that engagement.

So our approach is not just to automate all the things. I think there are a number of companies I've seen or approaches one could take, which is just to automate all the things. We're not doing that. We are automating things, but first of all, we're right-sizing and setting up the right engagement model for our control professionals.

And really, this is the CAMS for control. This is culture, early and often interaction. There is automation, for example, for DevSecOps and security testing. Measurement, we've got built-in dashboarding and reporting for our control compliance. So in terms of the better, faster, safer, happier, we know that we're safer. And S, sharing, constant feedback loop between all of the roles involved.

So that's doing the thing right, and now doing the right thing. So at two and a half years in, a lot of focus around maybe at the team level producing the right thing, and the constraint shifts to the left. And we look further up the pipeline, and actually it's the portfolio management piece. How long is it taking us to decide what we should be working on and getting that to the teams? So this is our current focus.

So we are shifting from an annual planning process with predictive planning, lots of planning and planning and planning for the next year's budgets, to hypothesis-driven investment.

And to quote Barry O'Reilly, we are writing business outcomes in the format: we believe this capability will result in this outcome. We will have confidence to proceed when we see a measurable signal. So this is very similar to OKRs, objectives and key results, for those of you that are familiar with OKRs. And we are at the beginning of doing this in the firm. We're just starting to roll this out to write quarterly business outcomes in this format.

As I said, business outcomes over milestones. Not analysis done, development done, and testing done, but STP rates increased by 5%, net promoter score up by 5%.

Rolling wave over annual. So we have a monthly cadence around portfolio management, and the business outcomes are roughly quarterly.

We're building in learning and optionality over sunk cost. Previously what would have happened is, big initiative, we're going to invest a load of money over a three- to four-year time period, and we're going to track the tasks rather than the outcomes. Now, whether you're waterfall or Agile, we want to see quarterly business outcomes with a rolling-wave basis, and actually what have you delivered? What business value have you generated?

And we have an incremental build of the business case. So right at the head of the pipeline, we have a very fast two- or three-day turnaround just to take an idea and expand it the next level into a business case. Is this really a good thing to do? And in doing this, in one particular part of the business, business cases have been killed very quickly because they turned out to not be such a valid idea.

And Obeya rooms. So increasingly, performance walls and Obeya rooms. This is a room where you've got lots of performance information up in the room. Increasingly I'm seeing this both at Barclays and at other firms, and this is something I want us to do a lot more of at Barclays because I think there's a lot of value in this.

I'm going to share an example. So this is Barclays Partner Finance in Cardiff. I know we have some Barclays Partner Finance colleagues in the room. This is their Obeya room.

I was very impressed when I visited, and on the far left of the picture with the pink Post-its at the top, those are quarterly business outcomes. So you can visualize there your backlog. This is a Kanban portfolio process. You can visualize the business outcomes on the left.

The A3 printout in between the left board and the yellow board, that is the CEO's top business priorities. That's an ordered backlog from the CEO of the business, who also stands in that room on a regular basis with his leadership team.

So then the yellow board, this is then breaking those business outcomes down into features. So roughly one-month features from a three-month business outcome. The next board along is the Kanban process to refine the features, to start to break them down into stories for the teams to pull. And then on the right-hand side, the teams are pulling the features, and you can see there some of the team names. There's Team Delta in there, Team Tetris, and you can see they've pulled one feature and they've got a burnup chart.

On the wall on the right that you can't see in this picture, there's a whole load of cumulative flow diagrams, a whole load of metrics. And just standing in there, you can immediately see the state of the system. You can see the health. You can see where there's been historically too much work in progress. That's shone a light on it for everybody, including the leadership team in the business.

So this is a really great thing, and I'm hoping we see more of this at Barclays.

So to summarize, in order to go fast, you need to have good brakes. The better your brakes, the faster you can go. The better the brakes on this bobsleigh, the faster it can go. So for us to exhibit agility, we need to have good brakes. For us to go fast and have speed, we need to have good control.

Thank you.