DU009 – Agile – Clive Trounson Interview

Transcript

The Design Untangled Podcast

Episode: DU009 – Agile

Host: Chris Mears

Guest: Clive Trounson, Agile Coach

Length: 27:19 minutes

February 5, 2018

 [00:16] Chris: Hello and welcome to Design Untangled with me Chris Mears and usually Carla Lindarte, but she’s ill this time so I’m going to go solo and talk to myself in my home office, which is a bit weird but anyway, we did manage to get something cool for you this episode. I’m going to be talking with Clive Trounson, who is an Agile coach. We did the interview in a freezing cold park in central London. It’s also the windiest day in recent memory, and for that reason at various points, I’ll probably dub over the interview so you can actually hear what we were saying above all the seagulls and geese that are attacking us and the wind, practically blowing us off the bench. But anyway, enough chat for now. I’ll be back at the end and here we go.

[01:04] Chris: Okay. I’m here with Clive Trouson. Is that how you say your name?

[01:08] Clive: That’s correct. Yes, that’s right, Chris.

[01:09] Chris: That’s a good start, and he is an Agile coach currently working at Ministry of Justice HMCTS. So let’s start with asking, what the hell is an Agile coach?

[01:20] Clive: What the hell is an Agile coach? Yes, that’s a great question, isn’t it? Well, so Agile methodology is a way of developing software, and what tends to happen is we get people that go on training courses or might be read some stuff about agile and it’s like most things, you can get the theory but to implement it in practice and to do it well and do it consistently and particularly on a big program like we’re doing, it’s some additional help just to kind of keep the wheels turning, make sure things are going in the right direction is really what my role is about.

[01:53] Chris: What is agile?

[01:53] Clive: In this context, it’s a software development methodology. It’s been around probably nearly 20 years now, early 2000s. It’s really started to gain momentum with it. That’s certainly when I got involved in it, and people will say there are two ways of software development. Of course there are more than two, but there’s the traditional what people call waterfall, where you do all the requirements up front and then you do all the analysis and design, and eventually you write the software and then you test is so more say] and then eventually you deploy it. Of course by then, the world has changed and it isn’t what you thought you wanted or things change. It’s also a very frustrating way of working because you’ve always got this deliverable that’s a long, long, long way away. So Agile changes that and what it tries to do, it tries to deliver software regularly and frequently in small pieces of value. So your risk goes down, your value goes up. You can try things out and iterate them and improve them, and also the dynamic of how it works tends to be self-motivating because there are software guys and people that work in the industry, they like to do stuff. They like see stuff happen, and if you’re delivering software frequently, you’re already seeing stuff happen and that’s cool and sort of motivating.

[03:08] Chris: Cool. How did it come about, I guess? When did it start becoming a bit more mainstream?

[03:14] Clive: So there’s some legendary names in the business. I forget ….

[03:23] Chris: Legendary but forgettable names

[03:27] Clive: Yes, and there was a conference. I think it was called the Snowbird Conference somewhere in America, and a bunch of these guys got together and they came up with what was called the Agile Manifesto, which has four key principles, four key statements, which, which I am now going to attempt to remember. So the first one is…the basic premise is about delivering software frequently and value in software, and the four main tenets in that are interactions and individuals over processes and tools. So what that means is rather than worry about the complexities of using a particular tool for tracking your backlog, like Jira for example, it’s about people working together and getting stuff done. The next one is working software over comprehensive documentation. If we think back to the other waterfall world, you need big requirements specs, big design specs that nobody ever reads. It doesn’t mean that documentation is not important. It’s still a very important thing to do, but it’s about finding the right level.

Responding to change and following a plan. There’s the famous saying, however good the plan is, it doesn’t survive contact with the enemy, and it really is. I’m sure we’ve all seen these Gantt charts that go on for thousands of lines and again, nobody reads them. They’re impossible to follow. So it’s about responding to change and that’s kind of where the HR bit of it comes from. And then the final one is about customer collaboration as opposed to contract negotiation. So if you’re in a commercial environment and you’re working with suppliers, it’s thinking about if you’ve got an output-based contract that says you will produce these screens and these many lines of code, but really what you want is something that allows you to book an air airline flight. You need to structure contracts in such a way that you can have that agility and change what the outputs are to meet the goal. So those are kind of the four things really.

[05:31] Chris: So when you say contracts, what do you mean? Like in terms of the contract with your end user?

[05:34] Clive: Yes, a good question. I’ve always read it as more of contracts with the software supplier.

[05:45] Chris: Right.

[05:46] Clive: You know, organizations outsource their software development. So if you’re outsourcing your software development and you think we want a piece of software that does exactly X, Y and Z, and then you get into it and realize that you want something else, you don’t really want to be changing your contracts. That’s just a pain. It gets in the way, so you want to get yourself a commercial arrangement, if that’s the way you’re working, that allows you to say we want something people to able to book airline flights, to give you an example and then your contractors [unclear; 06:16] that is, you can collaborate with the users and the customers to get them what they really need, as opposed to what you think you want and you bake it into a contract.

[06:25] Chris: So I guess there’s probably a bit of tension in terms of people signing off budgets and stuff. I guess why waterfall was a comfortable realm to live in is you knew exactly what you were buying, and you can put a monetary amount against that, whereas Agile is a bit more flexible and I guess you need to use stuff like milestones or what way

[06:47] Clive: Exactly. I mean you’ve hit the nail on the head there. It’s as if you’ve got a functional spec that you can sign off, you say, I know exactly what I’m getting. But the problem is though, you’re doing that so in advance or before doing anything, how do you know you’ve got it right? It might be 80% right. It might be 20% right, and then you’re stuck in this world where you just have to go through this really painful change process to get what you need. And then what about the crazy situation where actually you start doing something and you realize that you don’t need all of it?

[07:17] Chris: Yeah.

[07:19] Clive: You know, it’s a classic Microsoft Word example. Microsoft Word has got 15 billion features in it and most of us probably only use about 10 of them. So why do we need to pay all that money for all of it?

[07:31] Chris: This is a very good question. I often wonder that.

[07:34] Clive: Exactly. Yeah.

[07:35] Chris: Have you ever seen Agile used outside of software development, or do you think it could ever be used outside software development? So I was thinking about… well, I wasn’t thinking of it. A colleague was thinking when he knew this chat was going to happen. You probably guessed who was thinking it. I guess probably one of the biggest examples of the waterfall methodology outside software developments is maybe like building a house. So it would be quite rare or perhaps crazy that you would just maybe design the kitchen first and then figure out how the bedroom’s gonna slot into that.

[08:13] Clive: True. It’s an analogy that gets drawn quite a lot. Whereas the construction industry is a mature industry and people pretty much know in order to build a house, you do the foundations, then you do the ground floor, then you do the upper floor, then you put the roof on last. That’s a well understood thing, and most modern houses now are built standard sizes so you can get furniture through the doors and we kind of know what people want in a house – eat, wash and sleep and do all sort of things that people do in houses, so it was relatively well understood. It’s well understood, whereas most software engineering, if it’s new product development, you don’t know what you’re doing and the example that people talk about is the Sydney Opera House. The Sydney Opera House was a new building that people didn’t know what they wanted, and they were inventing new construction techniques and all sorts of things and it took a long time and of course they went over budget. Whereas if we were to build a Sydney Opera House now, we would say we know exactly what we want, we know we’re going to have it, bosh. Done. Simple.

[09:22] Chris: So at this point I asked Clive how you can measure the value of Agile or waterfall in a project. Here’s what he had to say.

[09:30] Clive: One of the buzzwords in Agile is about uncertainty and there are two dimensions to [09:38 ancestors]. One of them is about do we know what we want, and the other one is, do we know how we’re going to do it? And if the answer to both of those questions is yes, we know exactly what we want, and we know exactly how we’re going to do it, then yeah, you don’t need an Agile project. You don’t need to explore, you don’t need to experiment, just go. Go ahead and do it. The value thing is interesting. If you do a waterfall project, the value that you’re delivering, the benefit you get, you only get it right at the very, very end when you deliver the whole thing, and imagine taking the Microsoft Word example again, if we spent five years developing this super advanced word process and you get to the end and someone says, well I only need notepad. Could’ve had that like a month into the project. That’s kind of where the value goes because it’s delivering software regularly and frequently people can use it. They get value out of it. They are getting the things they need to get done done.

[10:35] Chris: So let’s move a bit more to how Agile works in the context of sort of designing stuff. Can you explain the difference between Agile and SCRUM?

[10:46] Clive: Okay. So Agile is the way of working. Scrum is a particular methodology within it. So there are various different flavours of Agile processes. They all adhere to the same principles and Scrum is probably the most popular way of working process. There are other ones. The other one that people talk about is Kanban, which is more of a flow-based methodology, which primarily came out of the Toyota vehicle manufacturing industry and they stole ideas of that from supermarkets as well. Probably the best example of a Kanban is if you go into McDonald’s and look at the burgers. They only make the burgers when people come in and ask for them. I mean, if you actually go to Whopper King, actually they do it too far the other way. You hang around waiting…

[11:40] Chris: Whopper King?

[11:40] Clive: I believe that’s what it’s called, isn’t it?

[11:42] Chris: Burger King. Some new burger joint I have got to try.

[11:50] Clive: If you’re going to Whopper King, yeah. But the idea is you go in and you make your order and they have just sort of enough stuff that’s in flight so you always get a fresh burger and they match the demand to the supply of burgers and things, so that’s more of a flow-based model. The work flows through something and Scrum is an initiative thing based on two weekly cycles, normally two weekly cycles where you set an objective for that period of time, then the whole team works on meeting that objective. At the end of it you ideally deliver and ships and suffer if you can, and then repeat and repeat and repeat.

[12:26] Chris: And Scrum is made up of a couple of different ceremonies.

[12:31] Clive: That’s correct. Yes. So there’s basically three key elements to Scrum. There is the people side of it, there’s this thing called the product backlog, and then there’s the ceremonies, which is a very grand term for the meetings that you have, and very broadly, you have five or six depending on how you count them. At the beginning of the cycle, you plan what you can do in the next two weeks, and that’s called spring planning. Every day the team comes together and has a brief conversation, normally first thing in the morning called the daily stand up, where you say, what did I do yesterday? What am I going to do today? And what’s preventing me making progress? And the idea of that session is to have some quick communication with the team so you know what you’re doing, and you need to work through the day, oandn any issues that need to be taken away and resolved.

And then at the end of the cycle, you do two further ceremonies. One of them is called the demos. Some people call it the show and tell. It’s where you come together and say, look this is what we’ve done. Isn’t that cool? Isn’t it amazing? And that’s great. You show people what you’ve done, you get to celebrate the success, go to the pub afterwards and then you do the other thing. It’s called a retrospective where you look back on the work you’ve done and how you’ve been working and say, can we improve that process?

[13:52] Chris: So we did have a specific question actually as well. We’re on retrospectives. Have you got any tips for running good retrospectives and making sure it’s not just a big whinge session?

[14:04] Clive: Yeah, so what you can do. There are many different ways you can do it. There are lots of different techniques that you can use of doing that. What went well? What didn’t go well? What do we want to start doing? What do we want to stop doing? All that sort of stuff, but then the other thing you can think about themes. So rather than it being a broad brush moaning, you might recognize that, for example, your technology team aren’t getting the software deployed quick enough. So you could say, let’s just have a retrospective on that. So you can sort of pick a particular theme and that’s sometimes quite a good thing to do because sometimes it can just be too generic.

[14:42] Chris: And you need to kind of define actions coming out of it as well, which is another important thing, I guess.

[14:49] Clive: Yes, and normally the hardest part is actually flowing, is doing something about the actions. If you do a retrospective and you do a generic one, you come up with 700 actions and usually deliver none of them. Whereas if you say, we are just going to look at our tech part and we have two actions, there’s a good chance you might fix them. In my experience, that’s the way to do it.

[15:09] Chris: So Agile works very well for software development and I guess one of the newer kind of areas or capabilities that has come in software development more recently is UX, user experience, design research. In some ways it’s a bit of an uncomfortable fit sometimes, because as UXers you kind of want to understand the whole thing and Agile is very much about, okay, we don’t know what the whole thing is yet. That’s a tricky balance.

[15:43] Clive: So I disagree with that statement, because if we go back to… It’s really understanding what is the objective of this thing that you’re doing. Am I building a seat? Am I doing something to show you how to book hotel rooms? Or am I building a system that puts a flyer out and asks people to track their moods throughout the day? You have something that you’re trying to achieve, some benefit you’re trying to get out of this, and what you need to do is you just need to explore what that means on the journey to get there. And so this is the whole point. We’ve talked about this, about having a vision. Once you have got a vision about what you’re trying to do, suddenly it becomes a lot easier because people are focusing on the same thing. Once you’ve got a rough idea of who your users are and what they’re trying to achieve, then you know where you’re going, and in software development now, there are a number of patterns that we understand particularly in sort of routine data processing, things like forms that capture information or people booking staff. So you have a broad idea of the types of things that your system might need to do, and it’s really about exploring those things and making sure that you build the right things to allow people to do the jobs they need to do in the most efficient way possible.

[17:09] Chris: So if you’re building that grand vision in two weeks sprints, you are inevitably looking at smaller parts of that bigger journey. Are there any techniques to make sure that you get to sprint A and you haven’t just built eight disjointed things that allow them to do the task, but make no sense when they are combined as one software product?

[17:33] Clive: Yeah, I mean obviously you need to, as you go through, each time you build a new piece, you integrate it into the whole and say does the whole itself continue to work and you’re going to be looking at it from a technical point of view. Does it perform, does it integrate well? Is it responding? Is it a performance? Can we deploy it? But also your users. You’re going to take it back and get them to test it. Test those along the journeys, of course you are.

[17:59] Chris: As an agile coach then, you’re coming in helping teams get used to this way of working, whereas maybe they haven’t before. What have been some the main challenges or common challenges that you see with teams adopting agile effectively?

[18:17] Clive: So the first thing people get hung up on is the tooling. I think it’s all about…. [Unclear; 18:23] has this tool called Jira to allow them to track their product backlogs and they knotted about that, and they think I’m doing Jira, therefore I’m agile but that’s not true. Fragmentations of teams as well. Teams get bigger and bigger and bigger and then suddenly you find our morning stand-ups taking an hour. How do we do that? And so you need to stop and think about are your teams getting too big? How do you restructure them? Ideally a Scrum team you have six people, multi-functional team because you can stay small and nimble, but that’s not always practical. I think the other thing is you have amenities. This is one of the things that we do as coaches. You have people that have different experiences elsewhere and they come to organizations. They have their own view of the world and their own Agile view of things and sometimes those different ways of doing things can clash and I mean, that’s not just with their job, that’s with anything if you are bringing people together. So part of it is getting people, the individuals and interactions species getting those people together and get them to understand what our common vision is, and heading in the same direction. I think if you can get that bit sorted, you’re in a good place, and that to be honest, there’s not really agile. That’s just good practice really, isn’t it?

[19:42] Chris: That’s just making sure people don’t punch each other in meetings.

[19:47] Clive: I mean there is the temptation to drift because oh, we need to keep exploring and we need to keep experimenting and that tends sometimes to be the downside. Whereas it’s not about that. It’s about delivering software frequently and get to a) deliver the value and finding out if from that learning and improving it, there sometimes can be a temptation, and we’ve all been guilty of it through our careers of what’s called gold plating. You keep tweaking it to make it perfect, but you never actually deliver the damn thing, and that can happen all sorts of oh, I need to run one more test. I need to do one more design. I need to do one more round of research. I just need to refactor this code one more time. What you need to do is ship the damn thing and you find out.

[20:36] Chris: Let’s say one of the things that happens during the course of the sprint is developers will typically estimate how long it’s gonna take to… Well not how long, but how much effort it is to build a particular task or story. Does that work or can that work with UX-type tasks as well, or do you need a different approach for understanding how and what UX-related stuff you’re going to be doing within a sprint?

[21:07] Clive: I think that has to do with nirvana. If you could do that, if you can have complete teams sizing of the work, I think that’s an excellent place to get to. It’s really hard because you’re measuring different things, but I’ve never personally got it to work successfully and it’s one thing that I know as other coaches we have talked about and the challenges getting to that point. The other thing that you can get is the… I mean we’ve talked about this, the concept of a runway where you have an idea, you might explore it. So you might have a user story that says – let’s think of something. My favorite one, I need to pay a fee. We clearly know there’s a user story that says I need to pay a fee. At that point in time, we don’t know anything more than that. How is the fee calculated? Technically what payment service provider are we going to use? Do we want to build our own bespoke UI, or just going to use the one by the service provider? Is it going to pop out into its own window? Is it going to be in page? All those things that we don’t know about, and it may be that by the time you’ve answered all those questions, several sprints have gone by. So then it becomes quite difficult to estimate something because by its very nature then it splits across several sprints. So how do you tackle that particular problem? If you’re not careful, you split it down and it breaks itself into a number of different tasks, which is sort of getting away from what you want to do.

The way that we tend to do is we just treat them separately. It’s the pure engineering, the software engineering piece, and we estimate that and the rest of it is more of a how long do you think it’s going to take to go away and investigate this work? What sort of research do you want to do? And then backwards plan it from it. So you might argue, well, hey, that sounds like a waterfall project to me, but you’re not water falling all of the projects. You’re just looking at those bits that you don’t know. So that payment bit you have to say, well, before we build that, we’ve got to understand what it is. We gotta try some ideas, we’ve got to design it and then we’ve got to build it. Meanwhile, there are other parts of the project that are building and delivering software. That’s the thing.

[23:29] Chris: It’s like a spike almost. All right. Well, I don’t know about you, but I’m absolutely freezing and cannot continue this conversation much longer.

[23:41] Clive: All you hear is our teeth rattling.

[23:41] Chris: All right. Well, thanks very much for chatting. Hopefully get you back the podcast again sometime in the future.

[23:47] Chris: Okay. I hope you enjoyed that. Maybe one of these days I’ll actually get a clean recording off this portable mic, but we’ll see. No promises. Let’s do some plugs, so on Twitter you can follow us at @designuntangled. We’re also on Facebook now as well, Facebook\design untangled. You can get in touch with us individually on Twitter at @Chris_mears_ux and @CarlaLindarte. We have a website which is design untangled.co.uk

As always, leave us your feedback comments on Apple podcasts, because that helps us know what you guys like, what you don’t like. Don’t forget to subscribe as well, so you never miss a new episode and we will both see you next time. See you.