Yes, I can hear you loud and clear. So thank you for having me. Can you hear me as well?
Yes, we having you, we hearing you very great. So I had a talk before with AirBoss and we talked also about some agile methodologies. They're doing PI planning, other stuff. I also worked before as a scrum master agile coach at some automotive companies in Germany. So I'm very interested now in hearing what's the impact of agile from the perspective of Rabobank. And so let's see what you have for us. Thank you. Okay,
Well, thank you. I also enjoyed the last discussion on the previous presentation on agile, because that's exactly one of the, or the, the main topic that I'm gonna take you through just quickly need to find my presentation back just a second, because you see it. And my thought will be first on diving a little bit into the reality of working agile and what that meant for us Rabobank and specifically the identity and access management department has been working agile, as we say, from 2017 onwards. And that has, has really taken us some time to do. And when you consider agile, then my reference a couple of years ago were all the fantastic stories of the tech companies that are working agile directly interfacing with users and immediately adapting their development to the, the user needs doing really quick AB testing for example.
And when we started in 2017, we sent everybody to a, a agile training. So we had product owner trainings, and then we started on agile, but we found out a couple of things. For example, what we learned in 2017 was that there are a number of things or that, that at least three groups here. So I split here up the management, the teams and the product owners, cuz there are a distinct role within agile and from my own analysis, looking back, we've seen that in the past, when you talk about agile and saying we're moving to an agile way of working, it seems that management hears that things will go faster. Quality will improve. Sometimes they also hear that cost will go down and they also expect less management because a lot of agile also comes down to empowering the teams and, and auto long what our teams heard.
And we found out through conversations is that they, they thought that would, this would give them a lot of independence and freedom. And what they also learned from agile is that in an agile way of working, you work on the items that have the most priority that are on the top of your back loss. So that sometimes translated also in the idea that there is no planning anymore and there will be no project managers. And we cannot tell you when it's done because we work from this backlog. So the teams had the sense of, we can really start working on the most important things that they're not that much strengths attached. And then we have people stepping up to the role of product owner. They liked the idea that they were gonna be in charge. They were also kind of flattered by the statements that it's the most difficult role there is.
And that kind of continued until that difficulty really appeared. So three, four years ago, we started off with this, this basic understanding and over the, the, the months and the years that followed, we found out that actually on the things that we thought it was, we found out that when you work agile, the management is actually never done because it's not letting go of a team it's actually stepping in and supporting a team, but also figuring out what the next step is that a team needs to make. What type of support do they need, figuring out how to work together with the scrum masters on that. So there was actually a lot additional time spent with teams because we're moving away from Excel's deadlines and deliverables to understanding the work, coming up with the story points, getting the predictions sprint after sprint, the teams found out that initially, but later on increasingly the management style really adapted to agile.
So in, in our context, we had parts of the organization that were going through a massive agile transformation while other parts were still working in the current or old way of working, be it lean or waterfall or other types of working. So also, and I think that's typical for any large organizational change. Initially teams respond and are kind of a bit hesitant and they want to see what actually is gonna happen. Is this not just another reorganization? So it also took management quite some time to kind of adapt their own style reflected to the teams that was being picked up with the teams. The teams also found out that half of the rituals in agile have nothing to do with the work in the sense of what kind of code are you gonna build, but are actually more on how do you work and how do you work together?
So that, that took a mind shift and also quite some effort in the teams to work on and the product owners in the end. Well, they found out that although they are in charge, nobody actually really knows, but in the agile methodology, in the product owner is where the buck stops because he controls the backlog. And then you have to understand that when we stepped into this agile way of working the product owner was of course learning how to work with that backlog towards the teams. The teams also had to work with the backlog and where in the past, they were happy to help colleagues who just gave them a call and said, can you fix this? And that for me, they now had to assess how much work that was because when it came above a certain threshold, it had to go through the product owner.
And in the beginning we saw that the product owner had a really nice backlog. And then after a couple of sprints, he found out that actually not that much of the top priority items were done and he needed to converse with the team and discuss with them. And then he found out they were actually working on other things. So there's a lot of work done on how does the workflow to the teams who talks to whom about what? And in that sense, the product owner really is the most challenging role because he has knowledge on the product that's being built. He has to keep up to speed with the team, what they're working on, how they're doing, but he also has to manage the stakeholders and get them them in line. So that kind of happens over the course of two to three years from the happy picture of agile and what it will bring us to, how we found out that, that it actually works in practice.
And looking back, I think one of the key things is here to understand your current way of working your starting points. And for us, this sometimes felt like ever we're playing a soccer game. And I think that's recognizable for any large corporation with a history of a couple of decades in it that the people are fixed in teams. There was usually a large program or a couple of projects. They were coming up with the new developments, the innovations, and basically the teams operated and were quite stringently instructed and scientific management played a big part here in, in how you organize. But also in our case, as a bank, we are heavily regulated. There's a lot of focus on compliance. So in our context, that was even more emphasis on control on checking. So I think a couple of years ago it felt a bit like this.
We are working together, but we didn't have really control and empowerment to the people and the engineers in the team, actually that was a couple of levels up. And that had the risk of disconnect between leadership and teams executing the work. It's definitely had the risk of not taking ownership. So handing over from one to the other was a challenge. So that's, that's quite a, a static way, but it, it worked, it helped us over the past couple of decades to organize our business, to get things done. And we started off with that, that part to move that into an agile way of working. And then we also found out that one big chunk of work is to look to the insights and manage your teams, your product owners, your management itself, and evolve that. But actually we found out that it delivery in a large corporate really has a very long way.
Lots of teams work together before you in the end, actually reach the end user. And I, I liked what the, the guys from Airbus set at the end keep the end user remind. What we found out is that agile emphasizes that so greatly that it really helped us to first engage with ourselves. And then with the teams on the question who is actually the user and we created customer journeys because that's also a part of the, the agile way of working for us. We found out that people that we thought were the user were actually not the user, but other people worked. So that was kind of an ongoing development, but the environment in which you work is also of great impact on, on how red agile will work and what levers you need to pull to get things rolling. So I think when we were halfway into this transition, we sat down and we said, no, how is this agile gonna work for us?
And I think that was the point where we stepped back from the rituals, the things you do in agile, like a review, sprint planning, et cetera. We said, let's have a closer look at the agile principles. What do we aim to achieve for, and out of that, a concept was born, what we now call awesome autonomous teams and two colleagues of mine dove into that and really develop that concept. And it's in the name. We want to have teams that are awesome and autonomy and have autonomy. They can decide for themselves. They also have the skills and capabilities to do so. And that meant that from the soccer table that I showed you before, where the puppets are connected to the sticks and other people are moving, the handles, what we want to move towards is more like a soccer team. That's very dynamic, very adaptable to the advisory or the other player by using this image.
I'm not indicating that our software engineers are small children, but I do think there's great power in creativity and playfulness when you're working in it and you need to solve difficult problems. And the idea was also to empower our people, to give them more autonomy, to apply that creativity and to use that, to solve the problems. And as in this picture, it's like management product owners and scrum masters tying the shoelaces of our key players. And then they go off and play. They compete, they complete the match and they get the things done. And in agile, I think that's also a part where it's much more about a servant leadership putting the customer first and seeing what is needed to get there. And in the awesome autonomous teams that we created, there were a number of key factors that we put as instrumental to development and success that was initially the reliability.
So we wanted them to be predictable, say what you do and do what you say. We wanted to improve the quality. So that's on code code checks, removing technical depth, the customer first. So customer value was very important, but also continuous improvement. So on the backlog, we always said, there's a prioritized backlog that you need to do, but there's always an X percentage that you use for innovation and improvement and whatever you earn through those improvements, you can spend the next sprint yourself. And this evolved over time because it's a dynamic dynamic development. So coming back to, to agile and the impact it had on security, I think for us, it's very important to realize that agile is created for a specific type of question, complex questions. So ticket processing, for example, do not apply an agile way of working, but go for lean or some other operational methods. But we also found out that although there's an end user, there are many stakeholders and security has a lot of them. So the average employee is an end user in the sense they need authorizations and accounts, but the DevOps teams are actually an even bigger user because they need our identity and access management services to connect it and get things working.
And if you start working on agile, it's, it works fairly well quite quickly in the scope that you can control, but it's especially the scaling out. That's a challenge. So when the previous presenters mentioned that the PI planning and we, we started with what we call quarterly CCLO refu. So that's like a, a PI planning and we see that that is scaling up. So roughly every six to nine months we find out, okay, we can do it for our team. Now, can we do it for our department? And if we can do it for our department, can we do it for our group? And if we can do it for our group and, and that scales up in a model that in our bank is called simplified. That skill also agile is, is a, a mindset. So what I mentioned about the principles it's is really a principle based approach.
So going through the rituals helps, but it's actually a tool, not a means in itself. So what we've seen also is that, especially in the first two years, there was the tendency when there were high priority projects or, or high risk projects to step in as a management and say, this needs to be done first, we'll create a project team and we call it a feature team because then it fits in the agile terminology, but we'll take over. And that is something where we really had to restrict ourself as management and say, no, let, let, let's see what the process does here. We'll closely monitor it. But if we want the teams to grow in autonomy to apply this agile way of working, we shouldn't step in after half a year, because then the response will be if an ah, yeah. Autonomy, but when it gets a little bit scary, people will step in again.
So that's, that's different. And in that sense, it is a culture change, but did security improve in our case? Yes, it did. Even when working from home to, in the, in the COVID era, what we saw is that over the years, the, the engineers get challenged to think out of the box. They're not working in a project on a little bit. That is part of a waterfall planning. We see that they're taking ownership of the products, the process, the functions. So the deployments also become more coherent. They they're starting to see the bigger picture and they're growing. And that's a good thing for maturity, for security as well. Working agile also means that we can make adjustments faster. But in addition to that also have the conversations earlier on what is being asked of us now, what does this mean for the backlog? So where we in the past sometimes would adopt an additional project and do that in the weekends.
Now it's more, much more transparent and visible. So it's also clear when we deprioritize security items on the backlog. So that discussion is, is really clear and it helps also the, the business to make a more informed risk decision on how to prioritize work. Now, obviously the feedback loop is shorter. We automate more because working in the sprint and agile, including in DevOps way of working also means that the teams are faced with the results of their coding. So incidents are immediately routed to the team. We've seen a lot of the effort in the beginning phases of the teams was focused on solving incidents and that helped them for the next improvements to include monitoring codes and improve that over time and make sure that their code improved also security wise and with the product owner, there's one person overseeing both the team and the product that's being built.
So I think in the end, what we've seen by adopting this way of working, we had to go through or, or over some of the hurdles that we came across. But I think in the end, security is really about people making the smart decisions and implementing technology in the right way. So if we can improve our people and give them more autonomy, that means that also security security will improve. So our awesome autonomous teams are really helping the bank at the moment to improve identity and access management, to apply and assume breach principles throughout the environment that we have to emphasize monitoring and control in addition to authorization management and preventative controls. And I think in, in general, people appreciate it when they're granted more autonomy, because that gives them the message that they are trusted. And if that goes on par with the skills that they have, and we help them develop those skills, then it really improves a lot of things amongst others. Also security. As a final note, I do have to say, agile is not the holy grill that will answer everything. So the first one, you still need to think very carefully. Where am I does agile apply before you start implementing it? That was what I wanted to share with all of you. I hope it was clear and audible. I realized I had some background noise, a brief while, so I hope that wasn't too distracting and I'm open for questions.
