Ep. 102: Why you need a toolkit and not just a hammer

Peter: 0:05

Welcome to Definitely, Maybe Agile, the podcast where Peter Maddison and David Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to another exciting episode of Definitely, Maybe Agile with your hosts, Peter Maddison and David Sharrock. How are you today, Dave?

‍Dave: 0:21

Excellent, we were just chatting. We've had quite a few lots going on over the last few weeks and every now and again it's good to recover and feel like you're catching up with things again. I definitely feel like that is happening.

Peter: 0:32

Yeah, you sound a lot more refreshed. You were saying you had a good night's sleep last night.

Dave: 0:39

That's well. We're talking about toolkits and I think sleep is one of those tools in your toolkit. You definitely want to be using a lot more than people do.

Peter: 0:48

Yes, for sure. That is definitely a fact. Yeah, that's the topic of the day.

Dave: 0:53

So let's talk a little bit. I find this a really interesting topic because both you and I we're practitioners and we use very specific tools, and I think both of us have our favorite tools that we bring to the table. And one of the real challenges there is if I have a favorite tool, everything can look like that tool is the right thing for the job.

Peter: 1:16

Yeah, and we can start to try and apply the wrong tool to the wrong problem, and so that's why, it's and this is something that we've talked about, that why it's important to have a toolbox, not a single tool, and an example being that the classic old if you have a hammer, everything's a nail. So it's this idea that if I'm going to implement agile, then that means I'm going to implement scrum, because scrum's the thing I know, and so everything has to be scrum, because then, if it isn't, then it isn't agile.

Dave: 1:51

Yeah, and I mean it's interesting you're stirring the pot a bit there Just a little. Just a tad there. So it's interesting whenever I look at, I mean, if I think about when I left home, right, when you leave home for the first time you often have you can go and buy them right simple toolkits, the basics, and that toolkit will have a hammer. It's got probably a couple of spanners, screwdrivers, a pair of pliers, a saw, things like that, just enough for you to think you'll be able to kind of keep things maintained in your house apartment, wherever it might be, and that starting toolkit I often refer to scrum being the starting toolkit in an agile context it's the beginning of the journey, if you like.

Peter: 2:36

But anybody who's left home for a while.

Dave: 2:39

our toolkit now has had many things added to it over the years because when you're trying to fix something in your house or apartment, you suddenly reach into that simple toolkit that you have. You often find you know this is where you go and get an electric drill, because a hand drill is great for one hole in plasterboard or wood, but if you have to start doing many holes and different materials and so on, you go get an electric tool, electric drill, so you can do more, or whatever else that might be. We go and find and what's interesting is that in that context, that story that I'm describing is you need the problem first, then go find the right tool.

Peter: 3:17

Yeah, and that's the common problem that I see is that it's the. Hey, I've got this tool. Now what's the problem I'm trying to solve? And this is where and the in agile typically uses scrum as training wheels. As we, we've got a method and for us to learn, we follow through and vote until we've got an understanding of, like, why are we doing these things? Why are we applying these practices? Why are we fixing time and seeing what value we can deliver in that time? Why are we understanding these concepts? What does that actually do for us? And as you, as your tools get better and you, you understand them more and the uses that they should be put to, you can understand more about where should they be applied and to what sort of problems should they be applied.

Dave: 4:04

Right. I really like where you're going there, because this it speaks of two things right. One is how do I use the tool that I have more effectively the experience. How can we use it better?

Peter: 4:16

And I think that's.

Dave: 4:17

I mean, obviously it comes with experience, but it comes with effort of learning the underlying kind of principles, things that make it work, and knowing those really, really well. And then the practice of having done it many times. You kind of get the hang of it, and that's the same reason that we go and get an expert to come in and do certain things in our house, because there are things that we can do and there are things where we go. you know what that experience, the ability to use that experience, is more valuable than me trying to gain that experience. So I really like that idea of not just the right tool, but the right level of experience with the tools that we are using really makes a difference.

Peter: 4:56

It does and and that's yeah, I mean context is king it's like what is the problem? What are the? What's the environment we're operating in? How is everything around us? What do we know about the situation that we're in, so that we can start to understand that and decide what is the right thing to apply? I've had many times in my career, where it's been, there's this push for consistency and which results in some somewhat unnatural behaviors. You start to see across the organization and where you you say, for example, that well, yes, we're on the whole organization to be agile, therefore we're going to set up a bunch of rules that be agile and you're not, you're not going to be classifying at the rubber stamp unless you follow all of these to the ladder and even though they may not necessarily apply to you in one particular organization, they had this kind of something which which I thought was almost hilarious in a way is that you had, like the, the normal way of operating, which was very waterfall, standard, pmo type delivery. You had the blessed agile way of operating, which was somewhat restrictive follow these rules. And then they had this kind of middle state which was pick the tools which were appropriate to your context and apply those and my observation from most part it seemed that the people in the middle were getting better outcomes than either of the two extremes and that but coaches that were involved could somewhat see this, but it was difficult to articulate this to the organization that this kind of almost pick and choose model worked better for the diversity of different groups in the organization that were dealing with different types of problems.

Dave: 6:35

Well, I mean, what you're touching on there, peter, is that you know complex problems require innovative solutions. They often require quite unique you know one of a kind solutions for the particular context you're looking at. And yet we come from that sort of mechanistic, factory mindset where we want to stamp out one thing after the other in a consistent way, and the two there are two different problems. You're solving different problems in each of those contexts, so I'm going to talk to about that many times.

Peter: 7:02

If.

Dave: 7:02

I just kind of condensed what we've just been talking about. There's this everything's a nail bit of seeing everything as the perfect situation for the tools that we're fluent in, we're capable of using, is a real risk, right, and we've identified two things. That one is you need a toolkit. You can't just rely on a single tool. You need a range of different things that you can bring to the table, and we also identified experience of being able to use those tools in the right way really comes to the table. What we've not talked about is how to diagnose a problem in the right way so that we go and reach for the right tools.

Peter: 7:40

Right, right, there's. The very simple yardstick I use usually is the starting if I've got, if we're looking at like how are we going to work with this? And if we've got a problem that is large and tractable we're not quite sure where to start, and but we've got a team that from a technical architecture perspective or in a capability perspective, or more teams that can start to develop parts of that solution on their own and that they can come and they can operate in that manner, then you're in a good place where the scrum can fairly easily and likely be brought into that environment. If you're in a more complex situation where there's many, many moving parts, it's more, and you're trying to get to service, I find that applying something like Kanban, where you could start to well, the first part is visualize the system and then start to look at like what is, what is that system doing, and then we could start to apply the right practices over the top of it. But then it's looking at context of what is the problem we're looking to solve. Do you have a big hairy? Am I trying to take the I'm trying to think of saying nicer than Elf and Capaccio, but the idea of slicing a big problem up into smaller pieces to incrementally deliver pieces of value versus the starting where the organization already is. And looking at how do I improve flow through the organization until I can start to maybe form teams that can start to tackle individual problems.

Dave: 9:02

And look at it that way yeah, and I guess the question I was asking is even before that, which is how you might identify the problem. And what I'm thinking in particular is because we talk about measuring everything. We talk about knowing, you know, and if I've got a hammer and a nail, I can measure how deep the nail is going into whatever it is that I'm hammering it into, or how many hammer blows I need, but that's not really telling me. Have I solved the problem? It might be to do with if I'm putting framing, a house or whatever it is, does the frame actually withstand, you know, does it stand up and does it do its job? So I guess there's a couple of things that come in. One is is we don't want to measure the action. We always talk about this outcome over output, but we don't want to measure the action of using whatever it is the tool. We want to measure the outcome, what's the goal? So there's an element of identifying clearly, in the context you were describing, whether it's a you know which tool would work depends on what we're trying to achieve, and then we can use that goal of what we're trying to achieve to really tell whether or not the tools that we're using are the right one. I think that's a really powerful kind of thing to think about of the difference between I don't, I don't measure the action. I measure the outcome and that might help me tweak the tool set.

Peter: 10:14

Yeah, and I think there's those two different pieces of that there. I was talking about it from that objective view, as the. If you come in and ask me as somebody who's advising you as what you should do, I would do, I would start to ask questions about the sort of problem you're trying to solve and how your organization was struck up and how your funding thing and what does all of that look like, and then probably make some recommendations from that. But then there's the second piece which I think you're referring to there, which is that have I implemented that? But once I start down that path and I'm measuring the right things to learn, okay, is this giving me the outcomes I was expecting? I'm looking at outcomes of whatever change I'm making to the system, versus looking at how well have I adopted the framework, which is the more common problem.

Dave: 10:58

Yeah, and I guess whenever I think of if I can go back to what you were saying about identifying the problem, what I've noticed is if I do it on my own, I invariably make some glaring mess or mistake. I miss something right. And this is one of the reasons you and I have this conversation on a frequent basis is because we come at it with different perspectives, so that diversity of experience and expectations when we look at a system is really powerful. So looking at that problem as a group, where you've got sort of conflicting, is the wrong words it's not conflicting perspectives, but you've got different perspectives so that you can then really sort of shine a light in lots of different ways on the problem. It allows us to at least explore, it removes some of that bias around the tooling that our favorite tooling and allows us to really discuss the nature of the problem.

Peter: 11:47

Perhaps yes, definitely. And then getting to that clear understanding. And it requires all those different people having those conversations, talking at it through the problem, looking at it from different angles, and understanding like, well, what would be the right thing to do here? Well, like, what's that first step? Where do we want to begin?

Dave: 12:01

So if we were going to?

Peter: 12:03

take all of this and sort of wrap it up in a nice little bundle with a bow in it for listeners. How are we going to do?

Dave: 12:09

that, yeah, I mean, it started with that very simple Everything's a nail, so stop thinking about it from the perspective of the tool that we're most familiar with or comfortable with. So what would the takeaways be? Number one you need a toolkit. I mean, I think we need tools that we're excellent at, of course, but we need plural tools. We need multiple things that we can pull to the, you know, bring to the table.

Peter: 12:35

And I think the important thing, when we talk about having a toolkit, what do we actually mean? History? So we mean having different frameworks, different models, different ways of approaching problems, understanding how these applied into different circumstances, different component parts of that that can be applied to. Hey, I need to. I want to work at how to prioritize. Well, here's multiple different ways you can go about prioritizing work or looking at work. Here's multiple different ways that you can go about defining what a good way of breaking this work down might be that kind of thing. So this is what we mean by a toolkit, because I don't think we really quite covered that.

Dave: 13:12

Maybe I think the other thing that came out in the conversation is measuring the right doubt, if you like, like understanding the difference between activity, the use of the tool versus the results of using the tool. And there's lots of statements around that, whether it's output versus outcomes or being value focused and all of the rest of it but really is understanding that problem in the context of what does success look like and are we moving it towards that success? Because I think we didn't touch on this, but the tools might change depending on where you are on that journey.

Peter: 13:46

Yeah, and I think we touched on the. There's that learning element right as well. It's like well, if you're only measuring adoption of the framework you're putting into place, you're never going to know whether it's actually being effective, because you're not measuring the outcomes, so you're not going to be able to course correct if it's taking you in the wrong direction.

Dave: 14:07

Really, Anything else you might add?

Peter: 14:09

I think there's those couple of points which are kind of related around context as king, like knowing what to apply where, requires understanding the environment you're operating in and all the different elements of it, the context you're operating from. And to get that understanding of that context, you need diversity, you need different perspectives, you need understanding so that you can have the insights into what's actually happening. There's almost another part of it's like but do start, and it is the other part of it as well. Don't spend all of your time in just analyzing it. All there is that. There is that.

Dave: 14:50

Yeah, there is that. Grab a hammer at some point, right.

Peter: 14:52

Yeah, you will actually start it. Otherwise, you spend all your time designing the perfect deck and it never gets built For sure. Okay, awesome, well, it's fantastic conversation always. I always enjoy these. So thank you, dave, and if anybody wants to send us feedback, they can at feedback at definitelymaybeagilecom. And don't forget to hit subscribe, because we always like new subscribers and we always like the conversations we get.

Dave: 15:16

Grant thanks again, pete.

Peter: 15:17

We're always a pleasure You've been listening to Definitely Maybe Agile, the podcast where your hosts, peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.