Sessions is temporarily moving to YouTube, check out all our new videos here.

Developing an Agile Mindset

Dermot Kilroy speaking at Dot Net South West in August, 2017
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

True agility is achieved by the people within the organisation adopting the agile mindset. This talk is all about the agile journey GoCompare has taken and contains an experience report of developing an agile mindset at all levels of the organisation.


Recently, I've just kind of moved over to a management role at GoCompare, and my Microsoft skills, my Microsoft Office skills have improved exponentially. In between kind of setting up all those status update meetings and comparing velocity charts and things like that, I've had time to think about the importance of the agile mindset. And I kind of came to this conclusion. So I'm going to start with the conclusion and then work my way through to how I came to it, and hopefully, it'll make some sense at the end of it as how I came to it. So, this is the conclusion that I've come to: the agile mindset is crucial to the sustained success of an organisation. Notice, I'm not talking about software development yet, or any of that sort of stuff. I really do believe that if you understand the agile mindset as I understand it, then you will see why it's crucial to the success and sustained success of organisations. Yep, it leads to kind of three questions, which I'll be going through, hopefully answering during this talk. So what is the agile mindset, why is it crucial to the sustained organisational success, and how do I start developing an agile mindset? Okay. So just before I kind of get into the detail of all of this, just a little story. A couple of weeks back, we were interviewing, or I was involved in the interviewing of an agile coach for GoCompare. And, you know, I started off asking him the question of the day, which is what is the agile mindset. He kind of starts answering it. It was beyond the textbook, so I quite enjoyed the discussion that it turned into. And I walked away thinking, yeah, nice guy, I can work with him. He seems to get it. You know, but he was scrum master in his current role, or he is a scrum master, but I thought to myself, he's never really worked in an agile environment. So, I was like, pretty pleased with myself, thinking, that's great. I've come to this conclusion. Nice guy, would work with him, never really worked in an agile environment. When people were asking me how did it go in the interview, I was like, yeah, good, nice guy. Work with him, never worked in an agile environment. And I started... When people would say, well, what do you mean? They'd say like, you know, he's a scrum master. He should know his stuff. How does he know his stuff? And I said, well, you know, he does kind of know his stuff, but it's not a true agile environment. And then as I kind of thought about it a bit further, I thought... Something hit me. I just thought, I've never worked in an agile environment. I've been involved in kind of agile practises, tools, techniques, practises, for the last 13 years. I've learned TDD, BDD, continuous integration, continuous delivery. Been involved in retrospectives, facilitated them, worked in them, worked with them, standups, everything. All the process, and in all that time, it's never really felt like the promise of agile. It's never really felt like a smooth kind of process. And if we look at this kind of, the landscape of agile, it's easy to see kind of why most of us, I would say, haven't worked in agile environments. Because it's the complexity of all of the different kind of tools, techniques, and practises. You know, one of the things about agile is that it's kind of... One of the criticisms is it's dogmatic. There's lots of dogmatism involved in it. And if we look at it, like these definitions, I do believe that the Agile Manifesto contains a set of principles which are true, essentially, but we'll be showing you how I've come to that kind of conclusion over time. The problem is the dogmatism. So when you approach things through the lens of the tools and techniques, then that leads to the dogmatism. So I prefer to look for the evidence and opinions of others, because they're the ones that have the problems so we can start to solve the problems and have a discussion about it. So, the second kind of big problem is it's cargo cultism. Oh, that looks better on my screen. Hopefully there's not too many memes in this talk. But, yeah. So, you know, it's easy to point out what's not agile, you know, and we get that quite a lot. It's the same kind of thing with REST. I think everyone always tells you, that's not REST, but actually, what is REST? It's very hard to kind of answer this for a lot of people, so it leads to more problems. What I'm going to try not to do is say that's not agile, and point out what the mindset is. What is the agile mindset? And in order to understand that, we have to understand two things. One is, what is a mindset, and the second one is a brief history and a brief run-through, and I'm sure most of you are familiar with it, but the agile history and where we get to. You know, how we approach things, positively or negatively, will kind of lead to the outcome, and I think Henry Ford summed it up very well: "Whether you think you can or you think you can't, "you're right." So, yeah. So, let's move onto a little bit of history. It kind of struck me that, you know, the manifesto wasn't the beginning of the thinking about agile, if you like. So what I did was I just kind of started to look at it and think about all the influences that kind of led up to the manifesto, and this is just a brief kind of timeline that I put together. 17 people got in a room, 2001, Snowbird. Everyone's familiar with that, a bit of it. Yeah. But the people in the room were already involved in doing lightweight methods. So they'd already created a whole bunch of experiences around delivering software in a kind of lightweight way. So we can see here at the beginning that you had Scrum was formalised in '95, and so you had a few Scrum components there. Proponents, and then you have DSDMs. So XP, Kent Beck, Ward Cunningham, adaptive software development, Jim Highsmith was out on his own doing his own thing, and then 2001, they all got together, and at that stage, I actually heard a talk by James Grennell, one of the signatories at the Agile on the Beach. Was anyone at Agile on the Beach? Nope? Okay. So, yeah, he talked about the run-up to this, and they were actually calling it the lightweight methods, kind of, summit. Thankfully, they thought of a new name. That was one of the priorities of the summit, was to think of a better name, because we'd all be sitting here talking about lightweight. We're lightweight this and lightweight that. So, they didn't really want to do that. But, so, so there was a lot of kind of experience from '95. They were delivering software projects using these lightweight methods, looking at the kind of heavyweight, if you like, methods, the linear processes that were happening, and not being happy with the state of software delivery of the time. And just like across, you know, the representatives within the kind of summit, you know, we've got lots of engineers, one project manager, and testers. But there's no product owners or business side of things representation there. I wonder if it would have been a different kind of set of principles and values if there'd been any kind of business people in the room. So it's important to understand that it was the set of experiences that led up to it, and that the manifesto was kind of a group of opinionated people getting together and finding consensus on what they agreed was kind of a lightweight method for delivering software that they branded agile. Yeah? So, and if we look at the kind of practises at the time that were heavyweight, that were linear, it was, you know, management style was top-down. Communication was more about efficiency than effectiveness. It was all about kind of planning up front and stepping through. And this was in the 90s. It was the middle of the software crisis. I think the software crisis is probably still going on. We've managed to kind of hide it, but it is still going on. In fact, a friend of mine's been on a project for two years. They've only just done a release. So, you know, in fact, we've worked it out that he's worked on four years of projects, and they released the previous one, but it got canned as soon as it was released because it was a business fail, which was identified in the early kind of analysis of the project by a business analyst, but it was just carried on anyway. So, yeah. And that was only six million lost. It could have been 200 million. So, fail fast, right? So, yeah. So the point about this is when they came out with the Agile Manifesto and agile, it was a stark contrast to the prevalent ways of delivering software at the time. It was easy to say enjoying something that was like, we're not happy with this side. We're not happy with the way software is being developed, so what we can do is this other thing. Agile is a really stark contrast, right? So it was about kind of having that contrast. It was easy to spot the difference. And then if you fast forward kind of 17 years, yeah, this is the stage of agile, 2017 report from VersionOne. 58% of us are in scrum environments. So scrum is the kind of prevalent agile methodology of the day. Now, the problem is is when you mention agile, people mention scrum in the same kind of breath, if you see what I mean. And so to me, scrum is processes, tools, and techniques, but it's not really the agile mindset. But we'll get into that. It's not that scrum is the problem. Scrum's okay. It serves a purpose. It serves us in lots of problem, and it's about solving those problems. That's where the agile mindset comes in. In fact, I like to think of it as, it's like putting an Apple logo on a Dell and thinking you're gonna get the same experience. Saying that scrum, in its own right, and agile are the same thing. Yeah. So, just to kind of sum up this bit, so a mindset is a set of attitudes, beliefs held by someone. The Agile Manifesto was written in 2001 by a group of software development experts who were leading the way in lightweight approaches to software implementation. So we've got the four values and 12 principles of the Agile Manifesto, and every word they put into it was carefully crafted to kind of prompt us to go in the right way. Yeah. So, why is the agile mindset crucial to the success of an organisation? So, I'm just gonna kind of maybe talk about some stuff that may be obvious, but it will hopefully fill in some of the reasons how I came to these conclusions. If we start to look at... We need to understand organisations and organisational success and things like that as well. So, I just think that an organisation, the goal of an organisation, is to sustain its own existence indefinitely. Nobody starts an organisation thinking, okay, I'll start this one for the next year or whatever. They commit fully to it. They want it to last for as long as possible. They want it to grow. They've got an idea, vision, plan, and it's not, like, short-term, generally. Everyone wants to change the world in the startup world. And if you think about it, we're in a kind of economy where money is the life blood of organisations. So in order to sustain your existence, you've got to make money. Yeah, hopefully, more money than you're gonna cost to run the organisation. And if you think about kind of how we make money, well, we'll get to that in a second. But the money has to exceed the amount of money that it costs to run. So we wanna be profitable. And, you know, a few management thinkers and things like that. Again, to state what seems to be obvious, but a lot of companies don't do it, but it's starting with the customer. So, "The customer is the foundation of a business "and keeps it in its existence," yeah? So, it's about understanding your customers, it would seem. If you understand your customers, what they do is they have a problem. They have a pain point. If you find out what that problem and pain point is, and you solve it in elegant ways that they understand, you'll make money. It's pretty kind of simple and straightforward, right? It's very difficult to do. I've tried. Yeah. So when you solve their problem, people will power it with the money. Yeah. So, of course, good marketers will find kind of any problem and turn it into a pain point, if you like. So this is... I think I was working with Chris down at Twofour, and I thought we were all kind of getting into the startup thing, and I thought, I'll look up the stupidest ideas that worked, and this was number one. And it was in the 70s a marketer said, you know what? I'm just gonna start this thing called pet rocks, and it's aimed at people who live in apartments who can't have pets, yeah? And it's big. There's USB ones and everything. He made millions out of them in the 70s. I'd love to have been in that meeting with the bank manager. But yeah. So, yeah. So anyway. So anyway. That's good marketing for you. So you can market any problem. But essentially, if you convince someone they have a pain point, and you explain it in a way, they will buy. I don't know if... Move on. So, if we think about it like today, in the world today, it's very... Technology has kind of caught up, if you like, with the goals of agile, because we can be pretty competitive pretty easily with the cloud and infrastructure and all that stuff, very cheaply. You can have an idea. You can put technology at it, and you can, for a very kind of small investment, you can disrupt a market. And, you know, Blockbuster being the classic kind of example of a company that should have seen what was going on, but they didn't, and so now they're gone. And they tried several times to change, but they didn't fully understand their customer. They didn't fully understand their business model. And so therefore when they actually did go online, I think they were trying to charge 99 a month without, like, any, there was no quibble. You just paid the 99 a month or you didn't join. So, they were right to die. They didn't have the right feedback mechanisms. They didn't understand their customer. So, yeah. Again, just to kind of back it up, Jeff Bezos, Amazon founder. "Focusing on the customer makes a company more resilient." It's a very simple message. It works, Amazon says. But what do you need? So by focusing on the customer, then what you can start to do is get the feedback mechanisms that's going to lead you to understanding the changes that are happening in your marketplace. So, I will come back to the whole Agile Manifesto thing in a bit. So we've got early, early warning systems, early warning systems that lead to us kind of responding to the changes and demands of changing customers. So if you get to know your customers, you can respond to their needs. McDonald's is a good example of someone who has responded to change, because in 2002, they posted their first quarterly loss. It was at the same time Fast Food Nation came out. So people were kind of moving away from fast food and all that sort of stuff. And so McDonald's, what they did was they went to their customers, and they kind of said to them, what should we keep, what should we get rid? And they responded to that change and adapted, and unfortunately, they're still here today. And we still love fast food. So, yeah. Responding to change, and yeah. So, if we kind of think about all of that and how businesses sustain their existence, it comes down to, number one, customer collaboration. So you've gotta understand your customers. You've gotta collaborate with them. It's a collaboration to solve their pain. It's not just, we want to, you know, we don't care about you or anything. We have to understand you to solve your pain effectively. Otherwise, when it does change and adapt, as Blockbuster, then what will happen is they'll move on, and you will think you understand them, but you won't. So, it's constant customer collaboration. And then, even if you have the early warning mechanisms in place, it still takes people with a certain set of skills to analyse those early warning systems, and people with other skills to act upon them and effectively deliver or do something that kind of responds to those changes. So, that's the individuals interacting together to kind of respond to the changing, and it's the feedback mechanisms that you have in place and allowing the experimentation and things like that. And you see what I'm doing here, yeah? Good. So, yeah, we've got like, working software. So that's, if you think about it in a digital world or online businesses, that's how we kind of get one of our early feedback mechanisms, is getting working software out there quickly and analysing the behaviour of our customers and seeing what they're doing, and then a kind of constant feedback loop so we have working software. You can probably change that today to, you know, valuable products, working products. What is a valuable product? It's something that someone can use that the wanna pay for, yeah? So, it's kind of moved on from just software into the business. And finally, all of it is encompassed in responding to change. So for me, that's why it's crucial. The question that we were answering at this stage was, how can I start the... Okay. So we can start to see that the wording and the values and the 12 guiding principles are kind of synonymous with actually having an effective business, yeah? That's self-sustaining. So, how can I start to develop an agile mindset? So, yeah. So it all starts with the individual. Yeah? It all starts with each person in this room working in teams and understanding how those teams operate. So what I would say is that we have to go past all of the complicated landscape of tools and techniques and practises and just revisit the Agile Manifesto. The more I revisit it in the last year, as I tried to kind of help the teams that I'm working with to kind of become more effective. The more I see, it's prompting the right questions. So, one of the teams building the first service, they were so concentrating on kind of the technology, the tools, the practises, that they spent four sprints just kind of working on this thing with no real, what's happening? And if you asked, they couldn't say, well, we're here and we've got this. And they kept finding another problem and another problem and another problem, so I just said, look. Draw a line in the sand. I'm not telling you when to do this. I'm not setting a deadline. I'm not saying. But you guys have to. 'Cause someone's gonna come along and say, what's happening with that project? And ultimately, when I looked at the manifesto, I thought, we deliver early and continuously, yeah? But it took for sprints before we even thought about, like, delivering anything. So that to me, the questions were right there that we should have been asking, right in the beginning. But we'll talk more on that in a bit. So, just a little bit about GoCompare and our kind of journey and why I think that GoCompare has the potential to be a truly agile organisation. It starts off with our senior executives, you know. Our CEO, new CEO started about a year ago. He wants to, as all kind of business people want, they want a faster pace, yeah? More stuff. But he's a people person. So he's not saying work harder. What he's saying is I want you guys to be able to make decisions at the goal phase. I don't want people getting in the way of those decisions. But, you know, we need to be faster. We want to grow. We need to be able to respond faster. And what that means is we've gotta have decision making at the goal phase, yeah? So, one of the first things he did was get the right people in place. So our CTO's worked in kind of startup backgrounds and has kind of delivered in agile environments, startup environments that were fast-paced and things like that. So he gets it from an engineering perspective. We also kind of readdressed the balance as well in terms of, I think we were a very good marketing company that kind of had a technology... Didn't invest enough in technology to back up the marketing. So it was always that kind of, you know, we've got an ad going out, and we're going to... Then the tech follows, yeah? So it's readdressing the balance. We've brought in like a team that can get the whole decision making at the goal phase. And we've then reorganised. Reorganised the structure and also how we, how we kind of, what's the word, prioritise the backlog and do all that. So we have one single final, one team, one vision, all working with the same, in the same way. So it's... Is everyone familiar with the Spotify model? Yeah? Okay. It's kind of a little bit outside the scope of this, but it's just essentially, there's a white paper on it that Spotify have done, and we're finding our feet with it, but essentially, it's all the usual suspects. Co-located teams, cross-functional teams, and the idea is that a chapter... So the squad is the cross-functional team. Product owner, and then the team, so they will work together, and then chapters are the discipline. So that might be software engineering. That might be the test engineering chapter. So that's where you can get a group of people that talk about the discipline, and so then you set up guilds that then go across, which might be, you know, web frameworks or whatever, a guild, or agile guild or whatever. So it's a topic that you're interested in. So, this is kind of the way it works for Spotify, and it seems to be working well for us. So, yes. I've said this already. This is where I was supposed to say it, but it does start with you. And again, that looked better on this one. So, it's a mental note. Yeah, so, look. You know, I'm in the position where the senior execs get it. The business people are starting to get it. We have agile coaches who are kind of doing... Who are doing a work to bring the whole business up towards an agile kind of mindset, if you like. So, you know, I have that backing. But whether you have it or not, you can make changes. You can make change happen. One of the... So, I was reading a book which is all about change, Dan and Chip Heath. And they talked about this person who was tasked, one person tasked with eradicating child poverty in Vietnam. And he had six months to do it. So that's a big problem to solve. So, it makes kind of most of the problems that we have, well, that I have, I don't know about your problems, but, pretty straightforward, right? And so, what he did was he looked at it and he went, you know, how am I gonna solve this problem in six months? And he started to look for what he called... I think he called them hotspots or something. I can't remember. A term like that. But anyway, he looked for these things, which were children who weren't malnourished. It was malnutrition, yeah? I said that. So children that weren't malnourished. So he was actually eradicating malnutrition, not poverty, malnutrition. And he was... He went and he found children who weren't malnourished in areas that had a high kind of malnourishment scale. And he then just worked out, what were they doing? And it turned out the parents, the mum, was giving them nutritional food through vegetables and fish in with the rice. So what he did was he just started teaching other people and put out a whole like, at scale, a whole system that then kind of eradicated malnutrition. So he just looked for evidence of other people, having success and what he wanted to do. I say just. It probably wasn't that easy. So, and that's how he solved it. So, if we think about, like, our problems and the problems that we face in kind of effectively delivering software, we'll always come up against barriers of people who say, it can't be done there for these special reasons. Well, there's just loads of evidence of companies, and it doesn't matter. One of the big things about us is we're in regulated industry. We have the FCA, and that was one of the big kind of fears. We can't do this, because we're regulated, and we need to be careful. But then there's banks continuously delivering and deploying. So you look to those. They're regulated. They can do it. So we can do it. We just need to figure out how. So, the point is is to spot the problems, and the Manifesto, looking at the Manifesto will help you to spot the problems. You'll just look, read through it. It will start you. The prompts are there. You'll start to ask yourself questions. Why aren't we doing this? What is stopping us from doing this? And then you just pick the one that's most painful, and you start solving it. Yeah. Yes. So, also, you have to understand how the team operates. You know, strong teams have a common goal, a strong identity, they're planned, and they give honest feedback. And one of the hardest things I've seen in teams is to give honest feedback, right? The best teams hold each other to account. They give each other honest feedback. Any rugby fans? Yeah? The All Blacks? If you join the All Blacks, nobody's gonna take on a passenger. They're gonna give you honest feedback, that you're not pulling your weight. As soon as you join that team, you put on the jersey, you're in this team. There's an ethos. There's a work ethic. If you don't follow that, you're not going to stay in the team, right? So what we have to start doing is kind of looking at each other and saying, we can do better. One of the guys at work, he's in a band. And this band, it's a brass band. And they were kind of a mediocre brass band for a while, and then they decided they wanted to be winners. So they'd join competitions, and they'd come last, or whatever, and then for some reason, I don't know what the reason was, they decided they wanted to start winning, and so they then committed to winning and started practising and doing all sorts of stuff. So they set up a culture where they wanted to win, and then they started kind of winning, and then it was a self-fulfilling kind of prophesy, where it was a virtuous cycle of, we're in this, we wanna win, so everyone practise. And the band leader kept them all in line now. He would kind of all it out when you weren't doing stuff. One of the stories the guy said to me was that one of his band mates said to him, just before, like they were going for a big competition, and the band mate, he was doing a solo piece that it all hinged on, and the band mate said to him, you should have nailed that by now. And I said, what was your response? He said, well, he was in a rage. He was in a rage with this guy for telling him this. And he went home and practised. And he nailed it over the next session, right? So I said, did you think the guy? He said no. Actually, he probably holds a bit of a grudge. Not a big grudge, but he probably holds a bit of a grudge. But I said to him, look, that guy went out of his way to give you feedback, and said, look, you can do better. And so his way of saying that was, you should have nailed it by now. He probably could have had a, you know, a bit more of a softer approach. But the outcome was the same. So it's about understanding the team and how the team operates, and also the difference of, if we think about it, there's engineers, and there's the wider circles. So we have engineers, test engineers, and we have product owners. So all of those people approach software development in different ways. And, each one has a valid way of thinking about it, yeah? And so what we need to do is understand each other's perspectives, yeah? So, I think this one illustrates... In one of our teams, you know, the product owner, she was a bit worried, because the team had committed over the last few months to delivering a particular piece of functionality, and she approached the team at the beginning, before committing, and said, when do you think we can do this? What is it likely to look like? And then with the team's involvement came up with a kind of roadmap. And then of course she goes public with the roadmap and commits to lots of other people, yeah? And of course then it started to slip. And so, delivery didn't happen as well as on the committed times and all that. It's not a big problem, but it's just, trust starts to dip, right? As soon as you commit publicly to someone else, then you're gonna deliver something at a certain time, and then it just doesn't happen, and you're the one that has to keep saying, oh, you know, it's fallen back because of this reason, and because of that reason. Eventually, you're going to start not trusting what people are saying, right? So, and what I realised was just that the team didn't really understand her perspective. And so, they didn't, you know, when I said to one of the guys, one of the engineers, I said, imagine you have to commit to, you know, the head of engineering on a certain piece of functionality, but you're not doing the work. Someone else is doing the work. So, what do you need to know every single day? And just before it comes up to that deadline, and now you find out that it's maybe gonna be late or whatever, how are you feeling about having that meeting with that person? So that's exactly how she feels. So understanding her perspective. So they all start to think about it, how does she trust, how can she define trust? Like, at each meeting, she should be able to walk out and say whether that's increased the trust or decreased it slightly and maybe define it in some sort of way. And if you give feedback, if you understand the other person's perspective, then you can understand how they trust you, and then you can start to, in your stand-ups, instead of talking about, yesterday we did the Hoochie McFlip thing that she doesn't understand, and this... She wants to know exactly, like, you know, is there a problem or isn't there a problem? Maybe it's that stark, but the team figures out what the language is in the stand-up so that then everybody understands where we're at, not just the engineers. Do you see what I mean? So understanding each other's perspectives. Yeah. And then another part of this is kind of the importance of asking the right questions. So if you, you know, by asking the right questions, it leads to better solutions. So it's like, if you understand somebody's perspective, you seek to understand them as you're trying to figure out the problem. So, you know, you're not doing continuous delivery or whatever. What is stopping you in your organisation from doing continuous delivery? We've done manual releases for all of our history. So trying to move to an automated continuous delivery thing is gonna upset some people, because they're used to controlling and protecting and all of those things. So you have to understand them to ask the right questions to lead to the right solutions that works for everyone, but in an automated way, and things like that. So, don't just look at the problem, the outcome. What you have to do is... So there are two things I believe you need actually to kind of adopt the agile mindset. One is an understanding of the Manifesto, a deep understanding of the Manifesto. Look at it. Go beyond the four values, 'cause everyone reads the four values. Some people even memorise them. But nobody reads the 12 principles. Nobody reads the first line, we are uncovering better ways of developing software. Yeah? So, it's a constant kind of learning. So, and the way you learn is by asking lots of questions to get to the root cause. To solve the problem at the root, not at the surface, so we can sack the driver. He's not going to solve the problem. So. Okay. This next slide, I shouldn't have had. So, okay. So. Here's another one by Einstein. He was a clever bloke. You can't solve today's problems with the same level of thinking as when you created them. Now, the Manifesto was written in 2001, and I still think we haven't solved the problems that we were creating then, and the new thinking is... This is in the Manifesto, but we've never actually kind of, in our rush to adopt scrum, we've kind of not taken the time to really understand what they were trying to say to us, what questions they were trying to ask us. So, I believe that the new level of thinking is still in the Manifesto. I can see anything that's newer than that that's gonna help us to solve our problems to build sustainable, you know, organisations. If you look at kind of organisations that are hugely successful, they're constantly kind of assessing the market and, you know, huge amounts of data. They're always changing. They're always adopted new stuff, looking for new things, and having... So they've got the early warning systems, and they've got the mechanisms to act upon those things, and really deliver. So. And so, that's why I believe that the agile mindset is crucial to the success and sustained success of organisations. Thank you very much.