Thank you for having me today. It's a pleasure.
I'm here to tell you why and how a bank such as ours, which is thirteen thousand employees in, in Belgium, wants to become more than a bank - and I have only 18 minutes, meaning, and I have like five hours of backlog of stories that I want to tell you passionately. I will make a few shortcuts, and here is the first one.
Let's say a bank for decades is something could describe as a box: structured, organized, orchestrated, in which you can put money, and with certain constraints you can take money.
So that was a bank before now. Since digital culture kicked in, our customers don't function like that anymore. They don't say, "I want to get a mortgage out of the box. How can I fit the box?". Customers say, "I want to buy a home", and they expect us, as a bank, just like any other product, to be there, to adapt ourselves to their experience and to come up with something easy, fast and fun to go with that experience.
Bank, fun...We have some work to do, and - money is fun. So, and also the bank, the way we have been working for years, that we were structured, our hierarchy, a risk averse mindset and so on, had to change. So I joined last January with a few colleagues. One of them is over there filming me right now. We joined in January, and we started the transformation of Agile at Scale in May. Lost like, the track of what I was going to say.
Here is a first step I wanted to share with you: So, January we join, we think about how we can change the bank, the culture, the model, the process, Agile, and all of that. We looked at different models, and this morning we talked about certification - I am certified and no model at all. But I have a very good general culture about many models and frameworks, and I understand what the value is, what you were aiming at, and this is exactly what I encourage you to, to do have a general culture of these models so that you can pick the interesting pieces of these models and frameworks so that they adapt to your organization. Never do the opposite. Don't try to fit your organization orthodoxically in a model. It won't work. That's not the idea.
This is how we did it. First framework that you probably know is a skill, Agile framework SAFe, that we like for the structuring of the portfolio, the three layers. The fact that it tells a story that connects the executive committee, the strategy of the bank, the ambition that we have through investment teams, epics, up to the last story at squad level, which means that when a squad needs to prioritize their backlog, they have an overarching reference of the strategy, what it means, where do I fit in? and they know how to prioritize in a coherent way. The scaled Agile model also allows us to have a coherent prioritization, top down, at any point in time of our entire portfolio. We were lucky enough to, when in general, we did the first workshops we're presenting to our colleagues from the business. This is what we want to go to, were starting from I.T. and we would like to contaminate you over time, over the course of the next three years. Yeah, that's a bit, the word we used. And we were suggesting, like often it's done, proxy product owners, for example, and this idea - but, if we understand well, it would make sense for us, business, to be part of that trip right now. Yeah, of course. But, you know, we don't want to push you. And I said, no, no, no, no, no, no. We want our guys to be there from the start.
And we have two hundred squads today. And it's like one hundred and fifty product owners from the business physically in the squads, in the tribe, in our model, which was absolutely great, and they are currently managing that backlog prioritization in our skilled model as of now.
The second framework that we have used is Spotify, and you know it, it's been referred to very often. It's fine because it comes from music. We use it in a bank, but we like it's because of the following: It's it allows evolution. Today, our tribes are a combination of squads that have a common capability. We did some logical groupings. We have 20 tribes, two hundred squads. These groupings make sense, and for example, we have a tribe around all the assets that touch credit - that I'm talking about assets because this is how we work today. Ideally speaking, you squads should not be asset driven - I will talk about this - but, we have a logical grouping. Over time, my tribes will be able to evolve.
See the metaphor here with the bikes? Let's say, your minimal viable product is a simple bike. I want to provide a bike to my customer. He or she tries it, gives me feedback. That bike is built based on components from the squads here: wheels, frame and accessories. And the tribe here that you see on the picture, can be seen as the tribe of the two-wheeled vehicles. On the long run I want a customer journey based tribe. Imagine my customer journey is, I want to take a biking trip through Brazil.
Some squads will provide you the bike, some will give you the control and support function, like is it legal to go through Brazil, through the mountains, do I have the health insurance papers, and so on and so on. Some other squads will give you the water supply and the, the equipment and so on, and you're covering the full customer journey in a high velocity customer journey based tribe.
So these are the two models that I'm showing here, and we are adding also the large scale scrumming, LeSS, that is bringing that evolution towards feature based squads. I will tell you more in a second.
Transformation tip number two: long term value. Transformations are something big, and, you know, it it takes time. It's not something you've planned over six months. And I'm not saying I have a very detailed plan of your whole transformation right away. Absolutely not. That wouldn't be Agile, of course. What I'm saying is: from the get go, know the long term direction. When you talk to your stakeholders, like the business, talk to them about the customer journey tribes. This is our, our thing. We're not customer journey tribes today, but every time we're likely to deviate, every time we do a retrospective on our transformation so far, and "what do we do next?" Keep your eye on the goal, the end value of our transformation is customer journey tribes, because otherwise you're likely to deviate, to compromise, to really change what you wanted to do initially. So have a long term value you want to reach right away.
This is a story. Today, we are like this: since first of May we have the three layers of scale, we have epics in place, features in place, stories in place with the squads. We have made logical groupings that fit our organization today, and as a result, you see that my squads are sometimes in different tribes, and I have still a lot of orchestration to do between squads, between tribes, because we are asset driven for architectural and port automation reasons.
That's today. We did it, didn't prevent us from starting. We started like this. We do a retrospective at this stage and we know that to go towards my end value of customer journey tribes at the end of this year, we will try to have the first pilots that are shaped a little bit more like a customer journey, maybe not fully yet, because, again, our architecture doesn't allow that, but we'll try to identify squads that are more advanced in DevOps that have a bit of flexibility in their architecture that can deliver fast, independently. The full feature. My full bike. And my tribe will be a customer journey tribe. Something like, "I want to cycle through Brazil." That's 2018, and the next step will then be end of 2019, beginning 2020. More and more tribes that are really fully customer journey driven, with squads they're able to independently deliver high velocity features directly to the customer, and really shortening the whole cycle from strategy to story and and so on. So that is our roadmap.
Let's see. I like the word 'roadmap'. And this is - I could have put it as a transformation tip: do not underestimate the technology agility. We talk a lot about the methods today and the culture and so on, and I understand how it's important we talk about business agility. But if you're in an older industry and especially something like a bank, you have legacy I.T. to take into account and this can really slow down your transformation, the whole automation of your entire architecture, the DevOps in the teams and so on. Don't or, don't underestimate it. And agility culture is something that needs to grow over time.
Transformation tip number three: When I am asked what is it that we did differently? This is my typical answer: you need to know, understand the current culture of your organization when you try to bring Agile at a larger scale. This was the way of addressing the culture in our bank. Over the past decade, one decade, there were several mergers and acquisitions. Every time we did a merge and acquisition there is a few processes, procedures because you want to keep things under control. We need to be compliant with regulations, and we ask people to kindly follow the rules. Several times we did that, and over time their freedom to express themselves and say, "I have an idea. If this was my territory, I would do it like that", and their reflex of empowerment - "I have the space to be empowered", kind of was toned down.
We have great people. I mean, we have excellent recruitment. They recruited me, so, much - but we kind of toned down that whole cultural reflex of speaking up, so the whole empowerment...We think that it needed a bit of a kick. We also have silos. Different customer segments, silos. Different departments, silos. And so we wanted to avoid a situation of a bimodal: two worlds living next to each other, project management on one side and Agile on the other side. We don't believe it would have worked. We wanted everyone to be on the boat together.
So we have pushed everyone in the water.
This is how we did it. May 1st, the Big Bang moment. So that's 2,700 people. Today, our scaled Agile model is 2,700 people, and all these guys were impacted by the following: we switched the entire portfolio to our Agile portfolio. No more projects, no more programs, epics, features, stories. Everyone was speaking the same language. The fact that you develop your stories in Waterfall doesn't really matter. It's about the quarterly agile planning, the fact that we synchronize the commitments and so on. So, portfolio in Agile becomes a single language. My tribes are in place. My tribes today are composed of 80 percent I.T. and 20 percent business because as I said, my business colleague said, we want to be part of it right away. My tribes are in place.
Imagine May first, big banks. Suddenly you're mixing up people that were not necessarily working together before. It had an amazing, very special effect called, "Let's talk to each other", and they started talking to each other! So, this is one of the feedback that came from the floor, they say, "You created chaos, and we had to collaborate to figure it out". The new governance was put in place, so the whole prioritization of the backlog, it trickles down up to the story level.
It works. But if you want to escalate or manage it that governance was in place from day one, too. And one important thing that we decided to do, and we had great support from our HR, is that we move to functions. We didn't want to play the role system, because it allows again for that, my bimodal: yesterday I was a project management, today become a product owner, it's exactly the same thing - said no. First of May, we have mapped your previous function to a new function.
From that day on, you are playing that new function constantly, and that that made a big difference. That whole system also brought feedback from the business saying, "Since you have put this in place, we have more transparency". It's not that Agile resolves things right away, but we know where shit will hit the fan and we can address it. And they really love that. This is absolutely lovely feedback. We were really happy.
So, big bank. The structural elements that federate your people in your transformation, and it's a big kick in the culture. So this is one thing we did, and you're asking yourself, "where do the Agile methods fit in there?", and if you're a coach, you're certainly thinking very hard. This is the waved approach. So first of May, we have a Big Bang approach, and from first of May onwards, every three months, a new wave of roughly 500 people started wave then coaching the methods on the floor adapted to their squads, DevOps coaches as well because I said we invest in automation.
We had Agile Mindset coaches also helping people endorse the new function, and work on the way the tribe is managed, and we had Lean coaches as well, ensuring that we do the right things in the Lean manner. So that was the waved approach. So this is why we did different: Big-Bang to federate the waved approach for the actual methods on the floor. We - actually that guy - Terry can you wave your hands, please. So, Terry has been saying that sentence over and over, "It's going to be chaos". People go, ha ha ha. No, really, it's going to be chaos. But it's a structured chaos, and we we wanted to basically tell people "when it starts hurting, it means you're doing it right". We didn't want to have a clean, proper, thing. And our executive committee, "it has to be a clean plan". No, no, no, no. We told them it's going to be chaos, guys. There are risks with the transformation, but we really think it's the way to go.
It's the right speed to go. And there's a good reason for that chaos. Look how many people are involved. So I said in the scaled Agile model that's 2,700 people, and you if you take the whole ecosystem of demand and support and control functions, it's over three thousand people that were impacted from the 1st of May onwards, 80 percent business, 20 percent - er, 80 percent I.T., 20 percent business. As I said, it's a mix of people.
The tribes will shift to the organization. We mix up the people. We have 100 coaches on the floor helping with that. We have put the means to support that transformation. It was an important decision. It's, it's really needed. And here are a few figures. You see 60 percent predictability. Remember, in the world of project management, you had a project with a very strict plan and it was starting to shift. Then you would add some new resources, but they need to be onboarded so we postponed the plan, and we postponed, and we postponed. And we didn't really have a measure of delay, of of reliability of your plan, because it was a structured replanning. So your predictability was kind of fluffy, a gray zone, the predictability that we have today. So May 1st we have, we are preparing our fourth PIP fifth?. Fourth PIP. 60 percent means when I'm committing to hundred features in the next quarter, I'm a squad, I say, "I'm a tribe. I can - I'm committing to deliver these hundred features".
I'm actually really in a predictable way, delivering sixty today. You can count on the sixty. That's today. The number is growing. My gut feeling is I will hit a plateau in a few months and we will have to adjust the way we do things, but 60 percent at this stage versus the world of before is great. 68 percent is when we ask the people on the floor, "how would you rate your role and adoption of your new role, methods and model that we have at BNP", say, sixty eight percent.
It's not bad at this stage, considering everything that moves. It's pretty good. And we had warned our executive committee that, look, we're changing so many things, it's likely that we might have incidents, because it'll be a little bit messing up with things. And it's absolutely great. We're very proud to say that our incidents actually have dropped, not thanks to Agile, but despite Agile, despite the transformation. It's amazing, and the major incidents have dropped by 30 percent. So major incidents are the ones impacting directly customers. So it's lovely. We're really happy. So, be transparent about the fact that it's going to be chaotic.
My last famous words of the day will be about culture.
Whatever you do in terms of methods, process, roadmap or transformation, that is going to represent 30 percent of your efforts and success. You're pushing your model, your transformation to your organization. 70 percent - and it's just a gut feeling figure as you as you hear it - 70 percent of your transformation will be actually pulled by the people, by your corporate culture. Again, you need to know your current corporate culture, adapt whatever you do to grow it towards the agile. And we mentioned it this morning. Agile is not agility. Agile is the processes, the method, is the, is the, the roadmap, if you want. Agility is that actual mindset that you want to have for people to think Agile, to connect to the customer, to feel at home and bring up their ideas like they would do it for for themselves.
It's about the fail fast and learn fast. In a bank it's a bad word. You don't say fail. It's not allowed. It's collaboration about hierarchy also not necessarily easy. If you had a very hierarchical organization before. It's, it's about workplace culture. You have all these remote access and collaboration and so on. It's about teaching them all of that. It's helping the people to take that on, and we have a role to help them, but they will have to take it, and I really hope that in a year I will come back here and tell you what we did and share my five famous tips about how to grow our enterprise agility culture. And one last thing I wanted to mention about that community. I was inspired this morning. You also have a role of responsibility that you have to make that grow the enterprise agility culture in the world, right?
Thank you for all the nodding and smiles!