Jonathan Smart

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

I'm going to share with you an experience report. Barclays has been on this journey organization-wide for nearly three years. In January 2018, it'll be three years. So I'm going to share some lessons learned from our journey. Hopefully, some of you will benefit from some of these lessons learned.

Everything is context-dependent, so it will depend on your context. Some lessons might resonate with you; some may not.

In terms of me, I sit in the technology organization. However, our remit is not only technology. As Gene said, we are looking at impediments to flow across the whole organization. So that includes legal, finance, compliance, everything. Systems thinking, the whole organization.

First of all, Barclays. Barclays is a financial services company. We're a universal bank. We have investment banking, retail banking, corporate, wealth, and Barclaycard. We are 327 years old. We were founded in 1690 in the City of London, which was four years before the Bank of England existed, and it also makes us older than the United States of America.

In our origins, we were founded by two goldsmiths, and our origins go back to the beginning of paper money in the West, because you would deposit your gold or your silver with the goldsmith, and you would get a receipt which would say, "I promise to pay on demand the sum of £1 of gold or silver to the bearer." Pound sterling actually comes from a pound of sterlings, and sterlings was the name for a silver coin. So we go back to the origins of paper money.

Today, the two founders in 1690, I think, would be very pleased that the company has continued to be successful. We have 120,000 employees in 40 countries, and we have 29,000 staff in technology. We have an annual revenue of £20 billion, which is about $26 billion U.S.

We have 48 million customers. We process 30% of the annual UK gross domestic product every single day. That's £600 billion a day which is flowing through our technology. That's flowing through our software and our hardware, and other people's hardware and other people's software.

We meet a financial need for almost half of the adults in the United Kingdom. Every £1 out of every £3 is spent through Barclaycard. And, like a number of you in this room, like a lot of industries, we're very highly regulated.

So we have to have both speed and control. In fact, we have to have control because financial services is all about trust. We're looking after your money, ones and zeros on a disk somewhere. So it's all about trust. We have to have control first and speed second.

Lessons learned. I'm going to share six lessons learned, and then I'm going to talk a bit more about how we're tackling speed and control.

The first lesson learned: if I could go back in time and I could speak to myself in January 2015, and I would say, "John, do you want to scale agile?" And of course I would say, "Yes, I want to scale agile." My advice would be, "Don't."

In order to scale agile, don't scale agile. Descale the work first. If you just take 200 people working in a traditional manner and you slap agile on those 200 people, you will not get the outcome that you think you will get. You won't get a good outcome. I know. We've done it. We've learned from it.

There was one particular part of the firm: 100 people trying to deliver a product in a traditional manner. Multiple failures. Take five people from 100 people. Those five people managed to deliver something into production, customer-facing, within a few months. Five people instead of 100 people. So descale the work first.

Achieve big through small. This is something I've learned in two and a half years. Achieve big through small. Have a big vision. Have a big outcome. Be clear what you're doing, but then achieve it through small. Small everything. Small investment, small team size, and small batch size. A small amount of work. So do a spike. Do a spike with a small team, with one customer, and just learn from that spike.

To quote Dave Snowden. Dave Snowden is one of the creators of Cynefin. Who here is familiar with Cynefin?

Okay, so that's a disappointingly low number of hands going up. If you're not familiar with Cynefin, it's a Welsh word: C-Y-N-E-F-I-N. I highly recommend you go Google it and you go and watch some videos of Dave Snowden because it's very relevant.

So to quote Dave Snowden, "You don't scale a complex system by aggregation or imitation, but by decomposition to an optimal level of granularity, followed by recombination in context."

You don't scale by aggregation or imitation. You don't do the same. You do not have one size fits all. You don't slap one way of working on an organization because you will not get the desired outcome. You do not aggregate the same. Organizations are not homogeneous. They are diverse, they are complex, they are different, and context is king. Do not try to do the same thing because you won't optimize for outcomes.

So that's from Dave Snowden.

Do you want to do an agile transformation? I would go back in time and I would say that to myself. I'd say, "John, do you want to do an agile transformation?" And I would say, "Yes, I want to do an agile transformation because that's my job. I'm being paid to do an agile transformation."

What do you think I'd say to myself?

Correct. Don't.

To do an agile transformation, don't do an agile transformation. Focus on the outcomes. Focus on why. Simon Sinek, "Start with why." Why are you doing this? You're not doing it for the sake of agile. You're not doing it for the sake of DevOps. You're doing it for a reason. And if you don't have a reason, don't bother. If you don't have competitive forces and you're making enough money and everyone's happy, don't waste your time.

So understand why you're doing it. Focus on the outcomes. You will probably end up doing an agile transformation, but don't do it with agile transformation as the headline. It's not the opening act.

For us, our outcomes that we're focused on are flow, quality, happiness, and value. That's what we're doing. We're focusing on flow, quality, happiness, and value, and these are the things we measure. I measure, we measure, flow: lead time, throughput, flow efficiency. We measure quality: incidents in production. We measure happiness: colleague happiness, net promoter score, colleague net promoter score, and customer happiness, customer net promoter score, or other measures of feedback. And value.

I will speak a little bit later about value and how we look at value, and there's a time decay element to value as well.

I surface metrics on these measures to the organization, to senior leadership. We focus on those. So it isn't about doing agile or doing DevOps for the sake of it. It's around, how's your flow? How's your lead time? How's your quality? Any problems? Anything you want to improve?

We have a toolbox, and in this toolbox, we have Agile and we have DevOps, and we have Scrum and we have Kanban, and we have SAFe, LeSS, Nexus, Disciplined Agile. We have a whole bunch of tools in that toolbox, and it isn't a case of always using the same spanner. This is not a spanner transformation.

And be the best at being better. Ultimately, what this is all about, it's about being the best at being better. It's about evolution, not revolution.

I have a bee in my bonnet about capital-A Agile and capital-T Transformation. Capital-T Transformation is saying, "Whether you like it or not, organization, you're going to be transformed. We're going to do transformation to you."

As a leader, it's like, yes, we want to transform. But for the people doing the work, it's, we're going to inflict yet another transformation on you. So, "Oh yeah, here we go. Every three years, another transformation. I'm just going to nod and smile, keep my head down, keep quiet, put on my invisibility cloak. No one can see me. I've been here before. I know the story."

And that's a transformation with a capital T. And it's not surprising that lots of transformations are not successful.

Agile with a capital A. I also have a bee in my bonnet about Agile with a capital A. It is not a noun. It has a lowercase a. The Agile Manifesto can have capital letters, as can Scrum and Kanban, but agile is like nimble. We're doing a nimble transformation with a capital N. It's a mindset. It's a way of thinking.

Agile Manifesto, that's fine to capitalize that. There are some principles. It's a mindset. There are principles. There are values. There are principles. And the practices are unique depending on your unique context.

So my third learning is my team used to be called the Agile Adoption Team. We're a small, central center of enablement for the organization. My team is now called the Better Products Faster Team for the reason I just said.

So when I go and meet with leaders, rather than saying, "Hey, I'm here to help you with your agile transformation. I'm here to help you adopt agile," I say, "Hey, I'm here to help you deliver better products faster. Would you like some?"

"Yeah, of course. Yeah, I want better. I want faster. Yeah, of course I do."

"Do you want some agile?"

"No, hate agile. We've done that four times, and it failed every single time. We're special. We're different. We're unique. Can't possibly do that. But better, yes. Faster, that'd be fantastic."

And the full term, the elevator pitch, is better products faster, safer, happier. That's the tagline I have on nearly every bit of material when I'm speaking to leaders in the organization.

"Hi, I'm John, and I'm here to help you deliver better products faster, safer, happier. Do you want some?"

"Yes, please."

And then I get asked a question, which is, "Have we increased our productivity? How much have we increased our productivity?" Wrong question. It's not about productivity; it's about valuetivity.

The definition of productivity is producing more output for one unit of input. That's fine. We can create rubbish quicker if that's what you really want. We can churn out more stuff. That's not a problem. We can do that. And in fact, we see that happen. I see it happen both at Barclays and at other companies.

Some companies where the IT, the technologists, get so good at this, they front-run their business partners, and they start making decisions on behalf of their business partners because the business partners are left behind. It's like, "No, stop."

So it isn't about productivity, it's about valuetivity. And valuetivity, which is a made-up word, actually means doing less to do more. It means going and spending time with customers, doing a Gemba walk, innovating, experimenting. Stop coding and go and sit with a customer.

And so the name of my team is the Better Value Faster Safer Happier Team.

The third learning, or the fourth learning, is whole enterprise agility. It's a local optimization if you just focus in technology. We need to also be focused on HR, legal, procurement, everybody in the value stream. We need to be looking at the value stream.

Definition of whole enterprise agility is this, and this is credit to Dan North for 90% of this. Changed it ever so slightly. The speed and effectiveness with which an organization can generate new insights, adapt, and respond to them. And it's the whole organization, not just technology, that needs to be able to do this.

And that "generate new insights," that's really difficult. And we generally don't spend as much effort on generating the insights as I think we could. You have to go to lengths to get the feedback, especially if your consumers are retail, and there's many millions of them. You have to go to great lengths to get that feedback.

And organizations should be, we want to be, a purpose-driven, self-managing shape-shifter.

Purpose-driven. Frederic Laloux, Reinventing Organizations. Teal organizations have a very clear purpose. Our purpose is to help people achieve their ambitions the right way.

Self-managing: high autonomy, high alignment. There's a very clear goal, there's a very clear vision for teams to achieve. A bit like the military in the 1800s, going from detailed command to mission command.

And shape-shifters. If there is a market disruption, if there is a new entrant, if a company is taking market share, the organization needs to be able to shape-shift. It needs to be able to break the value streams and recreate new value streams, and then those value streams need to be solid, thick, fast flow of two-way communication.

There's a chemical property for shape-shifting, which is called thixotropic. So if a material is thixotropic, that means you apply energy to it, it becomes more runny. It becomes less viscous. And then when you leave it, it goes more viscous. Organizations need to be thixotropic.

Tomato ketchup is thixotropic. When you shake a bottle of tomato ketchup, it goes more runny. When you leave it, it goes harder. So organizations need to be more like tomato ketchup.

The next learning: it's easier to act your way to a new way of thinking than to think your way to a new way of acting. This is from John Shook. John Shook was the first American manager at Toyota. And this is what he observed.

The old way of change would be to change thinking to change behavior, to put people on a training course, go on a two-day Certified ScrumMaster course, come back, you've completely changed. Everything's magic. It's like magic. Wave a magic wand, and all of a sudden, everyone's agile.

But the system of work hasn't changed. What have we done? We focused on the workers, not the work. And as we know from Deming, that's the wrong way around. We need to be focusing on the work, not the workers.

So effectively what this is saying is, focus on the work, not the workers. Support the workers with capability building, with training, but we have to change the system of work. We have to change the system of work.

A bad system, again, to quote Deming, "A bad system will beat good people every single time." And I've seen it. I have witnessed this firsthand in Barclays, and we made a mistake. We trained loads of people, and we didn't change the system of work. And then we realized our mistake, and now we started to change the system of work.

My sixth learning is, use the Force, Luke. This is the Kubler-Ross curve. It's a J-curve. Use the Force. Feel where you are on that curve. This could be a department, it could be a team, it could be an entire business, but you will be somewhere on that curve.

You could be in the honeymoon point at the top. If you're at the top and you're in the honeymoon part of that curve, make the absolute most of it. Ask your senior leaders to come out and talk. Get as much investment as you can to help support the capability building.

Or you might be in crisis down at the bottom, when you realize this is actually very difficult and you're struggling, and you might be thinking, "I'm not sure this is for us. I'm not sure we can do this."

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

For what we do, for achieving flow, impediments are the path. It's theory of constraints. It's: you fix your biggest impediment, you find the next one. And it's been interesting for me, as I've been attending talks over these three days, I've been hearing quite frequently legal, finance are an issue. And we're starting to, in terms of DevOps as a metaphor, we're starting now to see the constraints in portfolio management, in budgeting, in finance.

For me, finance is a big frontier for agility.

So now I'm going to talk about how we balance speed and control, and how we balance information security, compliance, audit, anti-money laundering, fraud with speed. And I'm also going to talk about lean portfolio management.

So this is how we do the thing right, and how we do the right thing.

First of all, lean control. Now, we call it lean control. That's our name for it: do the thing right. This is how we have both speed and remain compliant to regulation and control.

And we play a game with our control professionals. We'll set up a session. It's the cows in the meadow game.

In the cows in the meadow game, the mission is to draw a beautiful summer meadow with blue and red flowers and green grass, some cows and birds under a shining sun. And you're split into two teams, or two sets of teams. One set of teams work in an agile manner, and another set of teams work in a traditional manner.

Let's have a look at some of the output.

So there's two pictures. Which one do you think is better?

The left.

Yes, the one on the left is better. The one on the right, there's a cow upside down that's been crossed out with the word, "Oops." Maybe that cow's going to heaven and has died. I don't know.

There's a couple of birds in the sky who are not flapping their wings, so the theory of gravity, the law of gravity, is not applying on the right-hand side. There's no perspective. The cows all seem to be calves. They're all very small. So some baby cows there. Flowers in the sky. Not great on the right.

On the left, much better. The birds are flapping their wings. They're flying. There's some perspective. There's a big cow. There's some little cows. There's some green grass and there's some flowers.

The difference there is the control professional on the left was engaged with the team. They had early and often engagement. On the team on the right, they did what normally happens, which is they didn't engage with the team. They waited for the team to engage with them. This is no disrespect to any control professionals. This is just the traditional way of working. It's how typically we have worked historically.

And in both cases, the control professional was asked to sign off at the end. At the eleventh hour, they were asked to sign off. And that's why that cow was crossed out, because it was right at the very last minute that they realized there was something wrong. And this reflects reality.

Back in 2015, we had one of our exemplar agile teams. Super agile, super fantastic. And then just before go-live, they realized they hadn't spoken to information security. And so they spoke to information security, and then three months later, they'd finished the additional work. And then this very agile exemplar kind of went live not very agilely.

So we've fundamentally changed our engagement model with our control professionals: information security, data privacy, information risk management, fraud, anti-money laundering, enterprise architecture, IT ops, accessibility, and there's more. We have a lot of people who are in control SME roles.

And so we have pivoted the operating model. We've changed our system of work. We used to have engagement at the beginning and at the end, and it wasn't always at the beginning. It was definitely at the end.

We now have early and often engagement, so it's little and frequent, depending on the need. It's context-sensitive.

We've gone from control colleagues being time-sliced on multiple different things to being long-lived by value stream. So previously, someone in information security, one minute they're working with mortgages, the next minute with FX, the next minute with equity trading, the next minute with Barclaycard. So there's no appreciation of the value stream and the customer need, and the customer unarticulated need.

Now, we have somebody from each of those functions working together in a long-lived team, associated to a long-lived product, which itself has long-lived teams. So they start to understand the customer's unarticulated needs, and they can start to contribute to things like, "Oh, if we did this type of authentication, if we did voice recognition, we could really differentiate ourselves in the market from our competitors through voice recognition when calling into a call center," for example.

Used to be aligned by role, now aligned in multidisciplinary teams. Engagement via email to an engagement health Andon cord. So we have an ability for, like the Andon cord in Toyota, you pull the cord, and if it takes longer than the takt time, the assembly line will stop. The leader comes running over, says, "Thank you. How can I help?"

We have a virtual equivalent of that where either someone on the product team or in the control tribe, they can press a button and it shows up. It flashes a virtual red light. So we then know that there's an impediment. There's an impediment which has been surfaced, which we can then deal with and get on top of it quickly.

And from a contract to a conversation. We used to have over 700 questions in multiple questionnaires. Anything from 25 to 45 mandatory artifacts stored on 10 different SharePoint sites. That's the evolved 300-year process.

We have gone away from that. We have as few questions as possible just to frame it at the beginning. And then we have conversation. It's stories as a placeholder for a conversation.

And we've gone from linear projects to quarterly business outcomes. Quarterly business outcomes like OKRs, objectives and key results. These are not analysis done, development done, testing done. It's straight-through processing increased by 5%. Number of click-throughs on the website increased by 10%. It's articulated as a business outcome, and that is the unit of conversation.

What are you trying to achieve in your quarterly business outcome? Let's have a conversation around risk and control on your product, which I now know a lot about because I've been associated to it for a long time, and what you're trying to achieve. And I will give you context-unique advice.

We have a lean control tool that we've implemented to support the people, the process, to the tooling. So it's in that order: people first, then process, then tooling. And we have a tool which supports this way of working, and this is across the whole firm, across everything that we do to do with change.

We have a menu of risk stories. One of the problems we had previously is we have more standards in the bank than we have years of existence. How can anybody possibly comprehend everything they need to do for a given delivery?

And we have now codified that, and this includes regulation as well, things like GDPR, as well as our internal controls. It was possible to do it before, and we did it before, but it was very time-consuming. It was very inefficient. It was very difficult. So by making it easier, we're increasing the likelihood that control effectiveness has gone up.

We have a menu of risk stories. The lean control tool prompts a conversation with the control tribe. So when you have your new quarterly business outcome, it automatically gets pulled in. The systems are integrated with whatever tooling we're using. It pulls it out of our tool that has the business outcome in it, and then you say high impact, medium impact, low impact, or no impact to your particular control guild.

If it's no impact, no conversation needed. If it's high impact, you're going to have a regular conversation, and it prompts that conversation.

There's an engagement health indicator. That's the Andon cord pull that I said. It's tailored to context. This is super important. It's unique. It's unique to your context.

So the product owner and the team lead with the control tribe will go through that menu of risk stories and they will say, "This one, this one, this one, this one, are mandatory. This one, this one, this one, you can do in a month's time. This one you can do later." So it is entirely unique for your business outcome as to what is implemented.

Previously, it was all one size fits all.

It's integrated with the tooling. It's completely seamless. There's no dual-keying. So the tools, whatever the tooling is, be it Jira, be it Rally, whatever the tooling is, it's fully integrated. So the work, any actions that come out of this, risk stories that come out of this, are automatically populated into where the team is already working.

And so as well as having feature stories, functional stories, and non-functional stories, we have risk stories. And we know when they've moved to done. We have a callback through the APIs, and we know when they've been done, so we can determine that in the lean control tool.

So that's do the thing right. Now, what about doing the right thing?

So shift left, great. The teams are cooking on gas. The control environment's working well. Now, what's happening left? What's happening upstream of all of this?

Ozzie Udezue talks about the urgency paradox, where something can be waiting in the portfolio management queue for 18 months, and as soon as it hits the build team, the product team, all of a sudden it's urgent. You've got to do it in one month. You've got to do it in two weeks. But it's been waiting for 18 months.

So we are very early days. We are starting to roll out hypothesis-driven investment. Credit to Barry O'Reilly. We're writing business outcomes as, "We believe this capability will result in this outcome. We'll have confidence to proceed when we see the following measures." And we are measuring these.

We have KPIs, typically lagging indicators. So click-throughs on the website, net promoter score for customers, specific measures on our business outcomes.

We are pivoting. Very early days, we're pivoting to quarterly business outcomes over milestones. So again, instead of analysis done, development done, testing done, it's a business outcome.

It's rolling wave over annual. We're doing quarterly rolling wave planning, quarterly rolling wave pivoting. We are able to build in learning and optionality over a sunk cost fallacy. Previously, annual planning: this is your budget for the next year. It takes us six months to work out what the next year's budget's going to be with multiple rounds of planning, and then it's almost unchangeable. So we're changing that and making it more changeable, more adaptive, able to pivot.

It's an incremental build of a business case. So more like an internal VC model, Series A, Series B funding. So the first business case is a lightweight business case, back to achieve big through small. Here's a small amount of funding. Go and run some experiments. Go and do some spikes. If that all looks good, then we'll give you more money.

And Obeya rooms. Obeya rooms is to do with visualizing the work, and I'll show you an example.

This is an Obeya room. This is Barclays Partner Finance in Cardiff in Wales. And on that wall, you can see everything from the CEO's top five priorities. There's an A3 printout on the wall. You can see them broken down into business outcomes. You can see them broken down into features. And then you can see on the far right-hand side the teams that have pulled a feature to work on, and you can see burnups.

And that enables a team, anybody can go and stand in there and they've got lineage. They can link their story they're working on all the way back up to a CEO top-five priority. And you can just stand in there. On the right-hand wall that you can't see in the picture, there's a whole bunch of cumulative flow diagrams, and you can instantly see the health of the system or any impediments in the health of the system.

Here's the help I'm looking for.

Stories of thawing the frozen middle. Maybe, to word that more generously, stories of supporting the pressurized middle. It's difficult being the pressurized middle.

Stories of lean portfolio management. I'm interested. Please get in touch if you've done what I've been talking about. Like I said, it's early days for us. This is our path. We're experimenting on this. If you're two years down this journey, I'd love to hear from you.

And stories of flow efficiency. So we now accurately measure lead time from pulling off the backlog into production, and I want to improve on that. And I really want to start to measure flow efficiency a little bit more than we're doing currently.

So with better brakes, this bobsleigh can go faster. With better control, we can go faster.

Thank you.