The Yin and Yang of Speed and Control

This is an experience report of the journey to adopt agile and lean principles and practices across Barclays Group (120,000 people, 40 countries, 327 years old, in the most regulated industry). We are 3 years into the firm-wide journey, This talk will share lessons that we have learnt. It will also focus on the yin and yang of Speed and Control, as this is a hard challenge in a highly regulated industry with thousands of Control professionals who are incentivised to avoid issues, not deliver at pace. On the surface, there can appear to be a conflict between speed and control.

Certainly, the traditional approach to control inhibits speed. As we are in our third year of firm-wide change in how we do what we do, we are starting to tackle the harder challenges. We are implementing at scale a radical change in how we comply to a huge amount of standards and regulation, this talk will share our learnings to date.

Learning Objectives

• Learn from our lessons, avoid mistakes we made, take shortcuts.
• How to have both speed and control in a large, old, complex, highly regulated firm

Transcript

Good morning. So, as Nancy said, we've got the luxury of 18 minutes, so this is like an extended lightning talk. So I'm going to do this at 1.25 times normal speed. When you play it back on YouTube, watch it at 0.8 and it will sound normal. And I just want to say business agility: this is where it's at. And I'm really pleased that it's agility, not Agile. Yes. You know, evolution, Agile manifesto, Scrum, Kanban, SAFe, DAD, LeSS, Nexus: business agility.

This is it. This is the next, this is the next evolution. So, my name is Jonathan Smart. I'm leading on Ways of Working at Barclays. I'm going to cover three things in the next 30 seconds. I'm going to talk about lessons learned on our journey. We've been on the journey around Ways of Working for three years now, so I'm going to share where we've got things wrong, where we've messed up so that some of you can not repeat the mistakes that we've made.

Secondly, I'm going to share some examples of Agile outside of I.T., and thirdly, I'm going to talk about speed and control. So how we have agility, and as a regulated industry, we are Agile, not fragile.

So, first of all, a bit about Barclays. So we're a bank. We have offices just three blocks up on Times Square, which used to be the Lehman's building. We're 327 years old, founded in 1690 in the city of London. So we're older than the United States of America.

We have 80,000 employees in 40 countries. We have 29,000 in technology, which I think is roughly the same size as Google. We have an annual revenue of 20 billion pounds, which is about twenty six billion US dollars. We have 48 million customers. Thirty percent of the annual UK gross domestic product is processed every single day through our systems, so that's about 600 billion pounds a day. So it's not like Netflix if we have an outage.

We meet a financial need for almost 50 percent of the adults in the United Kingdom. One pound in every three pounds is spent through Barclaycards in the U.K., and we operate in the most regulated industry. So Agility, again, we can't be fragile.

In terms of lessons learned - so the first lesson learned is, do you want to scale Agile? Who wants to scale Agile? OK, so don't. Lesson number one: if you want to scale Agile, don't scale Agile. Descale the work first, and achieve big through small.

So don't take an existing area of, and this is a real example - Barclays, don't take an existing area of one hundred people. Take a scaled Agile frame, not THE but A scaled Agile framework, apply that framework to those hundred people and say, off you go. You've been on the training course, you've done your certification, you, you've done your certification, you've done your two days. You're now Agile. Off you go. Go and be Agile. Job done. Arms crossed. Let's, let's watch this Agility. That's, that's not a good approach, and I would advise not taking that approach.

Descale the work. So real example: hundred people trying to deliver a product, multiple attempts at trying to deliver this product. And in the end, what we did is we took five people and in the space of three months, those five people managed to deliver something of value to production to external clients that 100 people hadn't delivered in a much longer time frame.

So descale the work, achieve big through small. That's small teams, small investment and small work. So break it down. And it's not about scaling Agile, it's about agility again. So it's about a network of interdependent services. So descale the work, and then build up the descaled work, and, and there are patterns to help with that building up of the descaled work.

Who wants to do an Agile transformation? Oh, so I think I saw one hand go up over there. You're fast learners. Don't! So this is the second, this is the second learning, and, you know, when I like I said, we've been on this journey for three years. When I started out, I was the - my job was to do this. I was paid to do an Agile transformation. I was the head of the Agile Adoption Team. And my learning is, to do an Agile transformation don't do an Agile transformation. You will, you will end up transforming to have agility, which is far preferable to an Agile transformation.

Focus on the outcomes. So work out what your outcomes are. What are the problems you're trying to solve. For us, our outcomes, and this is what we measure, is our flow, quality, happiness and value. Those four things we measure. The fourth one is very difficult to measure. The first three are easier to measure. And I send out, once a month, I send out a one-pager of metrics with with some measure for those four, which go to basically the whole - all of the leaders, the senior leaders in the organization. In particular, we focused on flow. Focus on flow, everything else tends to fall into place. This is lead time, cycle time, throughput, flow efficiency. In large organizations typically flow efficiency, the amount of time that work is being worked on versus work waiting, is about ten percent. So typically, work is waiting 90 percent of the time and this is where, this is the root of it. This is the root of agility in knowledge work. So, to get it from ten percent to 40 percent, 40 percent is about best-in-class at the moment.

So if you can get your flow efficiency to 40, if you can measure your flow efficiency, first of all, and then get it to forty percent, you're doing an awesome job. And then you have to have some balancing measures, because if you just focus on flow, if people - and anything can be done badly, including Agile - then you have problems with quality, and quality goes down and we see this. We see this in the Puppet Labs DevOps enterprise survey.

The laggards, the poor performers, have reduced their lead time, but their incidents have gone up, the quality has gone down. So you've got to have these balancing measures. Likewise happiness. You can force people to work harder, not smarter. Well, you can't force people, but people can try to get people to work harder, not smarter. And then, of course, engagement goes down. Again, doing Agile, badly. And then value: we're using OKRs, objectives and key results, quarterly business outcomes where the KRs are the measure of value, because it's not just revenue, it's not financial. It could be corporate social responsibility, for example. And be the best of being better. So ultimately, what this all comes down to is a process of constant improvement. It isn't a transformation with a capital T. It doesn't have an end date. You're never, ever done. It's a process of constant improvement. Likewise, I don't like Agile with a capital A, you know Agile doesn't have a capital A it isn't a noun, it's agility.

So try substituting the word "Agile" for the word "nimble". Nimble doesn't have a capital N. We're trying to be nimble, we want, we want to be nimble. And I worry about Agile with a capital A and the, you know, the Agile Industrial Complex. If any of you have read about that. And so, my team used to be called the Agile Adoption Team. At the beginning of last year, we renamed my team to the Better Products, Faster Team.

So we stopped using the "A" word and we stopped using the "T" word. So when I go to leaders - previously, I would have gone to a leader and I would have said, "Hi, I'm John. I'm here to force Agile on you." Now I go to a leader and I say, "Hi, I'm John, I'm here to help you deliver better products faster, would you like some help?" Of course. You know. Previously, people go, "Ohhh Agile. We tried that. We tried that five years ago. It's not for us. It doesn't work. We're special. We're too regulated, too much regulatory change." Whatever. So it isn't about the "A" word. And you've got a kit bag, and in that kit bag you've got Agile, DevOps, Lean, Design Thinking. You've got a whole bunch of tools that you can use.

So, so then the conversation is about, you know, what are the problems you've got? What are your challenges, what are you trying to address? And then again, focus on the outcomes. The full tagline is "Better products. Faster, safer, happier." So that's what we have on the top of our, you know, our, our decks, when we, when I'm going around speaking to leaders. And then the conversation is, well, "John, tell me how how we've increased productivity", and that's the wrong question. The question isn't "how have we increased productivity?", because productivity is the amount of output for one unit of input, and then you get into the problem of the feature factory where all you're doing is you're just churning out stuff. And this is a problem with, you know, kind of Scrum and just focus on blind, focus on lead time and velocity and things like this where you're just churning out stuff. And actually it's not valuable stuff. And so it's really about value-tivity. And often we want people to go slower.

In fact, nearly always we want people to go slower in order to have better outcomes. We want people to be innovating. We want people to be spending time with their customers. We want to get the hands off the keyboard, and actually getting some feedback. So our tagline is "Better Value Faster Safer Happier". That's what we're about.

The next learning is whole-enterprise agility, which is obvious for this conference. You know, we're not about Agile in I.T., we're about whole organization agility. So my remitters across all of Barclays, I, I sit in technology however, our remit is everything. And a definition of whole enterprise agility: "the speed and effectiveness with which an organization can generate new insights, adapt and respond to them", and I think it's that "generate insights" is important because again, it's easy to have agility and to produce stuff and produce it without getting feedback. That's quite easy. The hard thing is getting the feedback, especially when you've got, you know, millions of retail customers.

You need to go to lengths to get good feedback, to be able to respond to it. And like I said, ultimately, what we're trying to get to is a network of interdependent services. There's a great book, Team of Teams. How many of you have read Team of Teams? Yeah, quite a lot of people. If you haven't, I recommend reading it. You know, so similar learnings: they're going from Mission Command, Command and Control, hierarchical organization, to, to the networked multidisciplinary teams, kind of bringing together the Navy SEALs and the FBI and the CIA sharing information where previously that information wasn't shared.

So we're trying to get to a network of interdependent services. And Frederick Laloux, reinventing organizations, again, aspirationally, we're trying to get to be a purpose-driven, self-managing, shapeshifting organization. Clear mission, really clear purpose. This applies at multiple levels in the, in the, in an organizational construct, self managing as much as possible and shapeshifters like the T1000 and Terminator. If there's a market stressful event like 2008, the organization needs to be able to kind of break its value chains, recreate new value chains and those value chains to be strong again.

There's a chemical property called thixotropic. So thixotropic is a substance, when you apply a force to it, it kind of goes more runny and then it sets again. And we want an organization to be like that. We want strong value chains, and then if there's a market stressful event like a new entrant, a new competitor, new legislation, the organization can reconstruct itself. Tomato ketchup is thixotropic. You apply some stress to it, it comes out of the bottle. So organizations need to be more like ketchup.

In terms of Agile outside of I.T. - so our internal audit department have adopted an Agile Way of Working, so audits now nothing to do with technology. Audits are now done in an Agile manner, and our audit department have found that that's saved a third off of the time to do an audit. So instead of an auditor being time sliced on, you know, multiple audits at the same time, now they work in a multidisciplinary team, limit work in progress. They're visualizing their work on Kanban boards, just focused on that one. And then as somebody who has been audited multiple times, I used to be very frustrated that I'd get this big thud of a thick document, you know, six months later. But now I get to see the, you know, the hypotheses that are being worked on every week, and then I can comment on that. So there's a lot less waste in the process.

This is compliance, so our compliance function have adopted Agile Ways of Working, and they've shifted from being kind of, they're shifting to compliance as a service. So in terms of the network of interdependent services, they are actually describing themselves as compliance as a service. They're setting themselves up as compliance as a service, and they're adopting modern ways of working. They're visualizing the work in progress, they're limiting the work in progress, they're story mapping and adopting better ways of working.

And then our real estate. So real estate across Barclays, across 40 countries, we have quite a lot of buildings, and right at the top level, the head of real estate.

This is the approach taken to managing the portfolio. It's a Kanban board with visualizations. We have third party vendors who come in to do work for us, and I had a conversation with one of these companies, and on one side of this room were Microsoft PowerPoint Gantt charts that hadn't been touched for six months. On this side of the room, there are a bunch of Kanban boards which were, you know, bang up to date, alive and kicking, updated on a daily basis. And I said to the to the to the person who, whose company it was, I said, "You know, this is the first time they've worked this way. Would you go back to working that way?", and he said, "Absolutely, not, never. You know, we're going to work this way from now on. Visualize work in progress."

And we actually, we had a construction company come in and visit us in Barclays, and construction companies are now adopting Agile practices. So a morning stand up, having having a stand up at a board, kind of visualizing the current state of construction, visualizing impediments, multidisciplinary team discussing how to overcome the impediments. So even in an area that you think they wouldn't be Agile, companies are adopting Agile ways of working.

So on to speed and control. So we are heavily regulated. It's important that we have agility, that we have continuous everything, but we have to have control as well. So, we've pivoted from our control functions, for example, information security, data privacy, fraud, accessibility, previously used to be organized in their, in their in their functional areas, and as a delivery person, what I would have to do is I'd have to engage with them at the beginning and then engage with them at the end in a waterfall type construct. And of course, what would happen is, as teams engage with them at the end, there's then three to six months of unplanned work, then comes up.

So what we've done is we have applied an Agile principle to this and we have multidisciplinary control tribes aligned to value streams. They are long lived teams aligned to long lived value streams. So, for example, mortgages, currency trading, equity trading, Barclaycard, contact center. And so, we can then have innovation from these control tribes because they get to understand the customer, the customer's unarticulated needs. So things like biometric authentication. Now, if it wasn't the same person who really got to understand the value stream and the customers, we wouldn't be able to have this level of innovation.

And so we've shifted from a line by role to multidisciplinary teams. Early and late engagement to early and often engagement. Time-sliced to long lived by value stream. Engagement via email to engagement health Andon Cord - I'll show you that in a second. Contracts to conversation, so regular frequent conversation, and from a linear project to quarterly business outcomes. And this one, this one's passing the mobile phone test, that's a good, that's a good indication, that one.

Lean control process. So we've got these control tribes, and so we've pivoted from a historical waterfall lifecycle to a continuous everything lifecycle. Again, in a heavily regulated industry. We call it the Lean Control Process. We have business outcomes coming in on the left. These are OKR philosophy. These are quarterly business outcomes coming in. We then have the product teams that are implementing these business outcomes, and this doesn't necessarily need to be I.T., this could be outside of I.T.

And there will be a number of product teams, and there is a control tribe associated to that value stream. So view the control tribe as a secondary team. In Disciplined Agile, Scott Ambler has the concept of secondary teams, because you've got specialists, you can't - there's not enough specialists to have a one-to-one relationship. That's not a one-to-one. That's a many-to-one. So this is like a secondary team, and it's continuous everything, emergent architecture, emergent delivery, emergent control, and we have a tool that helps support the conversations. Very much in the order of people, process, tool - in that order.

We have a menu of risk stories. We have over 300 standards in the bank, and so we need a way of codifying that and previously it's up to up to a, an Agile team lead or a project manager to have to go and read 300 standards to figure out what applies to them, in some cases with a bit of help from their control SME.

Now we have it in a menu in the tool. It prompts a conversation with the control tribe. When you have a new business outcome, it's tailored to your context. It's integrated with other tooling like JIRA and Rally, for example, Agile Central, and there's an engagement health indicator. So this is like the Toyota Andon Cord: if there's a problem on the line, somebody can press a button and it's a bit like the Andon Cord pull in Toyota.

And this is a, this is a screenshot of the control tool. On the left hand side, you can see the products that are under development. On the right hand side, you've got a view of the control tribe. You've got a control tribe view on the right. Now, this is too small for you to be able to see the detail, but suffice to say that we're kind of, we're visualizing work in progress here. We're visualizing the state of the health of the system on that picture.

And so the red on the right hand side, that's the Andon Cord pull. So you see those red circles on the right? That's where someone said the engagement health is no good. So, for example, Information Security are not engaging, and then we can follow up and take corrective action on that. And then my last slide. So this is, in terms of business agility, this is an example of an obeya room, performance room where we visualize work in progress.

This is Barclays Partner Finance. So if you buy a Tesla or an Apple product on finance in the United Kingdom, it's Barclays providing the financing. On the left hand side, there is an A3 sheet of paper, which is the CEO's top five priorities and the CEO and his direct stand in this room every two weeks, and every and, and daily the, all of the teams stand in this room. And so everybody gets to see from the left, from the CEO's priorities, all the way through to the green on the right, you've got the teams and you've got burn ups. So you've got Hoshin Kanri - you've got strategy alignment. So if you're a team member, you're working on something on the right, you can trace what that is back to one of five top priorities. So in terms of business agility, this is an example of business agility.

So to wrap up, in order to have speed, you've got to have good brakes. You've got to have good control. The better your brakes, the faster you can go.

Thank you.

Jonathan Smart

Head of Development Services @ Barclays

Jon is leading on agile ways of working being the default approach to how we approach change, across Barclays Group, with 120,000 colleagues. Jon has 20+ years experience of taking and leading an agile approach to change in Financial Services, starting out as a developer on the trading floor. Prior to this role, Jon was leading Derivatives Technology which had a large regulatory book of work which was delivered with agile principles and practices. He and his team is the winner in the category of “Best Internal Agile Team” & “Most Valued Agile Professional (UK) (Runner Up)” at the Agile Awards 2016.