Jenny Wood

Thanks for selecting me out of what has been an auspicious set of speakers today to come and listen to. Hopefully, you'll be able to walk out of today with some things that might help you understand what we're doing at RBS, but that you can then translate back to your own organizations.

I don't know about you, but as I've watched today's talks, I've actually modified little bits about what I wanted to say and the things that I thought might be relevant. And so I'll try and refer back to some of the things I saw in some of the other speakers' talks about grounding back what we're doing in some of the more detailed work.

So a little bit about RBS. We're not the oldest bank here today. I saw Barclays get up and talk about the fact that they were established in the 1600s, but we were actually established in 1727. And so we have 290 years of history and of doing banking for our customers that we need to work with.

You might recognize some of the brands up on the screen. We are actually a bank of brands, and we service customers in many, many different ways. The two brands you'll probably have heard of are the Royal Bank of Scotland and NatWest. But you may also know about Coutts, you may know about Drummonds, you may know about Holts, our military bank. We're a bank of brands, and that's how we present through to our customers.

We have not just 290 years of history, but we have 19 million customers that we work with, 70,000 employees. And within the areas that I'm interested in, from an Agile and a DevOps perspective, we have 19,000 people. And so that's 19,000 people whose lives we want to make easier, their jobs we want to make easier, and we want to free them up to do the things that they want to do.

And so who am I? Why am I up here talking to you today? My name's Jenny Wood, and within RBS, NatWest, I lead what we call our Performance and Business Management team. In any other organization, my role would be called the COO for technology. So I look after people, finance, IT strategy, all of those sorts of things for technology. I'm actually a technologist by trade, and so have done CIO roles previously. But I choose to actually do the sort of role I do because people and the way that we work within technology is one of the biggest, most fundamental things that is changing today. And if we can set up the organization that exists around technology to free up our technology people to do the right things, then that helps speed up the pace of change.

So as you can hear from my accent, I'm actually not from around here. I live in Edinburgh, and I'm not from around there either. I started my career in banks and telcos in Australia, and have grown up through pure technology.

I giggled when the last speaker said no one's ever written original JCL. I know that when I coded, I never wrote original JCL. I did have a conversation with someone the other day about the fact that the last PL/1 compiler release actually came out last year. When was the last release of Windows 7? Windows 2000?

So, technologist by trade. I don't do technology as you would imagine it anymore. I do ask lots of questions, though. And I do use my technology background as the way that I actually ask questions when we're leading into a change, which in our organization is fundamental.

So why is RBS interested in Agile? Why is RBS interested in DevOps? And part of what Gene asked us to talk about is why, as an organization, is this important to us? And the answer is, in very simple terms, that we can't change as fast as the environment around us is changing.

Up until 20 years ago, we could. The management practices, the way we deployed software, the things we did for our customers, they were adequate for the things that the environment demanded of us. In today's environment, we actually have to be able to deploy software. We have to be able to change the capabilities we give our customers far faster.

And it's not just our customers asking more from us. The regulator within the UK is asking more from us. And so many of you may have heard about open banking. Open banking is where effectively we expose APIs from our products and our customers to certified third parties who can then build applications on top of it. The foundation of how you do banking and the customer experience of banking is changing.

We also, within the UK, know that the way that banks are seen and the way that banks have performed is going to continue. We know that banking, sorry, the interest rates, the economic uncertainty that we face into as we move through Brexit and many of those types of things that as an economy we're moving through, that banking itself isn't the industry it was 20, 30 years ago when the management practices and when the way we worked were adequate.

We also know that technology is changing, and it is fundamentally accelerating at a pace that even many of the technologists can't keep pace with. Our customers and the people who use our services expect more and they're demanding more from us. So we have no choice but to become more agile as an organization.

And so you think about, I talked about the scale of what we're talking about. Where do you start with 19,000 people that you want to take on a journey? And the journey we want to take them on is actually about a customer. It's not about Agile.

And so we're very lucky that our CEO has a belief in leadership. And as part of that leadership culture, we have a leadership methodology that we use called Determined to Lead. Part of Determined to Lead gives us a thing called a physician's model. And in Agile terms, it's very much like a retrospective conversation.

And for us, what we look at is the symptoms the organization has. We look at a diagnosis, we look at the treatment, then we look at the follow-up. Every single leader in RBS is aware of this retrospective cycle and how you think about change, which massively helps when you're on an Agile journey.

So when we started this, we said, "Well, what symptoms are we seeing?" We cost too much, we take too long. The customers aren't liking some of the things that we're giving them, and we're not impacting the experience that they're having as much as we'd like to. Our staff are telling us that it's hard to work here.

And I think if you were in some of the earlier conversations, some of those symptoms are a sign of too much work in progress, when we were listening to Dominica. When I was listening to Chris, what I heard beautifully from Chris was that focus on the customer and how in Jaguar, they're lined up behind delivering the experience that customers of a Jaguar expect.

So when we looked at our diagnosis, we could have turned around and gone, "You know what? That's because we don't have good enough people, or the processes are broken, or because the technology we're using is old." And we actually went, "No. It's because the way we're leading and managing our organization is not allowing the change our organization needs to make."

And so then we looked at a treatment, and I'll talk you through the treatment, as in what we're doing. And one of the things that we're consistently doing is following up and running around that cycle to make sure that we learn what's working and learn what's not working.

Really good when you start looking at test and learn, when you start talking about tolerating failure. The most amazing thing we've ever had is the fact that we can all refer back to a diagram that our leaders have that talks about the learning as an organization we want to do.

Can't forget the middle: bedside manner. And it's about doing it in a collaborative way. And if you think about Agile and DevOps, you talk about servant leadership. And so the bedside manner is the way that you engage in this conversation, and making sure we do it in the right way.

We also, when we started our journey, went out and had a look at what we could learn. I think many of these brands are familiar, many of the books are familiar. We add to them, and we subtract from them as we go on our journey of the things that we learn and read.

But we didn't just want to understand our organization. We wanted to understand learnings from other organizations. And so you'll see that some of them are banks. Some of them are UK banks. Some of them have nothing to do with banking. And some of them are a little bit way out there in the way that they think. And you sit there and go, "Well, what would a regulated bank learn from some of those companies?"

And you might not do things in the same way as some of the companies that are less regulated or in environments that are different, but by actually learning those differences, you start to be able to challenge the way that you do do it.

And so it takes me through to how are we actually embedding agility, and what are we doing?

And so you've probably seen these sorts of mindset diagrams before. Sorry, these sorts of diagrams before about an Agile culture. And sorry, I should have told you at the start, you won't hear me talking about deployment cycles, because for me, it's really about the mindset of setting our engineers free to do the things they need to.

And so for us, Agile starts with a mindset. It starts with how we think about the work we want to do and what's going to add value to our customers. And if it's not adding value to our customers, then why are you doing it? Because if you don't, you end up with too much work in progress. You end up doing the wrong things.

And so then you've got your values. And so if you test the work against your values, if you test the work against the things you as a company feel are important, then you actually give your people a tool where they can say, "This is the right or the wrong thing to do."

We then overlay practices and structures, and then the last thing we look at is tooling. And we're very, very deliberate to make sure that the last things that we look at are practices and tooling. Because we all know the problems in fixing the wrong problem.

I'll come back to the physician's model I spoke about. We actually want to make sure we fix the right problem, not just the symptoms of the problem.

And so as we've worked through this journey, we believe that the greatest leverage we're going to have on our organization is actually through the mindset change. Now, this is really, really uncomfortable. Because as we've rolled out the changes that we have within RBS, I keep getting teams asking me, "What should I do? What processes should I now put in place? What practices should I follow?"

And we've set a very loose set of guardrails for them. We've actually told them what we don't want them to do. And then we've given them access to a whole stack of resources that may help them understand what they should do.

And so the biggest thing we ask of them, and Dominica said this really clearly, and I've seen it in a couple of the posts from today, is we ask them to measure, to work out what's the next thing they need to learn.

And for the first six months, the teams just looked at me and went, "No. You're just not doing anything. You're a program. Tell us what to do." And we went, "No, just measure and tell us what the next thing you need to learn."

Then the second six months, they turned around and they said, "Well, you're not doing something, so I'd better go and do something, because otherwise we're going to get hit with a whole stack of targets, and we better actually take some control of these ourselves."

And they started talking about the way they were automating test cases. They started talking about the way they were using visualization within their work. They started talking about how when they brought teams together for collaboration, they actually started reducing the cycle time.

And over the last 12 months, we've actually seen a massive acceleration in the conversation around the things that they themselves are changing. And sometimes the toolkit may be DevOps, because the right thing to do at that point in time is perhaps automate testing or continuous deployment.

We have one team that's taken 14 weeks off their deployment cycle, taken it from 14 weeks down to hours, and can now blue-green deploy. We have other teams that have simply co-located and taken weeks out of storage requests just by co-locating. We have other teams that have said, "The biggest thing I can do to actually change the way that I'm delivering is actually learn about value slicing as a tool." And so they've started value slicing.

Now, when we're trying to teach a skill, we do it in a standard way. We don't allow them to teach separate skills. But we've got the ability for them to pull it. We're not pushing it on them. Because it's actually all about changing mindsets.

It's not about implementing DevOps, and it's not about implementing Agile. Because if that's all we wanted to do, I could've just rolled out SAFe, I could've rolled out LeSS. We could've actually got a consulting company in to do it all for us. But the problem with doing that is that it doesn't embed, it doesn't sustain, and you don't own it as an organization in the way that we want to own it.

And so, for us, it's required a journey of unlearning. And I talk about unlearning a lot because in an organization like RBS, you've got people who've sometimes only ever worked at RBS. We have a rich history of things that they know of the way that they've seen banking evolve, and I had a great conversation with Gene Kim around the way that banking's evolved, even just in my lifetime.

When I talk to our interns, they sort of look at me a bit blankly about the fact that you couldn't just get money out of anywhere, because banking has evolved from the days when the ledgers were in the branches to the automation that's come through.

And so it's a journey of unlearning. And when you think about the transformational shifts that we are making as an industry, not just from technology, but that we're making as a world, the things that surprise you are the things you didn't know. The things that come through as your biggest competitors aren't the people who do the same things that you're doing better. That's about cost arbitrage.

The people who really fundamentally change the world we're in are the people who see it from a different perspective.

And so I'm not sure how many of you guys watch, and I'm going to get this right, Smarter Every Day. And there's a story about a reverse-steer bicycle. I see some nods in the audience. It's a great YouTube video to watch because Destin Sandlin talks about the fact that one of his mechanics decided to change the way his bike works, okay?

And he learned to ride a bike as a child, and you know that when you pull left, your wheel turns left, and when you pull right, your wheel turns right. So this engineer, this mechanic, decided to change it around, so when you pulled left, the wheel turned right. When you pull right, the wheel turns left.

And he talks about the fact that even having the knowledge that that was happening, even knowing that the world was different for riding a bicycle, that he physically had to do something different, it took him eight months to learn to ride it fluidly.

And the conclusion he drew was that knowledge doesn't equal understanding. So you can know something's different, but actually until you experience it, you don't really understand it's different. And he points out the fact that his son learned to do it in two weeks.

Really, really years of ingrained learning, years of "just do it automatically," versus two years of riding a bike: two weeks. Years: eight months.

It did actually take him a little while to learn how to ride the other way back, but not long. Once he did it, it clicked back in.

At RBS, we actually call that the rubber band effect, because it's easier to do it the way you've always done it. Even if you then go and learn a new skill, you can rubber band back into where you were.

And so one of the things we push for our teams is the fact that they have to spend time unlearning, they have to spend time exploring. That we actually want them to study the work that they're doing.

And so our goals as a program are clear. You'll never actually see me talk about Agile or DevOps internally. That's not what I'm doing. We're not implementing Agile, we're not implementing DevOps, we're not implementing Kanban, LeSS, SAFe, any other mechanism you could find.

We're actually enabling RBS to continuously learn and adapt. We want to delight our customers because, quite frankly, if the work we're doing isn't to delight our customers, with our aspiration being to be number one for customer service, trust, and advocacy, why are we doing it?

We want to free our people from the way that they work today to actually be able to work in a different way, to be able to transform our ways of working. And in doing that, we actually want to reduce our time, cost, and risk of delivery for the business outcomes from the time they're conceived to when they're actually available to our customers and our people.

So what are we actually doing? What's the tangible things that we've changed?

So we're doing a lot of work on continuous planning. So as of next year, we will actually run our portfolio not as projects, but as an end-to-end portfolio, which is planned strategy down. We'll basically, for groups of about 1,000 people, give them a set of investment money, give them their run money, and the business leader, not the technical leader, the business leader will be accountable for delivering all of the outcomes that they have been given that money for.

We're doing a huge investment in continuous delivery, and so we are looking at how, and we're working towards a target aspiration of migrating a significant portion of our estate to cloud. Now, we're not as bold in some of those aspirations as Barclays. We think that there's going to be a workplace conversation around some of it will be public cloud, mixed public cloud, some of it will be mixed private cloud. And we do actually think that there's going to be a portion that's left on physical infrastructure just simply because of the way you invest and the way that those applications work.

And we're also focused on continual improvement, and so measures and metrics. And you'll see us talking to our teams about what the measures are that tell them that they have something to learn, what the measure of throughput is.

We have a long conversation with our teams, and it comes back to some of the things Dominica said earlier about understanding the flow of work. If you're not directly delivering something for the customer, what we want you to do is understand the flow of the work through your teams to make sure you're not impeding the delivery to the customer.

And so great examples are teams like security. And so security is spending a long time understanding the flow of the work. And we know that we have queuing for pen testing. Who doesn't queue for pen testing? And so if we can bring pen testing earlier in the cycle, and we can invest in automation, we know that will speed up the work.

So we're understanding the things we need to change, because if we tried to change everything at once, we actually wouldn't fulfill one of our requirements of our customers, which is that we protect their safety and stability.

And so when we think about it, what we talk about is how we organize our work. So what are we here to do? What are the goals? We then organize our people behind the work, and then the last thing we do is increase our speed of delivery.

And I had a really interesting conversation with some of my team about increasing the speed of delivery because they said, "Isn't that dangerous? Won't you cause problems to stability? What about risk? What about all of those things?" And we actually had to go back to our technology teams and redefine what the work they were doing was. Because work exclusive of those things actually isn't something that can get speeded up.

And so we really focused on making sure that work is about the end outcome for the customer, not just about the functional delivery.

And so you can see down the bottom some of the things that we're moving, and we're about halfway through. Some of these things are time-based. Planning, you can only change on an annual cycle. And so we've known what we wanted to do for about nine months, but it's only as we come into planning for the following year that we can actually start looking at how we change that.

One-size-fits-all governance. We know that we've got streams now that our teams are running, and over 50% of our change goes through some form of standardized change process, which two years ago it didn't. Two years ago, we were having far larger changes and far less ability to take risk on those.

When we look at API adoption, when we look at all of the technical enablers, because you can't do this without technical enablers, we've made fundamental shifts in our API usage as well as the way that we've used cloud.

And so really, the conversation that we're having is a very different conversation to what you'd hear in some organizations. And as a result, it's a little bit frustrating, particularly for our leaders, because we're not telling them what to do. We're not giving them a pattern that they can apply.

And the reason we don't want to do that is because large organizations are very good at following processes. They're very good at rolling out a process, and then you have to follow the process, and it becomes about the process. But that's actually not what we want to create.

What we actually want to create is one of these little kids' bendy snakes that can pivot and change as the environment around us changes. That we can learn what the best tool is, and that we can learn how we as an organization then need to react to it.

And so where did we actually start on this journey? We didn't start in the technology, because by starting in the technology, we may have sped up the wrong things. And so we actually started with our leaders. We started with our executives, and we started getting those teams on board with the sorts of things that we were going to need to change.

We started outside technology, not inside technology. And as a result, we're actually leaving our technologists, who are great at their job, the freedom to improve their job rather than making them work in a way that's not natural for the things that they're doing.

So what are some of the things we have yet to solve?

The challenge with doing a change like this, where you free and empower people, is that balance between standardization and process. And we're almost reaching a tipping point where the enthusiasm to get on may be counterproductive to our ability to have a common language and a common way of doing things.

Metrics. We still struggle with metrics. Any organization like ours thinks that metrics are targets, and so as soon as we ask our technology teams to measure something, they're immediately wary about what we're going to use it for.

And it's going to take us a long time to build the trust with our technology teams that they can actually measure things and not get beaten up for measuring them. And the fact that if we ask them to look at a measure to improve, that no one's going to do a standardized technology governance metric that says, "Here's your target to improve, that we all need to improve 25%." That we actually want them to measure to learn rather than measure to improve. Sorry, rather than measure to target.

We've still yet to solve the people issues around team performance reviews, the way that you meld the external way that you manage people back into an organization of our magnitude.

And then you have the questions down in the technical layer about how do we actually choose the right technical tools to use? Should we choose one toolchain? Should we actually let people have different toolchains as long as they're controlled? We're still grappling with some of those conversations.

There are some schools of thought that go, "One toolchain, and that's it." There are others that go, "What's it really matter if we've got three or four that speed up the work, provided that we've got the controls we need built into them? What we don't want is 60." And so we're still trying to balance that through.

Overall, it's been quite a phenomenal journey. And I know that I talk to my boss, and we had this conversation, and I actually think I've got the best job in the world. Because not very often do you get a chance with an organization the size of RBS to actually allow it to change in a way that you get people walking up to you on the street just going, "It's just fundamentally different now to what it was two years ago."

And we're starting to see those sorts of conversations happening. And so what we want to see, though, is that translating into the way that our customers see us. Because you do these changes for a reason, and the reason we're doing this change is because we want to actually be able to deliver value to our customers faster.

So I'm going to stop for questions. There's five minutes left, I think. And so I'll give you the opportunity for questions.

I did say it wasn't going to be a technical talk. Didn't talk about GitLab or any of the other technologies that you might use.

Q&A

Q: What helped you to stop leading?

A: So in my previous job in a telco, we tried to lead a change through training our people for Agile and DevOps. And we had a whole stack of really enthusiastic people who understood Agile, who went through a mindset change.

And in fact, I had people say to me, "I'm never going to be able to work in another organization after we've done this real shift in the fact that you could have this fundamental change." And then we just couldn't change the environment around them, and they left. Because why work in an organization that doesn't do things sensibly in your mind?

So having the chance to do it a second time, we didn't even start talking to the teams about Agile, getting their hopes up about the fact that we might actually change the organization. We actually spent six months in a back room talking to the people around to make sure we could do particularly the investment changes and the project management changes, because that's often what constrains Agile, the fact that you try and sandwich it into the old world. And it wasn't until we got that agreed that we even started talking about an Agile transformation.

So, learning from past lives.

Any other questions?

Q: Second movement model of continuous, not project-based funding in the industry. How do you adjust that when one part of the business may need more investment than another, which will change how the financial modeling is done in the project?

A: Yeah. We do that anyway, if you think about the way you juggle a portfolio. As a business, you might want to change strategy. I suppose what we're trying to do is make that change of strategy a prioritization call.

And so if we've given Personal a whole stack of money to achieve certain customer experience and certain customer targets, and we choose to take that money away, we're actually making a prioritization call on the outcomes.

What tends to happen today when we do that is we try and tell you to do the same outcomes with less money because you had no view of certainty when we gave you the money, and then we actually put more work into the pipeline.

And so still not there, but the theory is that we'll actually have the exco play at the strategy and priority level, not at the program level. And then they can make calls themselves and flex up and down, and the fear of going over and under on projects sort of disappears a little when it's within a particular business unit.

And so a business unit, we're talking about something like home buying and ownership, which is the unit that looks after how you want to buy a home. And that's business-led through to technology, which is one of the things Gene talked about. How do you get the business buy-in?

Q: You spoke about measurement being a challenge.

A: Yeah.

Q: You also talked about mindset being focused. How do you measure the shift in mindset?

A: Ah. That's a really, really interesting one.

So we do actually have some mindset tools that we roll out, and it's been interesting because whilst no one wants to do the technical DevOps capability tools and share that, they're actually okay with sharing the mindset results, which is really quite bizarre. Because I suspect they think we're not going to target them on mindsets, whereas we might target them on testing automation and practices that they should be doing in their jobs.

And so we've got a really good mindsets tool where we've linked it to the training that you do to develop the mindset, and we ask them to do it as a team. And when they want to focus on something, they've then got the training that they can just pull.

And so one of the things it lets us do, though, in the background, is we've identified systems thinking as a big gap that people want to develop. And so we can now push the training up based on the mindsets tool, and that's been quite successful. We've had about 2,500 of our 19,000 voluntarily through the mindsets tool, which is good.

Q: Sometimes your value streams go outside RBS or RBS technology. How do you bring your "vendor partners" along for the journey?

A: Yeah. Look, and that's something we're grappling with. It's really easy when you've got a big enough domain and they only support that domain. Then you've got teams that stretch across.

The philosophy we're having the conversation about is the same we're using internally. And so if you think about it, our infrastructure services teams stretch across multiple business value chains.

And so what we're asking isn't necessarily for them to change the way that they work unless there's a value in changing the way they work, but to start understanding whether they're in the flow of the work or not.

And if they're only used by one person, we're actually aligning them to that one person. And so we're doing a lot of work to align contracts so that we've got them in the value stream.

And where they're used by multiple people, there's a little bit of tension around who uses the most, but how do we get the best lineup of the resources, and how do we make sure that the fact that you're sharing a service doesn't cause the work to slow down?

Haven't quite cracked it, but I think we'll be okay on that one.

So I'm actually on time. I'm not going to hold you any longer. I will be around for the next two days. Thank you very much for being so attentive. Thank you for those who stood around the side.