 Hi everyone. My name is Fiona Mullan. I'm from Suncorp. We're here to talk about our cultural journey of agile. It was a large transformation program, the largest in the southern hemisphere, and we just want to share with you our journey. I'd like to introduce Phil Abernathy. Phil was instrumental in helping us set up agile from the very beginning. Over to you, Phil. Well, and Fiona works with Suncorp now and has always been, I think, for 17 years. So, Fiona was in charge of the whole change program right from day one, so we're here to share the story. So we're just going to talk about the background, why change and what happened before that, and then what's the adoption strategy we adopted. And that's very important. It's very important to know what adoption strategy you choose as a company. And then we're going to share some experiences, what's and all, so with all the ugly bits as well, and what are the outcomes, and then some tips for success if you're doing it yourself. So, let's talk about Suncorp first of all and give you a little bit of background. So Suncorp is based in Australia and New Zealand, employs 15,000 staff, 9 million customers, 96 billion in assets, and in the top 20 Australian stock exchange. So, large corporation made up of general insurance, banking, life and superannuation products. So that gives you a bit of context of what the organisation looked like. So, the important question was why change? So, when the two companies merged, Suncorp bought a company called Promenade and doubled in size overnight, and they had a huge book that they had to transform in terms of integration. So, they've got legacy systems doubling up for every single system, and literally they wanted to bring them all together, and they had to do it in two years because they'd already committed to the market. So, there was a burning platform for change. Now, having answered the why change, the next question was why Agile? So, let's just look at the alternatives out there. So, what we're going to talk about later on as you will see is that Agile is a strategic choice. Now, if you want to do something faster, better and cheaper, or better, faster and cheaper, you can say we want to do partnering. So, we'll go offshore. We'll move to the cloud. So, these are strategic choices that companies can make. But what is the strategic choice to increase productivity today? What is there? So, there's Lean and there's Agile. And seven years ago, Lean was not that big in the software world, so it was Agile by default. And we'll talk later on about how it does not have to be one. You don't have to say we're doing Agile or partnering, or Agile or offshoring. You can do all of them. You can go to the cloud, you can partner, and you can do Agile. And Agile was chosen as part of the strategy. Yeah, absolutely right. So, as Phil touched on, this was all linked back to the fact that there was a burning platform of integration that needed to happen. We had a CIO who joined us, so as we said, they're a leader with the vision. And Jeff was very passionate about if we don't change how we operate and change all the human systems around that to support it, there is no way we're going to integrate these two companies. And so he announced to the market that we're going to do Agile. And so that was in 2007, May for memory. And at the end of 2007, a formal change program was set up because he identified that you can't just say we're going to do something, you need to set up all the systems around it to make it successful. So, then we came to the adoption strategy and we had a conversation with Jeff as well at that time. So, there's a little story behind the burning boats. Alexander with his army came all the way up to the borders of India in those days. In Pakistan and it was on the Indus River. So, he sailed down the Indus with around 30,000 of his troops and he had a few of the elephants along and everything. And he camped along the Indus on the India side of the Indus, so not the European side of the Indus. And, yeah, and there was the Indian army facing him of half a million soldiers with elephants and the works. 30,000, half a million. So, what Alexander did in the night, he sent his generals out and they burned all their own boats. So, no choice. Stand on the river bank and fight. And they did defeat the Indian army, by the way. So, and that was it. After that, he and his men were too tired and he pushed off back. He didn't come any further. But that's the strategy that Jeff adopted. And this is so important. He said, there is no choice. There is no going back. It's not like, oh, we're going to try it. He had done it before. He'd seen it work. He believed it. Now we're going to do it and there's only one way. There is no other way and it applies to every single project and piece of work, without any exceptions. So, that was very important. The strategy was very important. We've worked with other clients since then. And a lot of them are, you know, we'll just do a little agile. Then they have hybrid agile. What is hybrid agile? Tragile. Yes. Tragile or fragile or something like this. But this was very clearly, that's the way we're going and there's no coming back. So, a formal change program was kicked off, as we mentioned before. And we set it up around the five streams of work. So, the first one is people. And that was really around what's the culture we're going to need moving forward to support this agile way of working. What are the human systems we need to set up? How do we recruit these particular skills into SunCorp? Because as you can imagine at the time, it was very hard to get those skills, especially when you weren't sure what you were really looking for in the early days. Capability. This was the Agile Academy and we'll talk a lot more about coaching and also Agile Academy a bit later. But that was setting up a world-class training curriculum that provided training to our people for all roles within the organisation. Coaching. That was supplying coaches on the ground to support our people. There's no point having all the training systems in the world, but if your people get back into the real world and have to execute and they don't know how. So, coaching was important, along with the communities of practice. So, how do we have communities that our people can tap into for like-minds? So, we use things like Yammer as a collaboration tool and that was a community. We had facilitation community of practice, business analyst community of practice and they were all set up to support our people. Processes and tools. So, this is really around what's the technology we're going to need moving forward. What are some of the tools we can use, like JIRA for example. The governance structure, infrastructure itself. What are all of those things we need to put in place again around it to make it successful? Metrics and reporting. You know, as we all know, that's really important because there's a lot of money and funding put into delivering a program. So, we had to be able to show our value in that. And an Agile maturity assessment was set up around that and we'll talk more about that later also. And communication. Communication was key and I think sometimes organizations underestimate the power of that. So, communication was paramount to the success. We had communications advisors aligned to every division so that there was standard Agile messages across the executive table and to the teams. They also assisted with making sure that we facilitated having roadshows, organizing brown bag sessions, organizing SBS TV, which was a TV opportunity where people could talk about their success and failures in Agile. But anything to do with communications to get the message out. So, I think the other thing at the top, you'll see Disturb, Discover, Align and Transform. These are the four phases of any change program. And the very first phase is always Disturb. If you don't disturb the status quo, you won't get change happening. So, people were very uncomfortable. They were unhappy. What is this new Agile thing? They thought it's not going to work. It's failed before and lots of disturbance. It's okay. It's part of the journey. If you don't have disturbance, you're never going to change. And then you have to be ready to allow them to discover. And then you have to bring all the different understandings together to align and then transform. And guess what happens at the end of Transform? You start disturbing again. And on and on and on. That's very important. Absolutely. So, impacts and roadblocks. Well, there was many of those. In terms of impacts, we have to think about leaders of the future and what type of leaders we were going to need and what type of leadership style was going to be needed to support this new way of working. And trust me, there was particular leadership styles that weren't conducive for that. Also, too, the way of working for the teams. You know, they were no longer co-located. They were going to be distributed. How are they going to operate as a team together? How are they going to leverage off tools? How are they going to communicate that with all the important questions we had to answer for them? Funding. Funding was a huge issue. So, initially in the program, we had a centralized funding model for coaches. Then we decentralized. So, of course, that created the disturb all over again. So, how you cope with that? That was a huge impact for us. So, a few other things. The first one was the funnel of work. So, if you look at how traditional companies run in a waterfall mode, I talked to a BA who was on 17 consecutive projects at the same time. He was on 17 projects. One was in concert, one was in initiate, but he was on 17 projects. And that's how the work was done. It was shut down the funnel. And then, you know, different projects were in different phases. That wouldn't work with agile. You can't do six projects all with the same team at the same time. Can you? So, we had to throttle the funnel. Who's going to throttle the funnel? Who's going to tell business management that, oh, actually, if you want to go faster, you have to do one thing at a time. And it's such an oxymoron. It doesn't fit in your head. You think, why can't I start more and therefore I'll do more? But it doesn't work that way. So, we started the roadblocks. A fantastic idea, Jeff. This came from the leaders. Wonderful idea, but not now. We're very busy. That was the first one. The second one was, oh, yes, it's really a great idea, but not for this project, because this is actually a regulatory project. And the auditors need, and the government, and, and, and, and. There were 10 reasons, its legacy, why it won't work for their projects. And it really was all bullshit. But we had to use the other streams to communicate at the same time. And the other one that was there was, as Fiona said, a lot of directive, very strong directive leadership, which we're used to saying, do this, do this, and now it had to change. So one of the big challenges we had in 2007 when I joined Fiona's team as an agile coach was, okay, we're ready to start the training. So what's out there? Two courses. Scrum Master Training and TDD. That's it. Nothing, nothing else. There were hundreds of books around, but there was no formal training. There was absolutely nothing in Australia. Now we scoured the world. We went to the U.S., we asked others, can you come, can you do training? But how are we going to train 15,000 people? This is for the entire organization, not just for IT. So we wrote the Agile Academy. I wrote 16 of the 17 courses myself with a group of coaches. The initial quote we got from a company that wrote training was four weeks per course and then three weeks after that to set it, three months after that to set it. So about four months before the course can be released. We applied Agile to it. Every two weeks we released the course in the early version and trained 10 people at a time. So we had 17 courses running in about six months and we've gone through, well currently now the figure I personally trained about 3,500 to 4,000 people because you write the course and train as well and take it forward from there. So we also decided to make it open source. So Jeff put it in a separate company. The entire IP was put separately and made public. We went with four partners who were trained. So we trained the trainers and SoftEd, for example, is a company that currently is one of the partners and they deliver the training to all the rest and the IP is in open source within this company. So the other key point here was the training went from Agile for infrastructure up one level to Agile for the teams, Agile for the business. Then we started the concept. So what do you do when an idea comes in? Agile concept, how do you plan? How do you run iterations? Then there were the technical courses. Then there was Agile architecture. Then there was Agile legacy. Then there was Agile governance. Then there was Agile for leaders. Then there was Agile for non-IT leaders. So by the end of it it was 17 courses. It's a lot. So one two day courses, each one of them, but still a lot to cover. The white papers, the stuff and materials available as well if you want. And just before we move on to that too, there was also Agile facilitation and we identified that there was a huge gap in leaders to actually facilitate, which we underestimated in the beginning. And it's still a burning platform for us today that there's still leaders who struggle with facilitation. So troaching, this is one of the things that worked really well for us. This is the blend of training and coaching. So as Phil talked about, you go into the classroom, you pause for a couple of days and you come back to your day job and then you've got to make it real. Then you've got to work out how to write a story card, how to run a showcase, etc. So it was really important to have support on the ground and we had coaches assigned to the big projects to support that, which was outstanding because at least then they were getting that support. But it wasn't enough because as we said the company's quite large and guess what, not everyone's on the big sexy shiny project. There's all the small projects, there's the business as usual. There's all of those smaller pieces that needed support so we had to think creatively of how we do coaching around that. And so we came up with a concept called Doctor is In which we'll share with you too. So one of the other things we had to do is we had to show that we were making progress. So how do you measure the success of Agile? This is a huge challenge because you never run a project twice. You never do it in waterfall and in Agile and say waterfall costs 20 million, Agile as cost us, I don't know, 5 million. You can't show that. So once you go Agile, yeah, you can only say you can be relative to the other Agile project. There was a lot of work done by, I think it was QTech, a company in the U.S. that has got Agile metrics and statistics and we started plotting ourselves against them. But then we had to measure the team. So we set up what is called an Agile maturity assessment. Now this was heresy. We had the Agile zealots come down on us from every company in the world and say what you are doing is terrible. You can't measure Agile. Agile is a way of working. Yes it is. Yes it is. Yes it is values. Yes it is principles. But you must have some way of measuring. When you start, well start wherever. It doesn't matter. Just start. So this is now the Agile maturity assessment or the AMA started off. It's done three pronged. So it's done by the people themselves, by their managers, and by the coaches. So the coaches go in and run the same questionnaire on the teams. And it's about 20 questions. So as you can see, the number of surveys completed kept increasing, the respondents increased, the response rate increased, and the results increased as well in terms of the maturity number that's growing. We couldn't put that up here for other reasons. But it started increasing. Now what was very important is that this started creating a bit of competition between the teams, which is also interesting to see. Like oh my AMA score is 30 and your AMA score is only 25. So measures do create behaviors. And sometimes they can be the wrong behaviors. So you have to be aware of that. And we had to fine tune it. What was very interesting to see, the teams rated themselves in the middle. The managers of the team all rated them in the top 20 percentile as agile, and the coaches rated them in the bottom 20 percent. So it was nice to see the spider diagram on the same team, with the same questionnaire come out completely different. So that also brought the focus on the leaders and said what is happening here? So it wasn't just the measurement, but it was also the fact that the leaders had this sense that we've got a couple of story walls and we've got cards on the windows and we're agile. So that was something we had to deal with a lot. And it was powerful too because the execs would all get together. They'd get their AMA scores before going into that session. They'd workshop how they were going to improve their scores for next year. Projects quite often spun out of that. So how we could improve quality in testing was one of those. But as Phil said, it was healthy competition and made them all accountable too. Sorry. Doctor is in. So there we go. He's got the glove on. He looks like he's ready to do something. Yes, some people felt like we had the glove on, but you know. So let's use an analogy around this. You wake up tomorrow morning. You've got a bit of a sniffle. You've got a bit of a sore throat. You're not quite sure what's wrong, but you don't feel quite right. You're not sure if you're going to go to the office or not. So you might go to the doctor on the way to work just to find out what's going on. Sit in the doctor's chair. You describe your symptoms to him. You might have a look down your throat. You might check your glands, et cetera, et cetera. You might get a script out of that, or you might just get told to go home and have two days off work and take a couple of panadol. Same analogy was used with doctors in for agile. So for those teams who didn't have a coach with them side by side, they could use our doctor is in service where we'd rotate doctors as locums and they would provide a service of, you come along with a symptom or a problem and for one hour you could talk through that problem and get some options of how you could maybe fix it. And then if need be, you needed to come back and have a follow-up session if you just wanted to share how you went or you needed a little bit more advice. This was fantastic because it was a quick, easy way to get out to the masses. It ensured that we gave support to everyone, not just those that are on the big projects, and it also too just built a culture of having a connection to someone. And it didn't matter if you're in New Zealand, if you're in Melbourne, if you're in Sydney, it was irrelevant because we either did it by phone, VC or face-to-face depending on who the doctor was on that particular week. So I encourage you, if you're going through a change journey now with agile, this kind of approach is fantastic for building, you know, that momentum quickly. And it was free. Yeah, that's right. And they loved it even more. The project teams did not have to pay for the doctor service. Yeah. And we'll come back to how the funding model affects them. Right. So what didn't work well? The kiss of yes. Yes. So this is what you say, yeah. Yes, yes, yes, yes, yes. Sounds fantastic. Yes. Wonderful. And it's really the kiss of yes. They give you the yes to your face and nothing is done after that. So just, we saw this a lot. And we went away and a month later, nothing was done. So it was one of the things that we didn't pick up on at first and we didn't action. So it was just something that we had, we had a little, it was a wake up call. Funding model. What a challenge that was. So we started off with a centralized funding model and of course when everything is free, everyone jumps on the bang and wagon and everyone wants a piece of it, which is awesome. However, then there was a change in our funding model and it was decentralized. And we went through six to nine months of coaching, being a hot potato and no one had money to pay for it. And it was awful to sit back and watch that happen for those six to nine months. However, although going through that pain, the upshot of that was they now will pay for coaches and they have it built into their budget. So although we had to go through that pain, they actually now see the value because when they didn't have it for six to nine months, they actually felt it for themselves. So although it was awful for us, it actually worked out for the best in the end. And now we've got coaches that they're happy to fund. So we had about 12 coaches on a central funding model and Fiona was the head of the group and it was paid centrally by Jeff for two years. And then after that he said the projects have to pay it and there was massive demand. Coaches, we didn't have time to breathe and I was with Fiona on that journey and then suddenly he said the projects have to pay for it and the coaches were sitting there with no work. All of a sudden they didn't want, we don't need them. So interesting to see how it rolled out. Leadership, style and capability. Huge challenge like we touched on before. There were many examples of leadership which flies in the face of an agile culture. Leaders who potentially wanted to review posts before they went on Yammer for example. Leaders that actually wanted to check documents before they went out to customers. There was a lot of that type of behaviour. I guess what Agile brought to the forefront for us was you either got on the bus or you left. And so a lot of those types of leaders actually left the organisation which was great because we actually had the leaders and we wanted. So Jeff had to let go of three of his nine leaders and he actually had them moved on and so he actually took the size of action. But the other thing on capability was we wrote the Agile leadership training. It was about a year and a half to two years late so we had that running in 2009 and then guess what? The leaders never had time. It was a two day course. Then we made it a one day course. Then how can you make it half a day? Then it was two hours. They never had time to go on the training. So I think that is a huge issue till Jeff of course made it a bit mandatory for some of them. Then they came along because it was on their KRAs that they had to have done the training. So some strange behaviours and looking back for you I think we could have done better in that area. Absolutely. We should have built the leadership capability first including PMs and IMs and then the teams whereas of course we went with the teams first and the leaders then dragged it down a bit. So some learnings for everyone. Teamwork struggles. This was quite large for us too and as we touched on before we had teams that weren't co-located so how were they going to work together? It was a different way of working. The teams were accountable for delivery where historically some of them came from a culture where the decisions and the leader was accountable but now it was the teams that had to make these decisions. So there was a huge learning curve for PMs and IMs to actually take on that leadership role so there was many struggles and then being in Australia and New Zealand we can have teams in Brisbane alone being in four different buildings. So you're not co-located. So we always encourage for those first couple of iterations try and co-locate because guess what? That's when you get the momentum as a team and then when you're more mature then obviously you can be dispersed when the early days. And I think the one to add to that fee is in 2008 Jeff started 2009 the agile journey in 2008 he said we're going offshore. So all of a sudden we had off-shoring thrown into the mix of teamwork. So not only different locations but also different cultures and that made a huge challenge to the whole thing. That's taken a lot of time to work through and understand. I must say a lot of the Indian companies now because most of them were the large Indian organizations here like we Pro and Infosys and the rest have started on their agile journey as well. So it's fantastic. Choking the funnel. There was just so much and it was as Phil talked about before you had to really start to throttle the funnel and go what are we going to work on and what's the business value as opposed to all of these projects that aren't going to deliver the bang for bark and are going to hinder us on our ability to deliver on the key strategic pieces for the integration to occur. So throttling the funnel was key. And I think just again we had to devise games which were part of the training to show that no matter how many times you do it if you do more than one thing at a time it will always be slower than if you do one thing at a time. But it just doesn't go through. So that was a very difficult challenge to... And then of course we had testing and legacy. So SunCorp being a bank and an insurance company almost every system, back end system is a legacy system, cobalt based. More than 30 to 40 years old you've got two systems, 40 plus and they're still running perfectly. So why change? So testing those legacy systems was a huge challenge. There was no test scripts. There was nothing. We had to devise and invent and write wrappers and things had to be done. So lots of innovation around that and they've slowly risen to the challenge. We've now got legacy system cobalt test frameworks that run perfectly wrapped around the entire back end. The spaghetti is still inside. But that's fine. We've wrapped it with tests. We change anything. We just run the whole suite of tests on the whole thing and at least you're making sure nothing is broken at that high level. So lots of challenges there and then we come to the outcomes and achievements. So we're proud as you can tell of all the great work we've done and to be recognised now globally for how we execute and how we innovate I think is remarkable. We've met our delivery targets. We've asked them. The training curriculum that Phil built with the other coaches is just fantastic. The fact that other companies are now using it and leveraging off that I think is awesome. But I guess the harsh reality is you never quite finish. So that's hard for a team, especially these guys because they're all change agents and they wanted to make sure that we're always doing a good job but you never finish. There's always something else to do and you've got to keep reinventing yourself. So you're only ever 75% there. I think the last two years Jeff in order to disturb has brought in lean. So that's been a huge challenge for us, especially so because lean was brought in as a separate skill set and there's the lean team and the agile team and the lean team looks at operations and operational settings more for call centres and things like this and then the business are starting to to play that. I think one of the things that's important is if you don't have a singular clear vision then people will use any gap as an excuse to dodge out of it. So now when they're asked, are you doing agile? No, we're doing lean. Are you doing lean? No, we're doing agile. Are you doing lean? No, we're doing agile. And this nonsense goes on all the time. So it depends on who asked them. They toss it in between and I think they're coming to a realisation in Sankop now which is the next phase of the journey that it's actually one and the same thing and lean and agile is just a way of thinking for continuous improvement. Absolutely. Yeah, so... Yeah, sure. Have your training good to go? So as Phil touched on before probably having training ready earlier I think we underestimated the groundswell and although we did our best to support our people leaders really needed it and I think that would have helped us on a journey if we had had the leaders trained first built into induction and for contract staff. So whilst there's mechanisms now we probably should have pushed harder in the early days to make sure that that was woven through everything and of course we had lots of contractors coming in and out as PMs and it's hard to capture all of those whether they're in the business side or in the IT side so I think hindsight's a wonderful thing. We did it again. We'd make sure that we'd do that a lot better and make sure that we did an induction for those guys to catch them all in one fell swoop. The point on the contract staff is no contractor wanted to pay two days of his own time or her own time to go and do a training course let alone pay for the training course. The training course was free but it's two days of my billable time is now gone. Are you going to pay for that? And then SunCop had this big discussion and said no, it's part of your learning journey you have to invest in learning otherwise you don't work for SunCop. Here you go and work somewhere else. So it took a lot of doing. The other point I think that's important is you must separate awareness from training. So we ran awareness sessions of two hours for 3,000 people in groups of 250. Just what is agile? Because there were so many rumors agile is no documentation, agile is for car boys, there's no planning, we can never work to a budget, you just do it. All the myths that go with agile. That was all over the place. So run an awareness session on what is agile. You decide what it is in your company and then run it on that definition of agile to everyone. Follow that up with training because we didn't have our training ready between the day we ran the awareness and the day because we were writing the training. So there was a gap of about six months. Imagine I went on the agile awareness. I'm hungry, I want to hear about this new thing and then the next course is six months later. Back to waterfall. So just keep that ready. The other thing is, as I mentioned, focus on leadership training first. And the lean principles are so powerful. One of the fundamentals of lean is leaders as teachers. You can't make change happen if your leaders are not change enabled. So if we had the opportunity to do it again, which we are in some companies, get the leaders on board, including team leaders. So that's right down from executives to first line leaders. Then there's the project managers and don't forget the scrum masters, the iteration managers, whatever you call them. It's important that they go on this journey and train your own people. You may need to bring in a few specialist contractors to spread the knowledge. But yeah, the last one. Enough coaches available. It was hard to get good coaches. We are fortunate enough, as Phil touched on before, that we started off with 12 good coaches. But it is hard to get coaches who are truly coaches. So I encourage you to do your research when you're looking around for coaches and make sure that they truly do have an agile background. And train your own coaches as well. So we had a whole strategy a few years into our program of building our own internal coaches. Because guess what? You can't keep relying on the market forever. You've got to start building your own capability. And that's been successful, making sure we've got the blend of internal and external resources. And we've got some tips for success. So the first thing which is vital, agile is a strategy for either increasing your revenue or and reducing your cost. Basically increasing the profitability. It's a strategy just like I'm introducing a new product into a new market. Or I'm going to enter into a merger and acquisition. And just like any strategy, you don't do it half. There is no such thing as half. If you want to try agile, that is not rolling out. Just pilot it, call it a test, call it whatever you want, go and visit other companies, but it's not adoption. When you adopt agile, it is a strategy for change and you must fund it and you must do it properly. So imagine saying, there is this saying in Japanese and I'm sure somebody has talked about it in this conference called shoe hard read. So shoe is the stage where you follow the recipe, hard is the stage when you amend the recipe and read the phase when you write your own recipe. Now imagine in the first stage of follow the recipe, you say, oh well, I'm making a French pastry and I'm going to boil it because that's how I make a curry. So just follow the recipe and just do it properly. And be very firm on this. And people go, yeah, can we, yes you can. Imagine if you're rolling out a new product. What will you do? Will you say, oh well, you know, we'll roll it out half and if you want, you can go and sell it. If you don't want, you don't have to sell it. What nonsense. You just have to do it and be very strong on it and be very passionate about it and don't feel that you have to pussy foot around all these objections. It works. We're now 10, 12 years into the journey. There's thousands of companies doing it with proof and there's no excuse for not going for it if you choose for it. It has to be a change program. So like Phil said, it's all or nothing. So, you know, the more effort you put in, the more rigor and structure the more success you'll have. So I strongly encourage you if your organizations are embarking on Agile and you know, it's just kind of, oh I think we'll do it. It's not going to work. So put the time in and set it up properly. And I think just as a change program, it's very important to address what the grey hat people will know as PPPT which is process people and technology. It's not just get some agile tools and run it. It's not just a little bit of process change and not just people changes. It's all three things and the change program has to address all three like you saw in our approach and don't forget comms. Communications is so important throughout all of it. And take the business on the journey with you. That's key because they're your customers and they've got to be part of that journey and be part of the team for your success. So there's one little point on this that I would like to stress that Jeff was very, very instrumental in making happen. We told the business this is how we're doing it. There's no choice. You can't see as the business, I'm the customer. You don't go to a car manufacturer and tell them how to make your car. You just go and buy the car and they tell you how they've done it or they don't, they give you the car. So IT took a very strong view. We are doing agile and you will have to follow the principles and approaches if you want anything from us. And by the way, you can't go to anyone else either. That's it. And the business came along. They were wanting this. They loved it. I found more resistance in the entire IT shop than in any business group ever. The business just loved the collaboration. They take a little bit of time to suss you out whether you know what you're talking about because they've heard so much bullshit all along. But suddenly once they know it, they go, yeah, okay, I love this stuff. So they'll be your biggest supporters. Persistence. Don't give up. So there were many a time where the team were feeling a bit deflated but we just had to keep going. And that's really key too. When you're setting up your change program, when you're setting up who's going to support you in doing this, finding those people who have persistence running through their veins because it's paramount. Otherwise, they're just going to crash and burn early. And Fiona used to bring the wine and the vodka. That helps a lot as well. So when you're feeling down and everything's just have a drink and continue. But no, it's a journey. It's not something that you can say it's done. Jeff presented this from 2007 to the investors. Just like any investor group, the first thing they ask you is, when is it done? And he said, never. We'll always be 75% there. What do you mean? Yeah. It's a continuous improvement lifestyle. So just hang in there with the, you know, like a dog with a bone. People will try and shake it, try and change it. The organizer, and I think Evan, you showed the elastic rubber band as you pushed just one part. You know, the organizational culture, which is almost like an immune system, will fight back. So you have to be strong and go with it. And with that, we'll take a few questions. We've still got a few minutes. So throw it open. It's a nice small crowd. So feel free to ask. So I think the most important thing with the offshoring model that I'd like to say is that it's a 33, 33, 33 split. This is very important. So the cost of offshoring is a third of the price of a person on shop, roughly. Yeah? Now what people think is, oh, then I can save 66% approximately. If you do that, you're finished. You have to invest the other 33% on communication, travel, education, co-location, the right tools, and you have to add overhead. So if you want distributed teams across countries to work, you have to pay the price. You're still saving 33%. That's a lot of money on, I don't know, a $1 billion expense in total IT. So if you don't, if you try to cut corners, you will pay the price. That's all I can say there. Yeah? Yeah. So we were tracking the amount of, so the maturity model, what we did is we summed it up into one number, which were the different aspects of the practices, principles, values that people felt and we got it into one number. So that was the main metric. Teams started also measuring test metrics, percentage of code that's automated, percentage of code that's tested, delivery time, throughput time, cycle time. Now, initially they started measuring velocity, but that has changed now, because that really will lead to very bad behavior. So don't measure velocity. And yeah, then the number of training courses attended, percentage of people who have been on the Agile course, et cetera. So there's quite a lot out there. We don't fix price on the peaks. Yes. Well, not only the business, IT was also demanding an estimate. So the first phase is what we did is we actually had the concept and initiate workshop, which where rather than doing a feasibility study, we wrapped that whole phase into five days. So what used to take three to six months was done in about five days and then followed it up with a lower level estimate. That was plus or minus 100%, sometimes plus or minus 200%, and then we did the next one, which was plus or minus 30%, and all the Agilists went, you can't do that. Yes, we can. We have to do rough guidelines. Otherwise, who's going to give you money? Now the idea of final incremental funding and drip feeding, that will come. We are years away from that. Yeah? We're years away from that. We can't change that. Now if you try and go and change that in one go, you're going to just be told to get out. So you can't take that. So we had to go in small steps. So yes, there were prices. Now fixed price was not done. We started talking to vendors, including the external vendors, not to go for fixed price, but to go for time and material, time based on different models. It's a whole afternoon by itself, by the way. And bear in mind, the business was in those workshops for those five days. So they were there for the whole of the life cycle and can see how it was evolving. So nothing was thrown across the wall to IT for an estimate. The estimates were done together with the business in the room using poker cards and the whole system. So they got it in no time. Yeah. Sorry. So that's a very interesting question. Do you have front-end and back-end teams together? So they had an online team, which did the web-based sexy Java stuff, and they had the legacy back-end teams, which were cross-functional in themselves. So the BA Test Developer SME architect was in that team, but they haven't integrated the two as yet. So now they're coming to what is called the DAAS. So instead of software as a service, they're talking about back-end as a service. So they're providing services out of the legacy system so that you can call a service rather than anything else and offering this to the entire online team. So it's taking shape that way. Sorry. It's very difficult. I mean, I don't know what to say, but there is a leadership training course, and it's all about... The values, the principles and behaviours that you should see of a leader leading in an agile culture. And also to understand their fears. At the end of the day, leaders want to succeed. They're bonus. So just go to where they get their money. What drives them very often is the bonus. So the bonus is at the end of the year. What's driving your bonus? Start from there. And then they start seeing that this will give them their bonus better, faster and cheaper. Hey, suddenly the eyes light up. So, yeah, yeah. You have to go down to money at the end of the day. On the Agile Academy site, there's some one-pages to about the course material you can have a look at. Sorry. Motivation of the teams throughout this journey? The motivation of the teams. Well, I think the teams themselves... I mean, I don't know... I don't believe personally if you can motivate anyone. I think motivation has to come from inside. You can inspire, but you can't motivate. So I think Jeff and his leadership team were instrumental in inspiring people to achieve higher targets. So, for example, we released code in something like... We went from a three-month release cycle down to one month, and then he went for some conference, and he said, I take a bet with you. Let's see if you can do it in a week. And you'll all go for dinner for two. Yeah. So, simple things like this. You start driving it by driving targets, and that's the way you inspire them to be motivated. And showcasing successes and running the TV events where teams would actually get on the TV, the SBS TV we had in-house and share how their project went, and Jeff would be talking about the successes. And I think it's important to keep doing great work. And simple things like one of the... I don't know how much we're running over, but one of the things is we had the retrospective in the Belgium beer garden. So we'd go there, we'd order beer, put up the stand, do the yellow sticky notes, and after a couple of beers, I tell you the truth comes out. So 100% truth unadulterated will be on the board. So motivation, beer always helps. All right, thank you all very much. Thank you.