So, thank you very much for inviting me to agile days. I think this is the second time. I spoke in 2010 in November, the last one. So thanks for inviting me back and I'm going to talk about multiple speeds in parallel and the exam question. So, the theme, the perspective for this part of the agile days is relationship. And the questions are different agile progress through the organization? How to be synchronized at the same level of maturity?
So, this is the perspective. This is the theme for this part of the agile days.This is the exam question. So I'm going to try to address this question and if we take a closer look at this question. How to be synchronized at the same level of maturity for agile across santander? So I'm going to question that question. So there is an implicit assumption in that question that there should be synchronization. So I'm going to answer a slightly different question, which is, should we be synchronized at the same level of maturity? And then there's the word maturity. So I'm going to take a closer look at that word: maturity uh, because I'm not really sure what agile maturity means and I'm not really sure how you measure that so um.
So I'm going to share some views on how I might approach that topic and some advice and some suggestions, and also I'm going to take a look at the words agile progress, because again you know what what does that mean? What is agile progress? Is agile progress actually benefit to Santander? So I'm going to take a closer look at that question as well.
So, first of all around the question, should we be synchronized at the same level of maturity? The short answer is yes and no, a typical answer it depends. So I think the answer is both yes and no, depending on how you look at the question and how you're approaching this topic and how you're thinking about this topic.
So, let's take a closer look at both the yes and the no, and this is the topic of multiple speeds in parallel. So if you imagine a motorway, if you imagine you've got a slow lane on the outside, you've got a medium speed lane in the middle and you've got a fast lane on the inside. So if we take the scenario of IT teams and in quotes the business, and if we do agile in IT only we run the risk of having faster IT teams. So you can see there where we've got the green. The green teams in the fast lane we've got the yellow teams in the slower lane. If we are focused on improving ways of working in IT only. I would say that is not a good thing, because obviously what's going to happen. There is Technology teams might be running soon, might be running quicker time to value. However, the impediments outside of information technology are not being identified and alleviated, so it may be that there's still a lot of bureaucracy, a lot of impediments outside of IT that could be onboarding, it could be hiring, it could be governance committees, it could be the budget process, the funding process, the financial process. It could be an internal audit, it could be procurement.
There are a whole number of other impediments outside of IT. So I think multiple speeds in parallel in this context is not a good idea and so synchronizing across role-based silos aligns to value. Should you? Yes, absolutely! Absolutely organizations, should be synchronizing across role-based silos aligned to the flow of value you can see on the left-hand side there we've got a couple of teams are actually going backwards, they're going in the opposite direction to the direction we want them to go in.
So we want to be working together as our business. So, let's take a look at this scenario. If you ever find yourself saying the business, piece of advice, try saying our business instead. It shouldn't be IT and the business. Try saying our business so rather than what does the business want? Try saying what does our business want? Just that subtle, psychological framing in terms of our business?
So now imagine you have multi-disciplinary teams genuinely multi-disciplinary teams, product pricing, marketing, front office, IT, finance skills that you need in the team to be able to get the job done. Do you want to have multiple speeds in parallel? Yes, absolutely you do. You will have some teams because of the environment, because of the culture, maybe because of the technology are able to go faster. They're able to go quicker in the context of IT. It could be mobile phone development. It could be web development in the fast lane able to go quicker. In the slow lane you might have core banking. You might have mainframe. You might have third-party systems where it is harder to have the same the same short lead time.
However, what you can compare is the improvement trend over time. So if a team who are realizing value every two weeks start realizing that value every one week, that is the same as a team who've gone from six months to three months. In both cases, the time to value has halved, so the team is now has now doubled their throughput by going from six months to three months or from two weeks to one week. So the improvement trend is the same. So you can compare the improvement trend, even if the absolute values are different.
So in this scenario we do want multiple speeds in parallel. Again, we've got different culture, different environment, different backgrounds. I know that Santander is has had quite a lot of acquisitions over its lifetime. There will be different cultures so along the bottom synchronized across business units and countries. No, we don't want to try to force everybody to go at the same speed.
We don't want to force everyone to have the same level of maturity. Your context is unique. Santander context in its entirety is unique. Santander Poland is different from Santander Mexico different from Santander, Spain and UK. The investment bank is different to the retail bank. Mortgages is different to fx trading or to debt financing or to corporate financing. So you will you have to acknowledge the environment that you're in start, where you are now.
So in this scenario, no, we don't want to synchronize. If we take a look at the an anti-pattern here of trying to synchronize across business units and countries, and this is something that I that I see some companies try to do. This is an anti-pattern and, as you can see on the right hand side here. If we try to have everybody synchronized at the same time, it's like it's a big bang transformation. It turns out to be a big bang transformation. I've seen sure we've all seen, heard about companies who tried to do this. It's an anti-pattern, a capital T transformation, we're all going to go agile tomorrow or we're we're all going to be 40% of all teams are going to be agile by the end of year 1 type thing. It's a mistake that I've made I've learned the hard way. I have made this mistake in the past. I have tried to try to have done too much too soon. What happens is you end up with new labels on the same old behavior. It's think big, start big, then slow, and it's not applying agility to agility. We need to be nimble. We need to exhibit agility around how we approach the topic of agility.
Now, let's take a closer look at the words, maturity and agile progress. Let's try and unpack these words a bit and we're going to take a look at three anti-patterns and patterns. An anti-pattern is a headwind and a pattern is a tailwind.
First of all, do you want to do? Or are you doing an agile transformation? So I know that you are, and my advice is don't. And this is you know I previously had the job title of head of the agile transformation. We were previously doing an agile transformation. My number one lesson learned from having done an agile transformation. If you want to do an agile transformation, don't do an agile transformation and that way you will exhibit agility instead focus on the outcomes.
Agile is not the goal, agile and lean, and devops and systems thinking and theory of constraints and design thinking and so on and so on and so on are tools in the toolbox. Tools in the toolbox which help you to achieve a set of outcomes. So my advice is, focus on the outcomes first and foremost.
The outcomes that I have found to work in every organization that I have worked with, or we are supporting at the moment, are as follows: The first one is better, which is quality. This is building quality in, rather than inspecting it in later. Value, which is unique. It's unique to Santander and it's unique to each of your business units. Your value streams. OKRs, are a good way to measure value in my opinion. Sooner is the heart of agile and lean. It is time from concept to cache time, to learning minimizing time to learning and value its throughput and its flow efficiency.
Most large organizations have a flow efficiency of 10 or less, which means that work is waiting 90 percent of the time. Safer is continuous compliance. It's agile, not fragile. It's gdpr information security, not leaking your customer data onto the internet and happier which is happier customers, colleagues, citizens and climate because improving ways of working is not at any cost to society or to the planet.
So this is a balanced set of outcomes, and it's a word balance is very important here, because companies who do this not well with a focus on lead time, a focus on faster rather than sooner. What we see is quality goes down and happiness goes down. If the focus is only on velocity is only on being a feature factory producing widgets more quickly, typically, quality goes down and happiness goes down. So it's really important to have a balanced set of outcomes to avoid the law of unintended consequences.
In terms of the size of the prize uh so previously, after three years across tens of thousands of people. The benefit that we saw was a 20 times improvement in quality three times improvement on average on time to value and time to learning the best teams were 20 times sooner. We saw a positive compliance trend, a reduced impact radius. So if something went wrong, it was a whimper rather than the bang and subject matter experts were spending 80% of their time proactively instead of reactively and we saw the highest colleague engagement and a positive client net promoter score trend.
The anti-pattern is agile, lean, devops cloud for the sake of agile, lean, devops or cloud. It's agile is not the goal. Agile is a means to an end, and it's not only agile, it's not agile or waterfall, it's agile and lean. So if your work is repetitive and knowable, that is the sweet spot for lean, as in lean production. If your work is unique and unknowable product development, that's the sweet spot for agility. I prefer to use the term ways of working, because ways of working is more inclusive.
And this is what you measure and visualize. I recommend, I advise that the outcomes are what you measure and visualize. These are deliberately grayed out. These are real examples from the past. The one on the left went to senior leaders once a month with a trend and the one on the right was a real-time dashboard with more than 100 measures in it and you could drill up drill down by team, team of teams, value streams, business units.
A positive trend in the balanced outcomes is ways of working progress. So unpacking that term agile progress. It's not how many teams are using jira and jenkins. It's not how many teams have automated testing would be my advice. What I would advise is that the definition of maturity and the definition of ways of working progress is the trend on the outcomes for which you are using, agile or lean, or devops or systems, thinking or theory of constraints or design thinking and so on
Number two, do you want to scale agile? Don't is my advice. If you want to scale agile, don't scale agile, instead continuously descale the work end to end. That end-to-end point is important. Our business, not just IT. Optimizing in IT only will become a local optimization. Now there may be some low hanging fruit. There may be some benefits and some efficiencies. After not very long, it will become a local optimization. It's a case of strengthening something which is no longer the weakest link in the chain. The biggest impediment to quality value time to value safety and happiness will probably be upstream, it will probably be the funding process, the pmo process, how the work enters the pipeline, the system of work in the first place. That's probably where the impediment will be next in terms of the most value or it might be to do with working across role-based silos. suggestion advice, pattern achieve big through small and I would advise achieving big through well-formed small and invite over inflict it's important that people have agency that people feel in control rather than having a mandate imposed upon them.
So we're going to take a closer look at this. This is the diffusion of innovation curve everett rogers 1962. There are 508 studies of how people embrace change on the left of this normal distribution. You have innovators, 2.5 of the population of typically any group of people. Then you have your early adopters, 13.5 percent two standard deviations from the mean. Then you have your early majority, your late majority and finally, your laggards.
Your innovators and early adopters are motivated by scarcity, the first to have a tesla, the first to have an apple watch. Don't mind if it's buggy. Don't mind if it's got a range of 75 miles, that's okay! Uh! You know we like being first uh have a bit of a risk appetite, probably like adrenaline sports, and then you have crossing the chasm in order to cross the chasm, you need to generate social proof. The early majority and the late majority are motivated by social proof and recognition and incentivization. So you have to communicate, communicate, communicate and do lots of storytelling, and then you have your laggards. Your laggards are hell. No, no. Thank you. Um! Listen to the laggards, listen to what the critics, the cynics have to say. Probably some useful points in there, however, don't put any energy behind convincing anyone of anything. The words convince and resistance should not enter your vocabulary if you're going about change the right way, instead put all of your energy behind the innovators and prove it in context.
When you draw this normal distribution as a cumulative distribution over time, it's an s curve. Now this is as close to physics as human behavior comes. Obviously, human behavior is not physics, but I have seen this. I have learned this the hard way. Time and again, people embrace change with an S curve profile. The gradient to change is low to start with and then and then it steepens, as you have generated social proof as you've proven it in your context.
So mistake I’ve made here is to have too steep a line to try to do too much too soon, and if you do that, you have new labels on the same old behavior. So with your s-curve, what I would advise, especially with an our business perspective. Mindset start small. Apply agility to agility. Have your bubble of amazing and maybe this is maybe where you're starting to engage with the business unit or you need to go back and engage with the business unit with our business. Have your bubble of awesome. I would involve somebody from finance someone from internal audit, someone from hr at least one person. Invite them in because otherwise you'll have to go back and play catch up later, which will be a whole lot harde.
Once you've generated some social proof with your multi-disciplinary team. Then you have your second multi-disciplinary team and then you can start to increase the gradient. So then it's four and then it's eight and then it's 10 and then it's 20 and then 30 40 50. You can, as you prove it and as you create a path through the organization, you can increase the gradient and it's not just one s-curve, because if you think about it, a number of s-curves is still an s-curve. Now i wouldn't advise to have loads, but you can a pattern that i have found to work is you can have multiple s-curves. Typically aligned by the flow of value so, for example, mortgages everyday banking, markets, debt financing, high net worth individuals, payments. Maybe some infrastructure type stuff, like cloud, you have an s curve because your context is unique. The context in mortgages, I'm pretty sure is going to be different from the context in markets.
So you can have multiple s-curves. So do we want to synchronize in the value stream? Yes, we do. Do we want to synchronize in mortgages i.t plus business, our business? Yes, we do advice, start small and multidisciplinary. Do we want to synchronize across the value streams? No, my advice is we don't your context is unique. The pace of change in markets will probably be different from the pace of change in mortgages or everyday banking. Do we want to coordinate across the value streams? Yes, absolutely we do. We want to have the best of centralized and decentralized. We want to have federated and a good way to achieve that is through ways of working centers of enablement. Those words are intentional ways of working is inclusive. It's agile, plus lean, plus design thinking. In some cases, even smaller waterfalls. If there's a part of Santander, where there's been some failed agile transformation in the past, agiles got baggage. It’s a dirty word. You know people are resisting that topic. Try smaller waterfalls, 12 month waterfall to a six month waterfall, to a three month waterfall to a one month waterfall before you know it, teams are exhibiting agility without using the a word and a hub and spoke pattern for the ways of working CEOs. I find works well, it's infinitely scalable one for the group, one for santander group, ideally reporting into the absolute ideally into the group COO or into the xco somehow, so that remit is across the whole company not just IT.
Do you want to have shared outcomes across the value streams? Yes, absolutely you do. For example, quality value time to value safety and happiness, and there has to be incentivization. There has to be an incentive again across Santander, not only in technology. If there isn't an incentivization outside of technology. Very clearly, you will be limited in your ability to overcome impediments, to quality value. time to value, safety and happiness, and then what i would recommend is divide and conquer on the enablers. So an enabler is something which helps you have better quality, more value, more quickly and so on.
So, for example, mortgages might go first on experimenting with leadership. Coaching markets might go first on okr adoption, for example Get it working in one of the value streams in one of the business lines and then divide and conquer so then share it across Santander with coordination.
People have a limited velocity to unlearn and relearn. Very importantly, the pace of change is determined by the speed of unlearning. You cannot force the pace of change, even if you think you are forcing the pace of change, you're not. I've made this mistake. We have new labels on the same old behavior and the outcomes didn't improve. In order to have a sooner speed of unlearning. What do you think the number one thing is that you need for people to unlearn to be willing to experiment. It's psychological safety, psychological safety. So if you want to speed up your pace of change, it's a case of focusing on the amount of psychological safety. Nurturing culture, nurturing an environment within which people can experiment and can intelligently fail without any fear.
So the anti-pattern here is think big, start big, learn slow inflict over invite and a lack of psychological safety. This is an anti-pattern. This gentleman is here to install agile viewing agile is like an operating system update. It's not about it. It's not about process. It's not about method. It is 80% culture, improving ways of working, improving outcomes as an organization. My rule of thumb, it's 80 culture, it's only 20 process and tooling.
So again, psychological safety role, modeling an emergent mindset acknowledging that the future is not knowable, coaching leaders as coaches, the coaching carter, the improvement carter from mike rother, it's mostly about nurturing the right environment for experimentation and learning.
And then finally, number three is: Do you want to create a Digital Feature Factory? No, of course you don't. So go slower to go faster or you will end up going slower whether you like it or not .And so this is a a focus on velocity. We hit our target of 60 arrows a minute firing arrows out into the ether. Who knows if they're valuable or not. Making the wrong thing faster, makes you wronger. Good luck with the translation on that. That’s bad grammar! That's a made-up word!
So, instead we want to hit an actual business goal and we want to hit it with the least arrows, with the fewest arrows. We want the fewest amount of story points um. I'm not a fan of story points myself, but we want the fewest stories. We want the most value in the shortest time with the least effort. “If you want to go fast, go alone. If you want to go far, go together” to to quote that well-known saying, and what i'm referring to here is our business. If you want to go far, go together.
So to wrap up impediments are not in the path impediments are the path your job is to go from impediment to impediment to impediment and to alleviate it. They are not in your way. They are your way and improving daily work is as important as daily work, so it's really important to be including some time in your day and your week to be continuously improving aligned to the outcomes.
Quick recap start with the why our business, why, over agile for agile sake, focus on outcomes, for example, better value to say for happier or whatever outcomes work for you? That is your measure of success, not agile. Number three, incentivize improvement across the whole organization invite over inflict it's 80 culture. Number four, I would advise calling it ways of working rather than agile. I would love it suggestion, take it or leave it. I would love it if, in a year's time, this conference is called ways of working days rather than agile days, because it's agile lean culture, theory of constraints, customer experience, employee experience, agile is not the goal. Number five, achieve big through small nurture those bubbles of awesome. At the beginning of the s-curve, a federated ways of working center of enablement, providing servant, leadership and coordination, providing support across santander go slower to go faster, valuativity over velocity, most value in the shortest time with the least effort.
And finally create a learning organization impediments are The path - and you are never done improving, there is no maturity. There is no level five in the maturity. You're never done improving on your trends on the outcome. Thank you very much.