Dysfunction Mapping with Michael Lloyd

Join Murray Robinson and Shane Gibson as they chat with Michael Lloyd about dysfunction mapping.

Whether you are new to the agile world or a seasoned professional, you’ll find valuable insights as we delve into understanding team dynamics, honing the coaching process. And the essential principle of iterative hypothesis testing. Join us as we learned the power of mapping dysfunctions to unveil powerful solutions in agile environments.

Read along you will

Shane: Welcome to the No Nonsense Agile Podcast. I’m Shane Gibson. 

Murray: And I’m Murray Robinson.

Mike: And I’m Mike Lloyd.

Murray: Hi, Mike. Thanks for coming on.

Mike: Thanks for having me.

Murray: We want to talk to you about dysfunction mapping before we do that, can we get you to tell the audience a bit about who you are and what your background and experience is? 

Mike: Yeah, cool. I’m Mike I’m an Agile coach, I’m a scrum master, but I got my start in tech support. So I always knew I wanted to work in tech. That was an easy way in. And being the guy that answers the phone and logs the tickets when something breaks, gives you a really good view of how different teams work. My first brush with this agile thing was about 10 years ago now when I went to a team in the organization I worked with, it was a bank and said to them, Hey, we’re getting a lot of complaints about this broken part of the system. You think maybe you could fix it and they were like, Oh no, no. It takes nine months. You’ve got this giant backlog of things. . And I just thought that was really strange and bizarre because the same day I’d been speaking to this, other team that told me, yep, cool, give us two weeks and we’ll have a bug fix for you. So it was just clear to me there’s different ways of developing software. One of them clearly seems more effective. I wonder why that is. I’ve got to learn about this. And I realized that’s what I wanted to do. So that’s when I started developing my BA skills and tried to find my way into a scrum team. Eventually figured out the scrum master role was something that I really enjoyed. And the rest is history. I’ve been, doing scrum mastery and agile coaching now for about probably seven, eight years.

Murray: Oh, great. Your core skill was business analysis, Scrum Master and then you’ve been working with mainly software development teams. 

Mike: Yeah. Got into business analysis because I’m a bit of a nerd and I like to understand how things worked and so it felt like a good way to get into a scrum team. But as soon as I discovered scrum mastery, that became my focus. So to be honest, I don’t think I became a very good BA. I wasn’t doing it for that long. So I try not to oversell myself as a particularly deep technical practitioner. I’ve been there in the trenches with teams building stuff, which has given me enough of a view of what was going on. And then obviously being a scrum master for the first few years. Then also dual hatting it as a BA and even a tester at one point. It gave me a lot of chance to see the different parts of product development, which was really cool. 

Murray: Okay. All right, good. 

So why did you come up with dysfunction mapping? What is the problem you’ve been trying to solve here? 

Mike: Yeah so I guess there’s, two parts of the story. So the first was just my journey as a scrum master and an agile coach and figuring out how to be effective, how to actually help people to change and, to solve problems. And to be honest, the first couple of years I was doing it, I wasn’t very good at it. I was solving a lot of the wrong problems, making a lot of mistakes, as a lot of us do in the beginning. Once I eventually started figuring out the patterns, I was following a somewhat repeat approach to helping teams that would start with writing stuff down, looking for themes and looking for connections and what’s the most effective thing that I can help with. After a while, as I looked around the industry and I started being more active on LinkedIn meetups. It became clear to me that there’s quite a problem in the the agile industry as a whole, in that we don’t really support our practitioners to grow. A lot of us are overly obsessed with the two day introductory workshops to some particular framework, but we’re not actually helping people to grow as practitioners in solving real problems. 

So I thought to myself could I take this approach that I use? Become repeatable for me and put some structure around it and teach it to other people and see if it helps them. And so that’s what I tried to rapidly test by getting it in front of a few people at workshops, . And yeah, since then it’s just exploded. A lot of people seem to be having success with it, finding it useful. So I just want to use it as a way to give people a jumping off point to, to get better at actually solving problems.

Murray: How are people solving problems before? Because I would expect that what they were doing was having retrospectives and discovering problems there and working with the teams to come up with solutions, and then trying them. What were you seeing people doing?

Mike: There’s, a few things that I, certainly I fell into the trap of a lot, and I see other people falling into the trap of, and So, one of those is what I call firefighting mode, which is that as soon as we start with a new team or a new organization, we see lots and lots of things that could use our attention. And so we end up just jumping in a very reactive way to lots of different things and not necessarily being able to step back and look for those themes and patterns and figure out what the most important thing to do is. But then the second is just the analysis paralysis that comes when you do start trying to solve problems, because you don’t necessarily know which things are going to be effective and which things are going to have the outcome that you want. So it’s really easy to identify something out of retro and come up with an idea of something you can do, and that a lot of the times can be super effective but a lot of the time you don’t actually know if your outcome has been achieved. And so this is just about giving people a bit of a structure so that they can get to what I call a hypothesis based plan that says, I think if I do this, I should see this outcome, and then that’s a little bit easier to check empirically in the real world.

Shane: So one of the things I often see is coaches will go in with the answer, regardless of what the question is and then some other coaches will identify some problems they think the team have, and then they go back into the retro to see what the team thinks. What do you see? 

Mike: My experience, at least in terms of coaches that I’ve observed and talked to in the real world is that more often than not, they get in and just start doing stuff. They want to start making a positive impact right away, but that usually involves just starting too soon in my experience. That’s what I think was one of the mistakes that I made a lot in the beginning. So I’d start with a new team and I’d be like, Oh you’re not setting Sprint goals and I know that Sprint goals are good. So you should set Sprint goals. And maybe that’s true, but there’s all sorts of contextual reasons why the team might be doing what they’re doing, or there might be other things that are more important for them to work on. And that’s why one of the things that I’ve built into dysfunction mapping that I teach in the workshops is actually the first couple of weeks is just about observing. It’s about deliberately not trying to make a change and making sure you understand the system so that when you do make that action, you’ve got a little bit of a baseline of what was going on that you can test against with your hypotheses and see if things are changing.

Shane: Do you find some customers don’t want you to observe? They just want you to, fix the problem.

Mike: Yeah, if the CEO comes in and says. I need you to solve this problem right now. It can be a huge amount of pressure to say no to that. Or to push back or to say, actually, I think we need to observe and wait. And so over time I’ve learned how to stand my ground on that. And I think that’s an important part of growing into your own as a coach. But interestingly, again, it’s one of the reasons I build it into dysfunction mapping. And in fact someone who came. Definitely work with that and we’ll get more done. I’ve had great user feedback came to a lot of my workshops as now use dysfunction mapping said to me that one of the. Most immediate quick wins that they got from having this tool in the tool belt was the ability to say when someone came to them and said, hey, why aren’t you doing stuff? I need you to fix this problem. They could say, I’m employing this approach called dysfunction mapping. And it starts with this two week observation period. And it’s almost like it gives them a little bit extra authority. It’s not just, Oh, Hey I’m sitting around. It’s I’m deliberately following this process. And so it gives them a little bit more space to hold their position and say I’m understanding the system right now. And we’ll start changing things soon.

Murray: Should a coach have knowledge or experience of software development or agile teams, or should they be somebody who is, more of a, counselor, psychologist? 

Mike: So my personal opinion is that they should be the former, they should be the person who has some experience of this. I do get worried by the coaches that are just completely generalist outside of software and are now trying to coach software teams. I sometimes worry about my own deep knowledge on some of these things. And I think that anyone who doesn’t have a lot of deep knowledge should question whether they have enough to help teams. But I think ultimately you need to help the teams to come to their own answers. There is certainly a certain amount of knowledge of their work that you need to have to help them come to those answers. I don’t think it’s zero. But I also don’t think every coach needs to be a a 20 year veteran as a hands on developer or a tester . 

Murray: Yeah. I think a good agile coach is like a sports coach. They’ve played the game. They have the skills, but they also are able to motivate and inspire and help the team and don’t have to just provide it all. They’re not on the field, but they have the ability to see problems because they’ve seen them before and know what potential solutions are, but they don’t impose them. They let the team try and come up with something and then offer the, to the team,

Mike: yeah I agree. And I think the thing that I’ve seen in the wider agile coaching community is a rift between these two approaches to coaching. One is you have to be a detailed, knowledgeable practitioner that can give people answers. Or you have to be a coachy at the side not really giving people direction. More knowledge of the work makes you a less effective coach, is the way heard that articulated. And I guess my view is that both of those extremes are a bit silly. The answer is obviously somewhere in the middle. I would lean towards, you should acquire more technical knowledge and aim to treat that as a gap and plug it as such. You shouldn’t ever just be accepting of I have this small amount of technical knowledge and I won’t acquire more. But I also don’t think that should be the most important thing that you gain is more technical knowledge of how teams do stuff, it’s more about the team aspect. 

Murray: Yeah. I like S Esther Derby’s model, which is that a coach is a consultant who can have responsibility for building capability and responsibility for delivering outcomes depending on what the client wants. And as part of that, you have a toolkit and in your toolkit, one part of it is, the personal coaching, psychology stuff. But that’s just one of nine things you should be able to do. 

So let’s move on and tell us about dysfunction mapping. How does it work?

Mike: So at a high level, it is just a way to organize your thoughts by capturing things on stickies and going through a process of connecting them. The first stage is what I call forming a funnel, which is that observation period. It’s just observing the system, writing down the things that you see that make life difficult, that people complain about. And then you go through this process of trying to figure out which things are symptoms or dysfunctions and connecting them in that way. A symptom is a negative outcome, whereas a dysfunction is like an abnormality or an impairment to some known good way of working. So an example of that would be if you’re a scrum team and you’re breaking the rules of scrum, that would be a dysfunction. And so what you’re hypothesizing by going through this process is saying I believe that the fact that we’re breaking this rule of Scrum could potentially be why we’re seeing these negative outcomes over here. And then you have to go through this step that I call defining purpose, which is why does that rule of Scrum exist? This comes again from my experience as a coach and a Scrum master of sometimes jumping too quickly to implement a rule. I didn’t fully understand why it was there what value added. So once you’ve understood the purpose, then you can come up with your action. What’s the thing that you’re going to do, your solution that might help that purpose to be understood. And then obviously you can go ahead and do that in the real world to see what happens, but to test it, you need a measure.

And the final step of dysfunction mapping is what are you going to measure to see if that action does have a positive outcome? And I talk about closing the loop on dysfunction mapping because actually your measures are just a reframing of your symptoms that you started with right at the beginning. 

What’s the negative outcome that I was seeing and what’s a way that I could measure if that negative outcome were to be lessened or to go away. So it’s a linear process in terms of coming up with a map, but it’s designed to actually be iterative. So it’s something that you would come up with a hypothesis, test it, see what happens, either you get the outcome you expected or you don’t, in which case you iterate, you try again, and you just keep learning more about the system as you go. 

Murray: So let’s go through it again in more depth, maybe step by step. So I understand the first bit. You’re a coach. You come in, the first thing you should be doing is just collecting observations, which could be a mix of problems. A common one is the Team never come close to achieving what they put in their sprint plan. Are you doing it yourself or are you doing it with the team?

Mike: So it depends. It’s always collaborative to some degree. So the way I often describe it is it depends on like the level of psychological safety and autonomy that you have in the organization. Because in some organizations you literally can’t even talk about dysfunctions cause it’s not safe. People don’t like talking about things that are not good. And so in those places, what you’re probably not going to do is get everyone in a room and build a dysfunction map together. So what you should do instead is at each of those stages, find ways to collaborate with people. At that stage, and then the map becomes your tool to build the hypothesis that you would then make transparent via a coaching kanban board or something like that, where you show the actions that you’re going to take, not necessarily all of the work that went into the map. But if you’re in an organization where it is very safe, where you can collaborate with people quite openly then yes, this could be done as an entire group activity. You could use this as a a frame for a retrospective. There’s no right or wrong answer really, except that I guess a wrong answer would be trying to do it entirely by yourself behind closed doors, because that’s probably not going to lead to any good outcomes. 

Murray: I’m just looking at an article you’ve written in Medium called Dysfunction Mapping. You’ve got a picture here. Is that the best place to go for a reference for our audience? 

Mike: For now, probably, yeah, there’s also a couple of YouTube videos of talks if you’re more of a video or audio learner. But yeah, I think until I finish the book, the article is going to be the best reference. 

Murray: Okay, so you start with the symptoms. And then you’re trying to work out what the dysfunctions are based on your experience, and maybe what other people are saying.

Mike: Yeah the extra thing I would add is the dysfunction sometimes are some of the things you’ve already noted down. So you might look at something and say, oh, could this be a dysfunction or could it be a symptom? And there’s, again, there’s no right or wrong to this. It is just a hypothesis, but usually the the lens for is something a dysfunction is number one, could it cause multiple of these symptoms. And number two, is it a known good practice or something that we’ve said that we wanted to do or should be doing that we’re now not doing? So, symptoms are negative outcomes. so you’ve got them on the right. 

Murray: Then feeding into that, because we’re going from the right to left on this board, we’ve got negative patterns, which we’re calling dysfunctions. So give us an example 

Mike: So I would usually suggest more than one symptom. That’s how you go after the biggest wins first. So an example, one that I use quite a lot because I’ve seen it quite a lot is like you mentioned, teams that are struggling to finish the stuff that they’ve pulled in at sprint planning, like consistently just. Not finishing a lot of work. They might complain that they’re overworked and that they feel like they never get any time to upskill or that thing, or they’re always working late shifts. Or the CEO might complain about the team and say that they don’t think that the team is particularly good at actually delivering value or delivering on their plans. So there’s several things you might observe that clearly feel a bit related. And now as a expert practitioner, that’s maybe seen a bunch of things before. I might see, oh, this team either doesn’t set a sprint goal or they set multiple sprint goals. They don’t have a single clear focus sprint goal for the sprint. And I think that if they did set a clear focus sprint goal, it might help alleviate some of those problems. So that’s the hypothesis then that I want to test. 

Murray: Yeah. And similarly I’ve seen the thing where the team are using story points. Last sprint, they did 31. Before that they did, 20. The one before that they did 40. So the average is 30, and yet they continually put 120 into their sprint. And why is that? It’s because there’s pressure from the product owner and from management too, because they’re behind. 

Shane: Don’t forget, they put 130 in the sprint for new work to be done, as well as adding the 50 points for the last sprint that they didn’t deliver somehow they’re going to go from there. Average of 30 to this magical, 200 or in a sprint. And they wonder why they don’t get that done in an iteration. Oh. And of course then there’s the stuff that was BAU that they forgot to exclude time out for. They just happened to be busier, this iteration and they’re screwed.

Murray: So these are all, potential reasons why, yeah, 

Mike: Yeah and the thing that’s interesting there is that we’ve all identified three potentially different dysfunctions here for the same set of symptoms, so I’ve said it could be Sprint Goal related. 

Murray, you’ve said that potentially it’s because the team is not paying attention to the historical velocity and planning appropriately. And Shane, you’ve said maybe it’s because they’re planning their work. And pulling in a bunch of extra stuff from previous sprints, so there’s three potential dysfunctions we’ve identified. So not only does that mean we’ve got three different ways we could tackle this problem, the cool thing that I’ve seen in the real world is that all three of those dysfunctions could be used as a, hypothesis that does achieve a meaningful positive change, as long as there’s something that you say I can help the team understand why they might want to change. And I think it might address these symptoms different coaches can come up with different plans and they can still be effective, so that’s what makes it, in my opinion, quite a fun, cool process. 

Murray: yeah. 

And I also like that , having brainstormed your symptoms and now we’ve come up with these different types of dysfunctions, you can say, Hey, hang on a minute. This might also be causing this other symptom. So there’s a many to many mapping, which could be quite helpful to understand.

Mike: And as I mentioned at the beginning this is that way of identifying which things you should go after first, because if you iterate through this part of the process a few times, what you’ll usually get is a candidate dysfunction that you’re like, Oh, wow, there’s 20 things attached to this. Clearly, this is the thing that I should go after first. Now, again, that doesn’t necessarily mean that everyone else looking at the same system would come up with the same approach, but it is a relatively quick way of getting to something that looks like it’s going to have a big effect. 

Murray: All right. So then moving on to the left on your Kanban board, the next column is purpose. How does purpose map to dysfunction? What are we trying to do here?

Mike: So it was two things. It’s one is trying to flip the negative into a positive because dysfunction is a negative really, we’re talking about stuff that isn’t going well, and we want to try and turn our coaching activities into focusing on the good, which is what do we gain by doing something differently? 

What’s the purpose of this thing that we’ve identified? So for example, setting sprint goals what’s the purpose of a sprint goal or planning based on historical velocity rather than arbitrary numbers why does that offer a benefit to us? And the reason that’s important is because as coaches, as scrum masters, we can often fall into that trap of, this is something that I’ve read in a book that we should do because my favorite Agile practitioner told me it’s good, or this is something I’ve seen work for another team in the past, so I want to implement it here. Whereas what we should be doing, in my opinion, is focusing it in on what do the people around us gain by doing this thing, by changing their behavior in some way, and how can I then find a way to articulate it to them in a way that they’ll buy into. So rather than just saying, hey, we should use Sprint goals because the Scrum Guide says so, I can say, hey, did you know that Sprint goals are a way of providing focus and clarity and allowing us to create plans that aren’t overburdened with too many unrelated bits of work. And that’s a much easier way to get people on board with changing the way they do things than beating the rule book. 

Murray: Okay, so give us an example of the purpose for these things we’ve just been talking about. The symptom is that they never complete what they said they were going to do in this sprint. I’ve got those three possible dysfunctions. No goal, not using historical data, and 

Mike: automatically rolling work from previous sprints and other work in addition

Murray: how would you change those into a purpose? 

Mike: My guide for people, and you can test this as we go, is it should be something you can say to a person that’s not a Scrum Master or an Agile coach, and they’ll be like, Oh yeah, that makes sense. It shouldn’t just be something that we understand. So for the sprint goal what I would often say is something like sprint goals create focus and enable rapid decision making. So they help us to make quicker decisions about work that should or shouldn’t be in the sprint . For the not using historical capacity information. Why do we want to do that? Using historical data allows us to create plans that are based in reality of what has been done and not guesses about the future. And then the third one allowing things to roll sprint to sprint, let’s simplify that as, the purpose of not just rolling your work into a future sprint is so that we don’t get stuck in the Agile death march. 

Different people are going to come up with different answers to this. It doesn’t necessarily matter that we disagree on what the purpose of this thing is. The question is, is it something that brings people on board? Is it something that you can use to get buy in for change? And if it is, then it’s serving its purpose.

Shane: Okay, any benefit or outcome we can describe, that people nod and go, that sounds like something we should be achieving, let’s be doing. Let’s have a bet. Let’s do the hypothesis and see whether that change is going to achieve that outcome, then it’s OK, so everybody thinks in different ways. Organizations see value in different things, so as long as everybody’s going, it’s worth trying that, because if we did and we achieved that, that’s a good thing, then that’s what you’re looking for, oK, makes sense. 

Mike: The reason I actually often talk about this as being the most important part of the process is that we often fall into the trap of just beating the rule book. This is some theory that I’ve decided we should follow, and this is about making sure that we understand before we try to get other people to change their behavior. So as long as we can articulate to people in a way that they understand and that they get they get buy in for, we’re probably in a good spot that we can start influencing change. 

Murray: Yeah, I like that. And also you’re saying here that some of your goals could map to multiple dysfunctions 

Mike: Yeah, absolutely. So every section of dysfunction mapping can often be one to many relationships. Dysfunction to symptom less but almost everything else. But yeah, again, the cool thing as you get to your purpose statements is you might write that purpose statement and say, Oh yeah, that also applies to this other dysfunction down here. So potentially I’ve multiplied again the power of a single activity that I could take because understanding both of these things could affect multiple of these dysfunctions.

Murray: Yeah. Alright, good. So then working to the left again, you’ve then got solutions. Take us through those. What do you mean by that? 

Mike: it’s called solution because I wanted everything to be one word along the top, but really it’s solution hypothesis. This is about saying, okay. I’m going to take some action and the reason for that action is I want people to understand that purpose that we just talked about. So I’m not just implementing a process or approach that I think is going to be better. I want to think what’s something I can do that will help that purpose to be understood or fulfilled. So it shift that coaching away from that mechanical implementation that we talked about earlier that can sometimes be damaging and into how do I empower other people to find a way to change. And sometimes that action can be as simple as I’m going to be a facilitator and I’m going to get people together and talk about this problem that we’ve all observed and. Support them to come up with an approach. It might be things like bringing data to the team so they can see a pattern that maybe they’ve gotten so used to that they stopped seeing it. And in the workshop, I give people some extra tools to help guide them through coming up with actions. And there are things in there like the six stances of a scrum master and the pillars of empiricism and the idea is just . To look at these things and say, could this be a tool I could use to help someone understand that purpose that we just talked about? And if it is now I’ve got the basis for my hypothesis. Something I can go and do and see what happens 

Murray: So give us some examples of solutions for the problem we started with, which was that the team never, completes what they said they were going to do in their sprint. 

Mike: There’s a couple of things that I might do. And again, these might be different for another practitioner but I might, for example, , bring some data to the team. I So let’s say the team does set sprint goals, but they don’t set a single sprint goal, they set two or three or four. Maybe there’s some data I can show them that shows the fewer, the number of sprint goals, the more likely you are to get stuff done. That would be really cool data to show them and then see if that has some impact down the line. 

I’m thinking through these cards from the workshop, so let’s say I draw the facilitator stance. I might say, okay, let’s get together the developers, the product owner and myself, and talk about all of these negative symptoms and share with them that the sprint goal is this thing in the scrum guide that might offer a solution. And what do you think about that and see if that leads or prompts a discussion. 

I might even be more active and go into teacher mode and organize a workshop on sprint goals and how to define sprint goals and why they’re effective. It’s almost an unlimited number of things that I could do, but the thing that I’m anchoring it to is, will this action help that purpose to be understood? Because if it does, that might then impact our dysfunctions, which then impact our symptoms.

Murray: Can you just summarize the six stances of a scrum master? 

Mike: So for those who haven’t read it, Barry Overeem’s article is a fantastic resource, but all scrum masters generally operate in different stances as the need arises and their skills that you should always work on developing. And so those are things like the facilitator, the impediment remover, the teacher, facilitator, mentor, coach, change agent, I always forget change agent and it’s probably my favorite one actually. 

I use these printed on cards, because the idea is you can look at a purpose statement. You can pull any one of those cards and then just say in what way could acting as a facilitator help this purpose to be understood? In what way could acting as a change agent help this purpose to be understood? Again, no right or wrong answers. It’s just a way to get your creative juices flowing and get to a hypothesis that you can test. 

Murray: And what was the other tool that you used to help come up with solutions? Was it around values 

Mike: Yeah. So there’s a bunch of other things in there. 

So for example, yeah, the scrum values are in there. So how could I use focus? How could I use commitment or respect or openness? I’ve got the pillars of empiricism. Could I use transparency? Could I use inspection? Could I use adaptation? There’s constraint cards, like leadership or scaling. There’s things like pairing and expert specialists. They’re just things that are ideally meant to just trigger a thought and say, Oh yeah, I could talk to this person or I could try this thing or have this conversation. And sometimes you’ll draw one of those cards or try one of these things and think, I actually know that that doesn’t really apply in this context. That’s fine as well, because again, it’s just about trying to get that creative process going. 

Murray: Are these cards you’ve developed, or do they come from somewhere else? 

Mike: Yeah I’ve developed the cards, but they’re mostly, like I say, based on concepts that most scrum masters would be familiar with. A few extra things I’ve thrown in there. I have actually just today received my very first physical printed set that I’ve been testing that I want to try to make available to people, but they’re available on. My LinkedIn page, and I’m going to be putting them in a Miro template soon that people can access so that they don’t have to buy anything that they can just play around with them on their own time.

And so the reason they even came about was because as I was developing the workshops, teach dysfunction mapping to people, I realized that this was the biggest, obvious gap because every other step. Anyone can identify negative problems. if you’ve got even a basic understanding of scrum, you can probably identify what some broken scrum rules look like. Purpose is very much about you just have to think and self reflect. When I got to solution, I realized that If I was doing this eight years ago when I was a brand new scrum master, I would be lost at, oh, just come up with a solution, as if it’s that easy. So exactly like you say, it’s about giving people a bit more guidance. What I am hoping to do soon though, what I’ve been working on in the last couple of weeks is gamifying the whole process and actually coming up with sets of cards for everything other than the purpose step. So that I can give it to people in an unfacilitated fashion, because right now the only real way to get. Really into this is to come to one of my workshops that doesn’t scale very well. So I’m hoping that if I gamify it a little bit more and put all these digital cards on a Miro board, then it’s a lot easier for people to just guide themselves through it. And so my real goal is to just help as many people get better at this 

Murray: All right. So we talked about solutions. 

Now these solutions are hypotheses, I assume, from what you said before. We don’t know if they’re going to solve the problem yet. 

Mike: That’s right. so the idea is to come up with a hypothesis statement that says, I believe if I take this action, it will help the purpose to be understood, which might therefore make the dysfunction go away, which would lessen or remove those symptoms. 

Murray: All right. So now in order to test this, we’ve got to come up with measures. So that takes us to the next thing. 

So talk us through measures. 

Mike: In my mind, my experience you can’t test a hypothesis without measures. I do sometimes get people pushing back on that statement. So I don’t know how contentious that is, but it feels fairly obvious to me. You need to know if your action is the thing that’s created change or at least directionally, if the things you’re doing are taking you in the direction that you want to go. And that has been, in my experience, one of the hardest things about creating plans for change. It’s like, how the hell do you figure out what to measure? There’s so much noise out there about agile metrics and all that stuff. I guess I wanted to make that easier for people. 

And that’s where this whole process sprang from is because while it looks linear, it’s actually a loop because once you get to the end and you want to measure something. What you really just need to do is look back to the symptoms that started this whole thing, and then pick one of them and say what would I expect to see change if this symptom went away? And again, in the newer workshop that I’m working on with the cards to help people, I give them examples of ways they can simplify that. 

Obviously you’ve got The things that are quite well known, like flow metrics. But you can even do simple, softer metrics, like surveys or checklists or fists of five to just check in and see if things have moved in a certain direction. The thing I’m very clear about in the workshop is it’s not about just trying to prove that you’re an amazing scrum master or an agile coach. It’s not about metrics of success in the traditional sense. This is just a metric to say is my hypothesis accurate? Do I understand the system in the way I think I do? Did my action have an outcome in the direction I was expecting? 

Because if I do, cool, now I can iterate and I keep trying to build momentum. And if I didn’t I’ve learned something now and I can have another stab and see what new hypothesis I can come up with. 

Murray: Yeah. So for our example, which was the team never deliver what they plan to in the sprint. Fairly obvious measure is how much of what they said they were going to do, did they do? Maybe they start promising to deliver a lot less and do more of it, but it’s the percentage, that might be one measure. 

Mike: Yeah. This is just about, did I have an impact in the direction that I wanted? So those sorts of metrics, you don’t even necessarily need numerical figures written down. You just need a direction. You just need to know, did this percentage go up, down, or stay the same? That’s enough to give you a sense of whether or not you’re moving in the right direction. But again, there’s multiple metrics you could potentially grab, to try and get a better sense of this. So you could look at, yeah, does the number of let’s say product backlog items done at the end of the sprint as a percentage go up or down? You might just do little things like how often does the team actually achieve a sprint goal? Because that’s related, and that was one of the negative outcomes. You might even just do a survey, out of five stars, how do you feel about the ability of the team to deliver value? Product owner, CEO, stakeholders, what do you all think? One metric probably can be gamed, but if you can get three or four cool. Now you’ve probably got enough to get a good sense of, have you had an impact in the direction? 

Murray: Yeah, I was just thinking about a couple of projects I did, which were around performance improvement in systems. For example, I worked for Big Telco that if you wanted to, as a business, to buy a mobile phone, it would take 12 minutes to go through their online digital ordering process, and they wanted to get it down And we got it down to six minutes. But what was really interesting about that was that we had a group of people come up with hypotheses for what they could do to improve and we put all the measures in and they did the first one, nothing happened. Second one, nothing happened. Third one. Little improvement. Fourth one, small improvement. Fifth one, big improvement. If we’d started with the fifth one, I think actually we would have seen the same pattern. 

Because what was happening was we had to remove bottlenecks in the process in order to get the measures to move. And we actually didn’t really know what the real bottlenecks were. We obviously, we had five things we thought might be bottlenecks. And we actually had to remove all of them before suddenly the dam broke and things started flowing through. So I was wondering if you’ve had that sort of experience as well. 

Mike: Yeah I mean certainly in terms of the actual team changes and hypotheses, it’s sometimes something looks simple on the surface and it looks like there could be a one to one relationship. Oh, if the team would just set sprint goals, this thing might go away. But actually the reason that they weren’t setting sprint goals is because they had been setting sprint goals in the past and there was actually a CEO coming in, breaking the front door process and pushing work into the team, and so that doesn’t have the impact you wanted it to, but maybe that’s made visible by the thing that you just tested. Maybe once you start setting sprint goals and talking to the team about it, and then the CEO comes with extra work and now you can observe that’s happening, we’ll call now you’ve got something for your second stage hypothesis. But I overall the other thing that I just repeat to people throughout the training is it isn’t a silver bullet, this isn’t a process that’s just going to give you a perfect answer or a magic outcome every time. It’s just a way to get to a hypothesis and you need to remain vigilant. You need to be creative and you don’t want to just get trapped in trying to go through it as if it’s a paint by numbers approach. This is just a way to get you to that way of quickly testing hypotheses, because it’s that mindset in my experience that makes for a good coach, not the actual approach to get there.

Shane: So you’re saying there’s no big A3 PDF document with boxes and lines and exact answers on how to do this? It’s a toolkit that you just gotta use and get value out of. I see, that’s good. Is there a certification? 

Mike: I just had this conversation with someone today on LinkedIn. And so I don’t offer certification quite deliberately. What I do give people is a badge when they come to the workshop and I’m not entirely sure if that’s better or not, but my reasoning for it is people like to get a badge. It’s nice to have something to show you’d learn something, but what I’m not going to do is try and certify you as a dysfunction mapping person, because the thing that certifies you a dysfunction mapping person Is Did you use it to solve real problems? Cause if you did talk about those problems, don’t talk about the badge or the certification. That’s the thing that matters. And you might also evolve completely away from my process and come up with your own. That’s cool as well. I don’t want people following the process. I’m not in this game because I want dysfunction mapping to be the thing. I just want people to get better at coaching and solving problems. 

Murray: Leaving money on the table, Michael. 

Mike: Always. That’s the story of my life. I do worry that at some point in a couple of years, if I continue to get successful with this is McKinsey or KPMG going to start selling dysfunction mapping as a way for one of their consultants to go in and create a big flashy document based on dysfunction mapping with all these symptoms and problems

Murray: I did want to just reiterate that if you’re working on fixing something that is not the bottleneck in the process, then it won’t make any difference to the outcome. But the problem with this is it assumes you know what the bottleneck in the process is. And we actually don’t. It’s all experimental, really. So I really like your approach of just reiterating that these are all hypotheses. We’ve got to try things and see what works.

Mike: Yeah. And that is a big driver for why I came to this, because it’s something that I discovered a bunch in the early days of my career was that you. Change something that you’re certain is going to be the thing to change. And actually nothing happens or something gets worse sometimes. It’s like the approach for me of a good coach is one that can rapidly come up with an idea, get other people on board to iterate it and then test it and then keep doing that over and over again, because eventually you’ll figure out where the real pain is. 

Murray: So my experience is that the team can improve their own internal processes fairly quickly, but before too long, you’re going to be running up against organizational issues. In other words, there’s a big system around the team, which is demanding certain things or trying to make people work in certain ways. And it’s actually that system, which is causing the problems inside the team. So it’s not always the team’s fault. How do we deal with that here?

Mike: There’s a couple of things I think. From the Scrum perspective if that’s the lens you’re using and you don’t have to, but a Scrum master supports both the team, the product owner and the organization. So there are particular things in Scrum that are designed to push you in the direction of examining the organization, and I think that naturally comes through. But then secondly you can think about other wider approaches or tools that you could use as your dysfunctional lenses. I like things like the no estimates movement or beyond budgeting. There’s stuff out there that we can point to that we can say that seems to have been successful in a lot of places. Maybe if we use that as a lens for dysfunction, it gives us something we could try to solve some of these bigger problems and then just treat it the same way.

Murray: Can you walk your executive stakeholders through the dysfunction map Have you tried that? How does that go? Do they get it? 

Mike: So I’ve tried it. In the full transparent context in one organization. And it went quite well, but that was after I’d built a fairly good relationship with the CEO and I’d showed her in private and then she was like, cool you’ve got to show my exec team this it was essentially like, here’s the next 18 months of stuff that we could solve, let’s get some buy in for it. The problem with that, like I alluded to in the beginning, is some organizations, don’t want a person to come and say, Hey, here are all the places where we can improve. It’s who are you to say this? Or what do you mean? We’re not perfect. 

So the, thing that I, often do, is try and find a way once you’ve formed those hypotheses to convert them into a coaching Kanban that says here’s a negative outcome that we want to solve. Here’s what we’re going to do and here’s what we’re going to measure. So you can pull it away from all of the individual symptoms and potentially the things that people have complained about, or that might ruffle some feathers and instead just focus on here’s some stuff that we think we should do. And that you can definitely share with execs, with CEO, with senior leaders. 

Shane: Yeah. because I can see just like velocity and just like retros this could be turned into a weapon, oh, your team’s so dysfunctional and the name doesn’t help. You’ll go on, I’ll get a new leader and I’ll I’m doing the air quotes a new micromanager to come in and sort out that dysfunctional team. So yeah, I think you’d have to be careful about the organizational culture, how this is exposed up the leadership chain.

Murray: Yeah, I like your approach of bringing in people one on one and working up the chain. and getting support that way. 

Mike: Yeah. especially when you can use those symptoms as a link as well. So like I said, the way I treat it is at the very least, each one of those steps, symptoms, dysfunctions, purpose, each one of those represents a conversation you can have with someone. But every one of those conversations can be anchored back to those symptoms. Why are we talking about this? Because remember you talked about this problem over here, you were complaining about this challenge and this is related and it allows you to always draw it back to the things that people have been observing or feeling. 

Murray: Yeah. It’s great. I would really like this as an exec if one of my teams was doing this. Okay. have you got any stories of where you’ve worked with an organization to do this? And so you can tell us what the outcome was after doing it for a while. 

Mike: Yeah. cool. The interesting thing about this is that it started just as a thing that I was doing as a coach. So before it was formally called dysfunction mapping, I was following this process. And so the most success that I ever had in a role as a scrum master was when I worked in New Zealand for a place called education payroll. When I started, they were in a pretty good spot, I think actually one of the things that made it such a success is that they weren’t a team that was massively dysfunctional, but they had some places where they needed help. And in particular, I was able to show that things like the siloization of testing and development was causing a lot of problems. The fact that there was a set of teams working on a backend system and a set of teams working on a front end system was a problem. I was able to show that the lack of clear goals being set by leadership was creating issues. And all of those turned into a series of things that we work through. And these turn into things like getting the team onto single sprint goals getting the team onto using user stories instead of large requirement documents. Lots of things that many coaches would potentially do anyway. But I think probably more rapidly than I would’ve gotten to them if I’d have not had this structure. if nothing else, I can tell you that when I left that organization, there were a lot of people that came to tell me that they felt I was the most effective scrum master they’d ever had.

That I’d really helped and made an impact that’s anecdotal, but it really made me feel like it had an impact. And that’s how you have to measure it, this is why it all ties back to the symptoms is you’re only as good as the problems that you’ve helped solve and the perceptions that people have of how that have helped them. 

Murray: All right. That’s good. Shane, should we go to summaries? 

Shane: Yes, we should. I like the way that you opened, which was, what’s the most effective thing I can help with? Which is a perfect coaching stance, we’re there to help the teams. Become better at what they do, and then eventually they should be able to do it by themselves, and we get the hell out of DODGE. 

And then we talked about this idea that often coaches will go in with the answers, and just start to get some runs on the board. But actually, one of the first steps in what you talk about is this idea of getting the idea of lay of the land. I had the same problem in the beginning of my coaching career was I thought I knew what the answers were. I’d seen other teams do it. I’d drop in, I’d go, Oh, you need to do this. And I’d never stop and actually just look and watch for a while and understand and one of the things you opened with was this idea about testing if anything has a positive outcome.

I love the fact that you believe coaches should have been on the field Murray and I agree with that as well. But you also brought through that other thing that we agree with, which is not all players can become coaches. 

And you actually used a bit of different language, which I liked, which is effectively to go from an expert to a coach, you have to understand that you’re changing stance. And if you aren’t able or willing to change stance, then don’t go coaching, just stay being an expert. It’s okay to be an expert in your career for your whole life. You don’t have to become a coach. You don’t have to become a leader. You can just keep doing great work as an expert. That’s OK. 

So then we went through forming the funnel, . We’re observing, we’re spending some time to look, understand, see what’s happening. And then we’re getting an idea of where things are, things and how they can be connected. And then we look at dysfunctions, which are driven by symptoms, but we focus on the dysfunction, not the symptoms.

So for me, we focus on the behavior or the anti patterns that we see so not the problem itself, but the behavior that’s causing that problem. And then we say, okay, if we actually solve that, what’s the benefit of the outcome? 

If we applied a pattern that fixed the anti pattern, what would we see? And is it worth it? And if it is, then we do a bet. You used hypothesis. I find I can’t actually say that word very often. So now I use the word bet. So we have a bet, if we apply this pattern then we should see this benefit or outcome.

And then that leads us on to the last bit, which is proving the bet was successful, because we already said, if we apply this bet we think this is going to happen. Did it happen or did it not? That’s a nice series of steps. 

And then I liked the thing you brought in the end there, which is effectively we’re getting a lineage map as well, so people go I don’t think that’s a problem. And you go here’s six symptoms that are happening, and they’re facts, we know that, we can see that, we can point to it, that’s happening, and we can infer the pattern is going to solve it, or the anti pattern is a problem.

But the symptoms themselves are factual, so we can see that, the rest of it is a discussion about prioritization. I love the idea of use of cards, going to use that one. I think about it and I never really understood why everybody’s cards and now I get it. 

So that’s a great pattern.

For me, you’ve given me something that I can actually apply now, you’ve described a set of things, that I could actually go and use today. Thank you. Really enjoyed this one. Murray, what do you got?

Murray: Yeah. I’ve actually done a lot of this sort of stuff just naturally. I think like that anyway, and it’s got? me into trouble from time to time because I’ve pointed out dysfunctions in organizations and managers don’t want to hear it because they’re afraid that it’s going to make them look bad. Organizations are just full of dysfunctions everywhere. Can be quite difficult to present that to managers who haven’t really been involved in the work. 

I think the map is, actually a really good way of structuring and presenting it. I can see that I could have used that in my last agile coaching gig to more clearly articulate what I and all the people around me were seeing and the hypothesis we thought. So that would have been really helpful. And it was also very helpful to be able to constantly tie everything back to the outcomes that You want to achieve because managers will say, executives will say here’s the problem is this, and then they’ll make their own assumptions, which are you’re all incompetent and lazy or something. so you can have a map which ties it all together in a way which is much easier to explain. You identify symptoms, you’ve come up with dysfunctions to identify the underlining purpose or goal, then a solution, and then a measure, and we’re going to treat those all as hypotheses. I think that would help me a lot in just clarifying. What I’ve been doing with people. So it’s really good for that. I think the problem we’ve still got is a political one where executives and senior managers don’t want to hear it. It’s not to do with whether you can map the dysfunction. It’s to do with whether, they perceive it as being threatening their imperial aims. I think at least it helps you take some of the emotion out of it. You can maybe have more success with the more political people in management by, showing this in a map that is not emotional. 

It’s based on a group of people working together to come up with a map and which really ties together very logically. So maybe that would be more successful. I hope it would. I think it probably would. Yeah. Good way to clarify your thinking. And I like visual maps things and you might always find that helpful. Anything you want to add before we go to your links, Michael?

Mike: I think the only thing that we haven’t really talked about that I just think it’s always worth reminding people is this is a great way as well to come up with a consistent way to tell a story, either about what you’re going to do or about what you have done. And for scrum masters in particular, I think they often feel like it’s hard to demonstrate their value or to show the impact that they’ve had, because they don’t wanna take credit for the great work that the teams do in solving problems. And so it’s nice to have a story that you can tell about Something that was identified, an action that you took, and an outcome that you achieved because then 360 4 days out the year when you don’t care about taking credit for anyone else’s efforts, it doesn’t matter. But when it comes time to renew your contract or negotiate for your end of year pay rise, it’s nice to have that story to tell and to have some data to back it up.

Murray: So now you’re offering courses, and you’re writing. So where can people find out about all of this?

Mike: So at the moment, the best thing to do is to just find me and follow me on LinkedIn. I’m still trying to work on things like getting a proper website together that looks reasonable. I’m offering workshops that I am trying to do one per month at the moment. In January, I have one happening in person in Manchester. Yeah, I think at the moment, I’m just trying to put as much material out there as possible. So LinkedIn is just the easiest way for me to share stuff. As this becomes a little bit more formalized, I hope that I’ll be able to start doing things like online courses so that you can do it without needing to come to a class and, the book so that if you’re, the person that prefers to just read, you can get it that way. Most importantly, reach out to me, if you want to put this into practice and you’re struggling and you don’t know how to get started. I got into this cause I want to help people get better at being coaches and scrum masters. So if I can help you, just let me know.

Murray: Great. Thanks for coming on.

Mike: Thanks for having me.