Mapping Challenges

How do we approach conversations or engagements with clients, and begin to understand what is happening within an organization? How do we help clients understand where they are now, and what they need to focus on with a holistic view. And most importantly, how do we map and shift a company focus to outcomes?

This Podcast is hosted by Peter Maddison from Xodiac and Dave Sharrock from IncrementOne.

Resources mentioned in the episode:
You can find out more about Flow Engineering on the Xodiac website:
https://xodiac.ca/services/flow-engineering

And at our partner, Visible's, website:
https://thinking.visible.is/post/flow-engineering---a-kickstart-workflow-5ff61f303609424e1f2fba63

Agendashift: Outcome‑oriented change and Continuous  https://www.amazon.com/-/es/Mike-Burrows/dp/1787197263

We love to hear feedback! If you have questions, would like to propose a topic, or even join us for a conversation, contact us here: feedback@definitelymaybeagile.com

Transcript

Peter [00:07]: 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 Dave, how are you today?

Dave [00:20]: Great! How are you doing?

Peter [00:21]: Wonderful. It's a beautiful day here in Toronto and I'm having a lot of fun.

Dave [00:23]: I'm trying to get the same feeling. It's minus one here in Vancouver, so that's the closest we get to a true Toronto winter.

Peter [00:31]: Yes, it's minus one here too. Different sides of the country.

Dave [00:38]: So we talked a little bit about trying to understand how you and I approach our conversations and engagements with our clients. Maybe we can start by just understanding a little bit about what your approach is when you're dealing with a new challenge that you need to learn about?

Peter [01:07]: Right, and I think this was spurred by an email I sent you with a diagram of something I've been working on with one of our partners around this idea of flow engineering and the maps we use there.

So one of the things we first look at when we go into an organization is—how do we help them understand where they are today? And identify where they need to focus to be able to go next? We want to get them to start thinking differently about the way they're executing today and how they work together. Really take a step back and look at the entire system more holistically.

Dave [01:52]: So Peter, is that something that clients come to you and say "we need to understand the system and what's going on"? Or is it more like they have a very specific tactical problem or product they're trying to get out the door, and you pull it back to look at the system?

Peter [02:09]: It's more of the latter. We have, for example, a client who came to us fairly recently and said "there's a whole bunch of problems and I'd like you to help us with all of them. Where would you like us to start?" Because there were a lot of different things we could potentially focus on.

Examples would be something like "hey, I've just started on a cloud migration and I need to organize my teams around that. I'm worried that even as I introduce these capabilities, the organization isn't going to adopt them. Or I'm going to end up spending a whole ton of money and I don't know whether we're focusing on the right thing."

Another aspect in that particular case was "how do I ensure continued governance as we start to adopt cloud? So we don't end up exposing client data or causing problems, and put the right processes and practices and mindsets in place to help us through that transition?"

Dave [03:09]: So already, as you're talking about that, I'm hearing you go into a lot of tactical considerations. How do you determine where to start working? What's that process?

Peter [03:22]: For us, the process is very much about that first map. It's like—how do you get them to start taking a step back and think about outcomes? Start to think about what are the actual outcomes you're looking to achieve here, so we can build out your roadmaps based on that.

We want to build out a map of where you want to go. Where are your biggest problems? What sort of things should you be focusing on? But taking it back and looking at it from the point of view of—if we take the solutions out of the equation, what are the outcomes you're looking to achieve?

Dave [03:59]: So it's almost... I'm just thinking to paraphrase that—rather than diving into processes and people and solutions and so on, it's really pulling that back a little bit at the beginning, just to understand what the outcomes are.

Now, when you're talking about outcomes, is that in terms of cost-benefit realization or increased revenue? Are you talking about an outcome where I get a particular system into production? I mean, outcomes themselves are very broad. How do you help people get to the right level, and what is the right level from your perspective?

Peter [04:40]: So we go through the first one of those maps—the four maps in that diagram I sent you, which of course all the listeners can't see. But the first one is around outcome mapping.

But even before that, we engage with them to start getting them thinking differently—asking "well, what would the world look like if it could look different than it does today?" Like, where are you trying to get to? Starting to get them to think a little differently about how to approach the problems in front of them.

Peter [05:10]: And then we move from there into running outcome mapping workshops where we help them through the process of saying "what is the outcome you want in four to six months?" and help them articulate that. And then "what's holding you back from getting there?"

Once they've articulated that, we can build the outcomes roadmap from that to see—okay, to get to that outcome, what are the other outcomes you'd need along the way? And now we've got a non-solution based approach. What are we trying to do? What are we trying to achieve?

Dave [05:46]: Yeah, what's the change you're trying to see?

I'm reminded—Simon Orrell is a good friend of mine. He's a certified enterprise coach out of Calgary in Alberta, and Simon's insight that he's given me, something I take away and use in many of these situations, is the simple question of "what do you want more of, what do you want less of?"

What I really like about that is there's no assumption of where people are coming in. I'm not saying "what do you want more revenue of" or "less cost of." That whole perspective is brought to the table by the people we're dealing with. And immediately, we can see what they care about, what they're thinking about.

And of course, as we deal with more senior leaders, they tend to have a much broader strategic focus as to what that "what do I want more of, what do I want less of" is. I think that ties very nicely into that whole idea of outcome mapping—how do you consolidate that, put it on paper, and actually help people direct their energies in the right way to achieve what's really needed.

Dave [07:10]: So I think that's a great answer. Now, that map that you end up getting out of the outcome mapping—how permanent is it? Is it something that should be fixed onto the walls and used over a year or two years? What's the validity of that map that you're generating?

Peter [07:10]: So there's this cadence... we constantly want to be going back and revising and ensuring—are those still the outcomes we want?

And so there's this idea—and I know you and I have touched on and talked about it—there's this idea of the mapping process itself being more important than the map. The outcome map that you get has value. It can act as a guide, it can help make sure you're going in the right direction. It can act as signposts as to "which way should I be going, what should I probably focus on next?"

Peter [07:47]: But it's the actual process of bringing people together to create it that creates a lot of that value. So being able to iterate it and not say "hey look, I've created my outcome map, I'm going to put this on the wall and now everybody's going to do this for the next two years" without coming back and reconciling—well, are those still the outcomes that I want?

Because the environment is going to change as you start to move forward. As we move into the more technical parts of the process and we start to dig into "what more tactical changes do we need to make? What experiments do we need to run? What ways of looking at the environment do we need to have to be able to look at the other parts of what the organization needs to achieve those outcomes?"—we don't want to be locked in to potentially going in the wrong direction.

Dave [08:37]: I always come back to this—one of my favorite topics. I have many, but one of my favorite topics is the idea that change is... now we're in a complex world. More and more relevantly, we see this all the time.

One of the real outcomes of that is that we can't have a plan that's stable and static for multiple years. I think the way we see that change is—in the past we would have cascaded down the strategic objectives, and so the necessity to be able to modify those strategic objectives in sort of near real-time, or as a result of new information and changes coming to the people who are trying to execute on that, was not really necessary because it was a static objective over a couple of years.

Dave [09:20]: And I think nowadays that need of having people who can think through the process and modify outcomes—in the outcome mapping example that we're talking about now—is important because it should always be continually challenged. We can't expect our senior leaders to be continually challenging it. It's something that we want everybody to be able to rethink.

It's so different when you get into an organization where everybody is continually rethinking what's there.

Peter [10:07]: Yeah, I agree. So how do you approach this in your practice?

Dave [10:09]: Yeah, I think there's a couple of things. I'm going to talk about one and then maybe we'll touch on one of the other ones.

So we've just come out of a 2021 strategic planning exercise with one of our clients. Just talking about what we've just discussed, the intention was to come out with a roadmap for 2021, some idea of what the initiatives are going forward. But the roadmap itself—in times past may have been a committed roadmap that had to be signed. We certainly had experiences of this, I'm sure you've done the same, where people are signing some paper document at the end to say "we will definitely do this in 2021."

Dave [10:56]: What I really appreciated about what we've just done is, number one, it wasn't a commitment. It was "let's get everything on the table and look at what that map tells us." And the key finding that came out of it—and this is very true, I think, in many organizations—is the amount of work that was needed, the demand, was way in excess of the supply, the amount of work that could be delivered with the teams.

So one of those key takeaways is—is it real? Can we validate that and make sure that gap is real? And if that gap is real, we're either going to have to invest to increase supply, or we're going to have to prioritize and winnow out some of those things that can't be completed.

And so that's really that touching on the map as not being a fixed goal, but more a map of the current situation that will modify and change as we learn more.

Dave [11:48]: The second bit was—this was something where we were able to bring both business and the technology partners together, number one. So we had both sides working together. And then, secondly, we didn't just have senior executives, but we had product owners and we had team leads and key individuals who could speak for the broader organization—all going through that exercise.

So the mapping exercise was something that they were involved with, so they can continue to modify that and adjust as they go forward, because they understood what was involved, what the conversations were, and so on. I mean, I think we've got to see what happens—it's early in 2021—but it was one of those great experiences which I really think is that mix of "the map is there, but it's not the key outcome. The key outcome is actually the mapping exercise."

Peter [12:42]: Yeah, and there's Mike Burrows of the Agenda Shift fame. One of the things that he says he likes to do in those exercises is always have three levels of management, and I think that's kind of what you're describing there.

Because it's so powerful to be able to have those different perspectives. As broad as the executive's view might be—and the information they have about the environment that's around them that people lower down might not have—but the people lower down have a much better touch to "well, what are we actually capable of doing? Where are our gaps? Where are the other risks in the organization that we're going to need to tackle and ensure that we overcome?"

So it makes it such a richer and more valuable conversation if you can bring those different layers together. And it isn't just a strategy layer at the top of the organization that's trying to make all the decisions without any real visibility into what the rest of the organization needs to succeed.

Dave [13:36]: No, absolutely. I think that's great.

Now I'm just looking at the time here and just thinking about some of the pieces that we're trying to get to—the outcome mapping, that beginning piece. I think it's a hugely important discussion to understand why an organization or a department or a division is making the changes that they're making or attempting to make.

But how do you tie those outcomes to the organization itself? And, in particular, of course, people want to know what they need to do. What's the next step? So what are your next steps in that process? We've got some outcomes, we've kind of agreed on that with an organization, with the sponsors. How do you tie that first to the organization itself and reality in the organization, and then how do you define what the next steps might be?

Peter [14:31]: So we came up with a process to do this—a set of generative maps. Once we have the outcomes, we start to understand what the organizational needs are in the immediate term. We can use that as input into the next stages.

So the four maps that I mentioned earlier in a process we've called "flow engineering"—we called them outcome mapping, value stream mapping, dependency mapping, and capability mapping. The concepts here are that once we have that broader, strategic, generative concept that we're looking at across the organization, we can use that to inform "where are the value streams? How do we want to look at our value streams?" And start to look for what are the ways we can start to optimize flow, look for where are the constraints, come up with the tactical, immediate things we need to focus on that immediately adds value back into organizations.

Peter [15:30]: Then we move on to look at dependencies—what's external to those value streams that's influencing them? So we can look at... there may be regulatory controls or other pieces which are not caught in the value stream itself that we can then ensure that these concerns, these external concerns, are being taken care of.

And then we look at capability mapping, which is very similar to what you were describing—that high-level strategy of looking at "what are... now that we understand all of these pieces that we want to do and where we're going to focus, what things we're going to work on—do we have what we need to be able to get there? Where are our gaps? Do we need additional people or systems or skills? What is it that we need in order to actually make this happen?"

Peter [15:58]: And then from that, we can take all of that information and we can start to prioritize it and create what we call a "flow roadmap," which, again, it's the exercise of going through the process of creating that that adds the value and understanding.

And it's there that we hear from our clients things like "I never saw the whole system end-to-end before. I never got to see how all of these moving pieces fit together," and be able to take that step back to be able to look at "this is how we're going to get to those outcomes. These are the places we should focus first."

Dave [16:55]: Can I just pick up on that one comment you mentioned about "I've never seen the whole system before"? We all know there are systems which do three things and you can map that system with four boxes on a sheet of paper, and then there are systems that have hundreds and hundreds of different aspects to it.

What granularity are you looking at getting? And maybe part of that is to do with how much time you spend to be able to get that view of the system?

Peter [17:27]: So we look at it, when we're doing those later maps, typically at a couple of different levels. There's the strategic level or the portfolio level, where we're coming in and we're mapping like "what are the different initiatives? How does that work? How does the ideation process work?" And through that we identify "okay, here's an area we should focus on."

And then we start to dig deeper. So you have this idea of value streams being nested. Here's my higher level value streams, and now we're digging into the lower level value streams to identify exactly where to focus in those. So that's kind of how we picture it and start to dig into the organization. That's how that mapping process works. We look to identify for the organization where would the most valuable places to focus be.

Dave [18:08]: It's interesting you're saying that, because value streams—and I'm sure we're going to get going on some of these at some point, because it's something that we're really struggling with, that concept. I think the value stream, made famous by value stream mapping in lean, is a very one-dimensional view of a three-dimensional thing, or a two-dimensional view of a three-dimensional piece.

And I think that's something that is always a struggle. I was in a conversation yesterday with Aaron Saunders—a certified scrum trainer south of Denver—and we were just talking about those value streams at scale. When we're in a smaller organization, I can imagine, like you're saying, those nested value streams. When you get into larger organizations, that nesting... it's no longer the Russian dolls model. At some point it's a lot more complicated than that.

Dave [18:50]: And Aaron used a great phrase of "networks of value streams," and that immediately makes me think of things like the London Tube map or any number of different maps that has more than three trains in it for a travel system—when you've got many different value streams doing many different things that intersect.

So how does that come out? When you're dealing with the value stream, what sort of scope are you looking at? Or how do you deal with those complex product suites and services suites which don't necessarily nest in the way you're describing?

Peter [19:38]: So there's the concept of—what are we looking for is the outcome? See what I did there?

If we're looking at the value stream, we don't necessarily need to capture every single part of it in excruciating detail. We need to capture enough to be able to identify where we need to look next in the process and help guide the decisions that are looking to be made.

So we're looking for just enough information. This is where we get into this kind of explore and exploit—like when do you leap and look into the next piece and understanding how much information is enough? So now we start to bring in some other concepts that allow us to decide as we're moving through this—"okay, this is how we're understanding... do I now have enough information to move to the next piece and where should I go?" And that's the knowledge and experience we're bringing to it.

Dave [20:35]: If I can just rephrase that and put that back, because as you're mentioning that, I'm reminded of a conversation I was having about that maturity of, let's say, a consultant—of somebody that you're working with, that you trust as an expert to come in.

Early on in that journey, we often want to show how much we know by putting as much on the table as possible. And I think—and this is something that I really respect about yourself and Kino and the team that you have around you—that maturity... as you mature, your goal is not to put as much on the table as possible, but is actually to stay quiet and identify the one thing or the two things which are pertinent right now that need addressing. Get those solved and then come back to reassess and look for the next one or two things.

Dave [21:26]: And I think I just wanted to kind of bring us slowly to a close, because I feel that we've had a long conversation about a number of things. But one of the things that I'm hearing from our conversation here, and I think is really a key takeaway, is the value of this mapping and maps exercise.

The value of the mapping—we've talked about as being that getting everybody able to rethink and revisit that map over time. The value of the map is that identification of those one or two things which are relevant right now and that need attention, knowing that the moment you make those changes, that whole map is going to shift and adjust and so we need to revisit that to find what the next items are.

Would you agree?

Peter [22:15]: Yeah, I think that's a good way of summarizing it, and I think that it's directly relevant to a lot of the principles of Lean, of course, and things like theory of constraints. We want to find where's the one bottleneck, where we should spend our time and our effort to ensure that we're focusing in the right place. Effort anywhere else in the system isn't going to produce improvement.

So yeah, I think that sums it up nicely. Is there anything else you'd like to add as we wrap up here today?

Dave [22:50]: Let me maybe add that one context of the map being "how do you identify the bottleneck?" As you mentioned that theory of constraints—knowing that the moment that constraint shift changes, the map readjusts itself and so it needs to be remapped so that the next constraint can be identified.

And I think that remembering that understanding—the map is a snapshot that is going to need to be reformed—helps us really use those tools in the right way.

Peter [23:23]: Yeah, I think that's a great way of summing it up. So thank you, Dave. Great conversation, really enjoyed it. Until next time!

Dave [23:30]: Enjoyed it, Peter. Until next time.

Peter [23:33]: 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.