Impact Mapping in Practice

Impact Mapping in Practice

‍

‍[00:00:03.410] - Speaker 2

There is always a gap. And whenever Tony or I, whenever we take a look at our customers, there's always a gap. Sometimes they say it's a gap between business and technology or business 90 if you want to be specific. Sometimes between plan and reality. Sometimes between expectations, goals and delivery. Eventually impact mapping is a wonderful and in my private opinion, underrated technique that help us bridge the gap. Help us bridge the gap. If you, for instance, are interested in better visibility of the purpose of your delivery in such a way that everybody could understand it, impact mapping would be a good tool of choice. And if you believe with the majority of plans, for instance, they are based on assumptions, impact mapping will help you reveal these assumptions. So the plan for today is to talk more about the impact mapping and I'm pretty sure some of you have heard about the technique. Therefore we divide our webinar into two parts. During the first part, in brief, in nutshell, we will talk about impact mapping in practice. What is the construction of the map? How does it look like? Then, after an example, we'll take a look at a few practical hints and tips, how to make it better in your context whenever you want to use it.

‍

[00:01:34.430] - Speaker 2

So that's the first part. The second part a great surprise, I guess. And a gift from a gift from Tony is a case study how Tony used impact mapping together with other techniques in a completely different place. Not product management, it's how to use impact mapping and other tools to transform a company, a department. In that case, I hope you will enjoy it. Let's carry on. So, an impact map. So an impact map. In brief, each impact map consists of four layers for areas and it's very important to understand them before we go into the details. The very first one is goal. A goal, a single goal. If you have multiple goals as a product owner, for instance, if your strategy has multiple business goals, fine. There's one impact map per goal. That's very important. One goal, one map yielding it a goal of actors. And if you are used to product owners language, typically we talk about users, customers. Impact mapping comes from a little bit different basket of tools. Actors are for instance, users of your product, customers of your product, stakeholders, but also people who are not yet affected by your service, not yet affected by your product.

‍

[00:03:01.420] - Speaker 2

So, for instance, a person that you would like to buy your product, currently the person is not your customer, any actor of the system or the product. In brief, impact, it's an interesting concept of looking at value of your product or a service and from the perspective of these actors, users and customers, typically, if goal is more like a business goal, impact is the outcome to the actors. It's literally change of their behaviour because hey, whenever we deliver a product, or even a feature of a product, tiny update or upgrade to our product, we want the feature to be used by users. We want customers to buy and use it. If so, we are changing their behaviour. They were doing something, now they will be doing it faster or cheaper or better that we will see. At the end of the map, we have a series of deliverables. If you deliver these things, these features, for instance, the impacts will be there will be bloodshed. Of course, the map is not a set for big blocks. Typically a map, an impact map, looks like that. So if one goal, it's linked to multiple actors. Each actor is named.

‍

[00:04:25.430] - Speaker 2

It could be a user, it could be a person. If you're using personas, we will see an example in a moment. Actors are linked to impact, so what will change in the behaviour? Loops are possible here. One impact may affect multiple actors.

‍

[00:04:40.950] - Speaker 1

Why not?

‍

How to Construct Impacts?

‍

[00:04:41.710] - Speaker 2

And of course, a set of deliverables below. Versatile, I could tell, to tell about it. How to construct impacts. What is the difference between an impact and deliverable? For instance, if we go into details, but let's wait for it for a moment, I think we need a proper example. Hint number one before we move to the section of hints is that impact maps tend to be big, tend to be really huge, and no matter if you're using vertical map or horizontal one, you need the proper tool. Slight is not enough. Therefore, we'll be using, from time to time, a mural board for this presentation. So let's take a look how it could be in Practise. Tony, over to you.

‍

[00:05:30.330] - Speaker 1

Thanks, Pawel. So, as Pawel said, impact mapping is a highly under recognised technique. Personally, it's a favourite of mine, so whenever the opportunity comes to use it, I'm always excited in getting into it. But as he just mentioned, you need a lot of space. So if you're doing this physically, you need a big white wall or big piece of brown paper. Or maybe you need a digital tool which has got quite a wide expanse, which is why we've had a jump out of a presentation. So I'm just going to take you through an impact map. If we were, for example, impact mapping today. So if the goal of today was to create an impact as a result of you watching this webinar, we might be looking to meet a goal. In other words, reach a goal whereby you, as the viewer, the audience, can demonstrate how you might apply impact mapping in your context. And I'm sure there are more than just these three actors, or three personas, whatever you want to think of them as. But the three I came up with, just briefly, were someone who's brand new. Never heard of impact mapping before.

‍

[00:06:35.700] - Speaker 1

All of this, I'm learning it for the first time. It's new news to me might have someone who's heard of impact mapping, but they've never had the chance to apply it. So they know the theory, never got to actually practise. And then finally we've got someone who's maybe practising, but they're looking to up their game in impact mapping to maybe trying a new space, a new place. So the case study is really where I'm going to help you out later, so please hold by if you're that person in that last actor's place. So these three actors, these three different personas, they are behaving or you as the viewer are behaving in a certain way today. And as a result of this webinar, we're looking to make a change for that behaviour, an impact. So the next area of the impact map is saying, well, how will these actors be behaving if we are achieving the stated goal? So if we were achieving that goal for the completely new impact mapper, they might be going straight from this call and investigating where can they learn some more? Or they might be implementing or actually trying their first impact map.

‍

[00:07:43.390] - Speaker 1

If we move to the person who's heard of it but never applied it before, they also the impact might be they go away and they learn something more beyond what they already knew. Or they might be taking their impact map to the next level based on what they're hearing this final actor learning about. So, as you can see, we start to state what is the way we expect the actor to be behaving when we're reaching the goal that stated at the start. Because after all, if people don't alter the way that they behave, nothing really happens in the world. So, impact mapping, this is why I like it so much, because it's very people centric. It puts technology, process all that to the back. It says think about the people first. And this is exactly what happens on the last stage of the impact map. The deliverable is really what would be necessary in order for these behavioural changes, these impacts, to be taking place. So when someone is investigating War, we might invite them to look at the impact mapping website. So Impactmapping.org, Goiku Anzek who came up with the whole process of impact mapping his site, they might go there to learn more or they might be actually structuring their own impact map based on what they've just seen on the screen today.

‍

[00:08:59.320] - Speaker 1

So that's a deliverable. They might take something simple, you might go and take a goal, you've got a life goal or a work goal and you might start impact mapping it out using yourself as the actor. So we have these deliverables of the things that we believe will bring about the behavioural changes that will create an impact in these individuals or actors which will ultimately deliver on this goal. And what I invite you to think about is it's not really the boxes, it's the lines. When Pawel mentioned assumptions. Every single line on this diagram represents an assumption and at the moment, this assumption hasn't been tested. Until you start doing some of these things on the right hand side, you start to test these lines and validate whether they actually work. If they don't, all you do, you go to the next one down because they're all structured in order. So we've got a very simple way of navigating what I describe as people change. But it works for product, it works for services, it works for all sorts of context and we'll get on to that in a minute in the case study, but in the meantime, I'm just going to hand you back to Pawel to take you through a few more.

‍

[00:10:09.010] - Speaker 2

Steps, Tony, while I'm still sharing. Not anymore, but if you can open it, I have a few questions. Questions about your experience. The very first one would be, when do you think is the best moment to use the impact map? Is it at the beginning of the project? Only.

‍

[00:10:31.210] - Speaker 1

Brilliant question. It doesn't have to be at the beginning. I find it's better at the beginning. Trying to invite people to do it when you're partway through can be seen as why we have to stop doing the real work whilst we do this thing. So I find people are a little bit more resistant if you do it partway through a project. However, that said, if you sense that people are delivering things blindly and they don't really understand why they're delivering them, this is an excellent way to connect them with the purpose of why they're doing the deliveries. So one of the things I come across a lot is teams who are diligently delivering things because they've been told by someone they have no idea why that's important. This makes that connection between why is it important and what I'm doing to contribute towards that. So that's when I would bring it in in flight, but I would ideally start it right at the beginning and go back to this again and again and again. Don't just do it once, keep reviewing it, working out which of the assumptions have we tested? So I see it as a living thing.

‍

[00:11:35.070] - Speaker 1

Right.

‍

[00:11:35.730] - Speaker 2

I have a similar experience very often at training sessions whenever I bring up impact mapping, and I tend to bring it up pretty often, people complain, Puffer, this is fine for greenfield situation. And typically in business we have not so many greenfield situations. It's a non-stop continuous product or service delivery, I realised in my Practise. But if you use it even in the middle of the project, typically Jira is set up so you have deliverables. Typically you have a business case written, so there is a goal somewhere. I believe the team understands who are the actors. It's a matter of crafting the impacts. And it's so powerful, especially for product owners working with stakeholders to show them, guys, we have a backlog full of Deliverables and half of them have no links. These arrows does not exist. You cannot link them through impacts and actors back to the goal. So why are we doing it?

‍

[00:12:33.060] - Speaker 1

Maybe.

‍

[00:12:36.210] - Speaker 2

Let’s skip it. All right, thank you. Thank you very much. I think we have plenty of hints around that. Go ahead.

‍

[00:12:43.490] - Speaker 1

I had one other thought. You just reminded me something. I wasn't going to bring this up on this call today, actually, but you just reminded me one of the things I got taught very early on this was if you've got a team that uses user stories, for instance, and the user stories look a little bit off, in other words, the benefits, the why aren't particularly strong. The as a the person involved is not very clear. This reads like that. So as a you take the actor. So as a whoever it is I want well, normally it's the Impact. So I want this and why do I want it? Because of the goal. So you've actually got a user story actually done by example built out in front of you and you can just read them off here and you can create your user stories and link them back. So I'd actually forgotten about that. That's another way of connecting into a team. If their user stories seem a little bit disconnected, this is a good way to really reconnect them back to purpose. So, thanks. A reminder.

‍

[00:13:44.470] - Speaker 2

Now you reminded me something. That's another way of doing it. Depending on what is your goal over here, is it more a business goal, so the goal of your team, of a company or a goal that we want to achieve together with the actors? If former very often user story could look like, as an actor I want a deliverable so that I will receive the benefit, which is my impact. So, for instance, as an actor I want not as an actor, as a Netflix user, I want you to deliver payment by PayPal so that it's way easier for me to pay with this way because I always forget my credit card, but I remember my password. Something like that. Something like that. So you can play easily with the technique. And you will all see at the end of our presentation during the case study where else we can use import mapping, completely outside product development. Speaking of hints, let me come back to our presentation a bit more generic. We could talk forever, I guess both Tony and I, you know us already about it, but there are a few highlights, I think, very important ones that come from our Practise.

‍

[00:14:59.090] - Speaker 2

The first one is an interesting surprising link between the Impact Man and user stories format. The proper one. If you have technical stories like other system, I want to connect to system B so that I'm connected Impact Map perhaps help you craft the proper one, really focusing on users or probably speaking as being actors and however there are more first of all, good hint. Good idea is to use the impact map with your stakeholders for prioritisation. I'm not sure if Tony had a similar experience, but quite often I see maybe not, maybe not a big corporation, typically an average sized company or a software hub 100 people and a customer arrives or a company of 1000 people. Not a huge, huge international corporation. And very often CEO or CTO, CFO, somebody in the executive team wants to make decisions about deliverables. You know what? This pattern should be more to the right, I want you to deliver it. Or decisions like I think integration with Twitter is more important than another deliverable. Let's say implementation of new systems for comments. In our system I think executives, with all respect would always have competence to make decisions about design.

‍

[00:16:28.060] - Speaker 2

We have UX designers for it, for instance. On the other hand, I don't want executives to make these very low level decisions. So impact not help actual leverage the discussion to priorities that are business oriented. And I see two places where we can have this conversation. The first one is the business goal or goal in general. I have two or three maps because I have two or three business goals. One goal is a business goal could be increase the market share from 15% to 20% by the end of the year. And another business goal would be to keep the same revenue, the revenue on the same level as we had in 2021. Two business goals. Which is more important? I don't know, but we can have a conscious decision or discussion and then decision amongst stakeholders what is more important? So which map goes first? If map number one goes first, so increase of market share is more important or the deliverables linked to that map will automatically be more important. The priority would go up just one level. Another level I believe is the level of impacts. Indeed, I'm not sure if business wants to have these kind of conversations what is more important to implement this button or that functionality?

‍

[00:17:53.600] - Speaker 2

But on the level of impacts, do I want customers using my product to use it more frequently or I'm keen to bring customers that are not yet using my product at all. I want them to start using my product to different priorities. We can have a conversation which is more important for us to achieve the goal. So that's the first hint. Target the discussion or direct the discussion towards goals and impacts. What do you think, Joey, about this approach?

‍

[00:18:27.970] - Speaker 1

Yeah, I can definitely see that as a powerful way of putting it through. And it's another example of where this applies way beyond just the realms of product development because I think that's the trap people get stuck in is this can only be used in this situation. And when you do that it cuts you off from a huge opportunity like the one you just described.

‍

[00:18:49.930] - Speaker 2

All right, thank you. One other hint that I would say I could bring up from my Practise over here is related directly to Impacts and Deliverables. Very often I see junior product owners who just learned this technique to confuse these two. Impact definitely is behavioural change and it's not a deliverable. Impact should not be a one timer. So my actor will register to the system and deliverable is a registration form. It's literally the same.

‍

[00:19:27.340] - Speaker 1

Right?

‍

[00:19:27.980] - Speaker 2

And if you are confused how to write down the impacts, start with it's a template or a hint, actually, start with a few words, such as an actor will start doing something, or an actor will stop doing something. So the actor will start paying regularly with a credit card or will stop paying with cash. That would be the impact. And I can imagine multiple deliverables supporting it, or an actor will do more or less of something. If you try to start each impact writing an impact from these words, very often you are on the outcome level, not functional level or feature level. Any other hints, Tony, that you would bring up over here?

‍

[00:20:17.350] - Speaker 1

I suppose the only other hint I would come up with is when you're writing the goals in impact maps and anything on the left hand side, always try and write it in the language as if you've already arrived. So very often I see people writing very aspirational wishful hopeful language, but write it as if you're already there. It seems really trivial, but it rewires the brain into imagining itself at that place in time and then the rest of the map is a lot easier to develop. I found if that goal isn't structured in that language, I find teams all over the place trying to do this. So start as if you've already arrived, even if it seems far-fetched, and then work backwards and work out, well, how did we get there, what did we do, what do we think we did? And that's all your assumptions coming out then. So that would be my big tip, is that kind of use of language at the start and give time to get the goals as well. It's not going to come quickly. This is not something people think about very often, so you've got to give them space and time to do it.

‍

[00:21:30.270] - Speaker 2

Speaking of time, how much time do you book? Typically when you start, when you introduce this technique, not as a training, but in real life case with a project.

‍

[00:21:41.390] - Speaker 1

Team, if I was really pushed for time and they said, you can only have a little bit of time, I try and do two half days, which sounds horrific, and I try and do one afternoon first, which really gets the left hand sides of the board done. So spend ages on the gold and then I let them sleep overnight. And then the next day we do a half day morning and that's much more on the right hand side. The right hand side I find comes a lot easier. But if you've got the left hand, the goals and where you're starting really solidly done on that first half day, I find that I can just about do it in two half days. How are you?

‍

[00:22:22.670] - Speaker 2

I have similar impressions. Once or twice I managed to cover it all in one workshop, 4 hours. But it was in the middle of the project where deliverables in the product backlog existed. The business case was written in a pretty nice way. Cooperation within the team and stakeholders between two and stakeholders was awesome. And it was simply a brain dump of what was already there onto the map. 4 hours. But ideally one day would be okay. I tend to scatter your strategy across multiple days. So two or 3 hours today, follow up tomorrow, then another follow up in a week. And I think you will agree with me that it's a living artefact, like all the maps, canvases and other tools that we have in Agile. So the fact that you do it once at the beginning doesn't mean it will be right like that in a half year. It shouldn't actually. That's we can see. All right, moving on. A tiny list for your awareness of what we were talking about, the parties goals. So maps or impacts, that's a tip from Tony and me. Number 1, second one maybe I didn't talk about it directly.

‍

[00:23:45.290] - Speaker 2

Quite often I see people struggling with writing business goals. If you agree that the goal is the business one, they think it's about money. Okay, how much money will we make? It doesn't have to be money. Business goal is any outcome to your business, to your team, to your organisation, depending on what you're doing, where you're implementing the impact map. It might be something about brand awareness, for instance, typical in startups, especially during first couple of even years of your existence, when they are not focusing directly on making money, but increasing brand awareness or a novel business type of business goals. Increasing number of active users or users in general. So it's not just money. Hints to write impacts an actor will start or stop doing something or will do more or less of something. And two versions, only one on the screen, of how you can use it with user stories. As an actor I want deliverable so that I get impact or as an actor I want an impact so that I achieve the goal. The former is when you use a business type of goal. The latter is an example from Tony, where the goal is a general goal, something that we want to achieve as a team.

‍

[00:25:10.130] - Speaker 2

All right, perhaps I should have talked about it and mentioned it earlier. If you have any questions, should there is chat window open? We have a space for Q and A at the very end. But if you already have a question on your mind, just write it down. We'll have time and space to come back to it. Now let's move on. I think after the next parts of presentation of Tony will dramatically change, I hope you will dramatically change the way you look at the link between strategy and delivery, not only in product or service delivery. It's a real case story of Tony's engagement with one of our customers where Impact Map, together with other tools, was used to transform a department, pretty huge department. Before we move there, if you are interested in details of the Impact Map, because there are details we can talk forever about it, feel free to come to our training a master class named simply Impact Mapping. April 29, full day, 8 hours. With me going into details, going into details of actors. Impacts deliverables. Very practical one and fully on mural board. You'll be crafting your own maps.

‍

[00:26:44.360] - Speaker 2

If you're interested, reach out to us or simply scan the QR code that you can see on screen. And that's it. Now, Tony, let's move to the case study. This stage is yours again.

‍

[00:26:58.150] - Speaker 1

Thanks! Okay, so I'm just going to share up. It's a real impact map. It's been genericized. So one of the things I will stress about impact maps, if anyone does them in their organisation, they can't share them because often they've got something in there that's very sensitive. So this is exactly the same. So I've had to make it into a generic example. But it is a real life example. I imagine if you're on the call and you work in an organisation, you have a department known as People or HR. So this was an exercise that was conducted with an HR function which was global. So it was across multiple time zones. Many, many people, not a product in sight, not a bit of technology or it other than they had the systems they were using. But one of the things that was significant about this was they were mapping out themselves as a service, the service provided to the organisation. So this is another example that you can use an inbound map for just about anything. In this case, it was how do we want to be known? So they had a vision and goals.

‍

[00:28:06.020] - Speaker 1

This map took several sessions, several days to get done. As I said, it was done across multiple time zones with about 30 to 40 people contributing at the maximum points. And then we have to asynchronously link everyone back up again. So it was quite a big undertaking. However, this was used throughout the entire Agile transformation the area went through. So what we have on the screen here is quite a big impact map. I will zoom in a little bit, but I'm not going to go through all the details. There are a few extra bits in here which I will point out which aren't part of the impact map as Pawel sort of signposted at the start, there is a very good structure of how you impact map things, but nothing stops you adding other things in and remixing this and remodelling it. The original creator, Goiko Antique, he developed this from something he took from the Training Needs Analysis world and something from the marketing world. He saw two great ideas, he blended them together and he came up with impact maps. So there's nothing to stop you or I coming up with an even better variation of that.

‍

[00:29:17.510] - Speaker 1

And I'm sure he would be delighted to hear something's been devised that improves it even further. However, that said, as Pawel just mentioned, the goals don't have to be to do with money. So in this example I've got here, we've got something around how people perceive this service outside. We've got something about the team themselves. We've got something about the use of self service. It was only this fourth goal and bear in mind these were in order of priority. This one had some element of money involved in it, but it was only subtle. And then finally the inclusion and diversity of the teams. So we've got quite a broad set of five goals there. We also have for these goals, we have measures. We haven't really talked about measures, but every goal on an impact map has an associated measure. Now, I find, and this was true in this example, getting those measures understood out there visible is probably one of the hardest parts. Which is why I say don't rush the goals because often people either don't know what it is they should be measuring to know if that goal has been reached, they don't know how they're going to measure it.

‍

[00:30:33.370] - Speaker 1

And then more than often than not, they have no idea what the current measure is. So what normally comes out the back of this session is right after this, you need to go away and find out what is that measure currently. Because if we don't know what it is today, we've got no idea whether we're moving towards the goal away from it. What we're doing is making the situation better, worse or indifferent. So we have measures which we really do focus time on and that's something you dig into more if you learn about the technique. We've got our actors, which are already here. We've got our impacts we talked about before and we've got our deliverables. But the other area that's highlighted here with the dotted lines around Little Lance is something called hypothesis driven change. Now, this isn't part of impact mapping. This is a technique that I first learned from a chap called Mike Burrows. It comes from the world of hypothesis driven design. But it was his kind of spin on that to do with change management. And what he was saying was if you don't align the beliefs of a group of people.

‍

[00:31:37.950] - Speaker 1

When you're undertaking any big change, you're unlikely to get the outcome that you keep writing about because no matter what you put in the big vision box, if our beliefs are completely misaligned, we're all starting from a different place, we all have a different view of what that vision really looks like. So we're all pulling in different directions. So what I did with this whole area was we did a big exercise where we got their beliefs out on the table in person and the first thing that happened was they were shocked at how different their beliefs were, how much they varied from one another. In some cases they reconciled those beliefs and they made them consistent. In some cases they accepted they were different, but they knew why they were different. But what was important here was they were ensuring that the beliefs were visible of the team, and they knew where they wanted to have shared beliefs, and they knew where it was okay to have different beliefs. And why that was important was it meant they understood why they were doing this, and it meant that their convictions to change were greater. So what we found was by doing this there was a huge amount of engagement and a sense of ownership in the whole Impact Map.

‍

[00:32:49.500] - Speaker 1

It was unexpected, but that's what I found doing this. So we added this in in within the goals as sort of a connection in there. And what I would say is my takeaway was that bonded the sort of the why side of things on the left hand side with the what and the how side so much more because everyone was linking it to what they believe, which is a huge powerful motivator, intrinsic motivator inside us. So we got that going on in this case study as well. And then the final thing I was going to call out in here was if you look very far on the right hand side, we talked a little bit about how this creates stories and if you use user stories that kind of Agile, complementary Practise, you can create user stories by reading the map. But what this team was doing was they were turning the items out of the back of this Impact Map into product backlog items. So they were literally driving a product backlog straight off the back of here. And obviously the highest priority deliverable there was number one in the backlog. The highest priority on the next branch of the map was the next one in there and so on and so forth.

‍

[00:34:00.840] - Speaker 1

So they could actually start to build their backlog. And what we actually did was we ran this Agile transformation using Scrum. So we were actually using Agile to introduce Agile, which is kind of meta, but I find it works really well. Much better than trying to plan everything up front. But we use the impact map as our guides for what do we do next. And if we deliver that first item and we're finding that the transformation is not working as we like, or we're getting feedback from the teams that it's not working, we can alter our track and we can change direction down this impact map and try a different option. Now, why that was important, which came out a lot later, was this team, this area was operating within a very large organisation with very traditional governance, and one of the things they demanded was their change management approach. So they had to share how they were doing change management. And it took me a while to sort of make the dots the connection for them, but I said, well, what you've got here is your change management landscape. This is exactly how you're going to change as an organisation.

‍

[00:35:13.330] - Speaker 1

And these are the guardrails. So they were able to address all the demands and requests for change management through one simple visual like this, which was written in a language that everyone could understand and satisfied the needs of the governance team to the point where then they are going to start using this approach when they start doing change management. Plus, it allowed them to connect what they were doing in the backlog directly to all the things that connect them back to the goal, the why and the vision. And the other final thing I was going to leave you with was, bear in mind, this was global. So as one bunch of people were asleep, another bunch of people were waking up and they were working off the back of this. So this thing was evolving literally daily. You'd come in the next day and something had changed on here, something had been added, something had been amended, and we had a colour scheme so we could see that it changed. But this thing evolved over a 24 hours period. It was living, it lived and it was working whilst we were all asleep, some cases.

‍

[00:36:17.860] - Speaker 1

So I found it was a tremendous benefit to say exactly where we were in terms of their journey into applying Agile in their area. That was all I was going to cover off Pavlov. And if you have any questions, or you can imagine any questions the audience might have, if they've put any in.

‍

[00:36:35.100] - Speaker 2

The chat window, I have plenty of questions, but I guess we don't have time for all of mine. So just a few comments and questions. The very first one, a reminder. The map that Tony is showing right now, it's anonymized and way smaller. I remember the original one. It was longer, way longer, way bigger. Tony, correct me if I'm wrong. Day one situation was that there was a vision only and goals. I'm not sure if all the goals and nothing else, am I right? Yes.

‍

[00:37:10.490] - Speaker 1

As I said, this was several sessions, so initially, well, before this, we had principles, so we shared design principles, how the team were going to the principals are going to guide them. And then we got the vision and the goals down. That was first session. Second session was measures. And then that dogged us all the way through. Hypothesis driven change got added in after the measures because I could see they were struggling. And that's where we got these beliefs out, because I could sense that there was a gap there. So, yeah, if you imagine going from left to right, the map built out that way. And as you point out, if I put the original map up, it would scroll down for several pages. It was very big. It was a lot of items. I've simplified this, so you can just get the general theme. But yeah, much, much taller than this.

‍

[00:38:00.490] - Speaker 2

So transformation backlog was way more than just six boxes. Definitely.

‍

[00:38:06.350] - Speaker 1

If only it was that easy. If only it was easy. No, it was multiple sprints and multiple items within. There much more than two. So, yeah, much larger than this.

‍

[00:38:16.690] - Speaker 2

I think this is a very powerful example showing transparency, how visible it is. Imagine a situation, this map wasn't built and the transformation carried on just with the vision and set of goals. We would lose a lot, a lot of information, a lot of links, especially in case of very global transformation, multiple time zones involved. Tony, I have a very specific question about this hypothesis driven part, but you added on top of that, I can imagine while bringing up the topic of hypothesis revealing hidden hypothesis, some people might have challenged the goals. Was that the case?

‍

[00:39:01.470] - Speaker 1

Yes. And in certain countries it challenged more than others. It was fascinating. It was a lesson for me. One of the areas I was working with was the Middle East. I've never worked with the Middle East before. That was quite a difficult area to do. I don't know why. I never understood why in the end, but it was quite a challenging area to go through. But I stuck with it. What I would say is, by the end of it, they all saw the benefit of having that shared sort of belief, understanding, structure. But you're right, talking about beliefs is not an easy place. So again, don't rush if you use that, don't rush it. Allow people to express themselves, allow them to make the connections. Don't say, oh, your belief is different to yours, because that's the first way to lose your audience. You want to allow them to make those connections or facilitate that observation from someone in the group.

‍

[00:39:57.710] - Speaker 2

And I think that's very important to take away. What you can't see looking at this map or any other impact map is coaching. Plenty of coaching activities. Facilitation of this discussion. The map is a picture showing the end result of that discussion, but actually, a lot of coaching attention or facilitators needed to make it happen. All right, I have nothing to add, at least right now. Maybe tiny question. When I look at the transformation backlog, which is a standalone tool very often, how often did you come back to the impact mark? Because I believe on daily basis during transformation, it was just more quipped backlog, wasn't it?

‍

[00:40:45.230] - Speaker 1

So they had the next eight weeks of content in the backlog and they were always filling up another week. At the end of every week, they were filling up another week. So we were taking from the impact map, the changes to the impact map were happening on their reviews. You're really testing my memory now. So every two weeks in their reviews, they would then review the assumptions and see where the assumptions were being validated. If that was discovered, that's when they would make the changes. But that said, as I mentioned, there were little tweaks going on, measures especially there was lots and lots of work developed over time. The systems area, this third goal, which you'd imagine would be full of measures, that was the hardest. That one took loads of work. There was loads and loads of work in the background. But, yeah, I would say every week there was stuff being populated into the backlog as a week's worth went out at the top. And then every two weeks there was a kind of a cheque in of these lines, these assumptions, and saying, which ones are these invalidated? More on the right hand side, really.

‍

[00:41:58.890] - Speaker 1

But if you imagine crosses in them, which ones crossed out?

‍

[00:42:03.030] - Speaker 2

All right, thank you very much. And I think it's about time to move on to the Q and A part. There's one question already in the chat window. I encourage everybody to start typing your questions right now. If I know more questions after answering this one, we'll move to the final part. Natalie is asking, who should I invite for the impact mapping session as a product owner? Tony, brilliant question.

‍

[00:42:32.220] - Speaker 1

So the guide I was always given was keep it small, keep it to the people you absolutely need there, and make sure they have the authority to make decisions about stuff. So if you're looking for a relatively senior bunch, got a lot of autonomy, and you keep it to the absolute bare minimum. So when I started, I used to always keep it to like five, maybe six people maximum. Once you start using it and you get a little bit more comfortable with the technique and how you do it, you can expand it. I would say the example I just showed you, the case study there, that's fraught with huge amounts of risk, so I wouldn't go into it lightly. And you're going to spend a lot of evenings sorting things out because you've discovered something that involves a big wholesale change. So I would say, definitely, like most things Agile, start small, make sure you've got all the right people with the knowledge in the room. And for me, it was their autonomy to make decisions was really important because you wanted to get stuff done in the sessions, not have to go away and ask permission for everything.

‍

[00:43:38.820] - Speaker 1

I don't know about you, Pawel.

‍

[00:43:40.790] - Speaker 2

I just wonder because I tend to agree. Small group works better when you build such a map on the one side. But on the other side if impact mapping is a technique linking business goals that perspective with engineers deliverables with the solution part. I can imagine already a dozen of people, the entire team, my product owner and a bunch of stakeholders. It's getting crowded. Would you recommend, for instance, having it independently, one part with stakeholders, another part with designers and the delivery team? Does it make sense?

‍

[00:44:23.910] - Speaker 1

I don't know. When I think about it, I think, well, many things. I meet the very far left hand side, the goals, and that they're often struggling to know what they are because my experience has been they've not been open or exposed to that. So there's one side of it it could be useful. They're in the very early part of impact mapping, but they would be there in the capacity of understanding and learning the other side of it. I would see if you started small with those people who really understand the vision, the goals, measures, building that first bit out and then the second session, you're bringing more people in and as you suggest, it should be something that's written in a language everyone can understand. So it might be that you flip the model, you get those senior people to teach it back to the team, play it back to the team.

‍

[00:45:16.450] - Speaker 2

That would also my point of view, I think I would start low and bring more and more people. I think the proper answer, like always in consulting, to the question is it depends mainly are you starting it's a greenfield situation or its ongoing project and you want to discover it? But there's one more aspect over here. What's the purpose of impact mapping session? Is it to create it or update it or maybe to share it? And here I would see way more people, way more people involved into the conversation. All right, I'm taking a look at the chat window, no other questions. I'm going to give you a final 1 minute to write once if there are any, while you are thinking of your question, because that's nearly, I guess, the last opportunity to do that one more slide from our site. I talked about the master class input mapping on April 29, but of course there's one more, yet another webinar and Agile encounter very soon. Somebody's typing. I questioned the chat window, so I will not reveal what's the topic of the final of the next webinar. Let's see if we have a question.

‍

[00:46:43.490] - Speaker 2

Here it goes. Would you combine OKRs and impact mapping? I can jump on it instantly. Yes, I would not always there has to be a need, but especially.

‍

[00:47:00.790] - Speaker 1

If.

‍

[00:47:01.130] - Speaker 2

This is something big, like the transformation part that Tony mentioned, and setting proper goal, business goal, or even proper impacts or measures key results in the language of OKR to my goals, I wouldn't mind using OKR. Tony, have you ever tried?

‍

[00:47:27.550] - Speaker 1

I don't think I've ever explicitly called it that, but as I'm looking at the questionnaire thank you, Poppy. I can see how your objectives and your goals, they're very aligned. I can see how you can use measures to start to find in key results. So the structure of the two are very complementary. So there's no reason why you couldn't put the two together. But I've never explicitly gone, we're doing OKRs with this. I think it's just emerged when I've done it.

‍

[00:47:58.010] - Speaker 2

I think it's also a matter of what you struggle with. OKR itself is a fabulous goal setting system. First of all, helping you, helping team craft the goal, both the qualitative one where the destination and measures what you want to really measure. How will you measure the fact that you achieved the general objective? It's also about getting alignment with the organisation. If you struggle with that, I would directly move to OKR. Impact mapping is more about linking these goals with deliverables, but also with users. If that's the need, I would approach it over there. If you want to both needs. Combining OKR and impact mapping seems to be tempting, I would think I would take a look at my team first and Cheque. Maybe it's too much for them. I can imagine a company, a customer of mine, that have never, ever tried Agile. Starting with impact mapping and OKR together might be overwhelming for some, not for all, for some people. In other cases, why not? So we need to take these parts into consideration. However, I can't see any showstopper over here. No, you must not combine these two because it's not relevant.

‍

[00:49:27.260] - Speaker 2

No, I think that they are pretty much aligned. All right, any other questions? Anybody before we close? Can't see nobody's typing. So let me move to final part of our meeting. Agile encounter four and interesting topic of becoming an Agile coach. So how to become an Agile coach? This time, Scott Oliver, not Tony Richards and myself will be exploring this topic based on based on our own histories, but also based on histories of Agile coaches that we coached or those who we know. So it's not that we will share just two journeys with you, actually multiple ones. Maybe there's something that these stories have in common. Maybe there's no partner here because everybody is different. If you're interested in this topic, you would like to learn more, if you would like to cheque, what's the professional path for Agile coaches? If I'm an Agile coach doesn't mean I can only be better and better coach and that's the end of my career path. Or there's something else behind that. Please come on. May 11. And again, if you scan the QR code, you'll be moved to registration page. If you're not fast enough, no worries.

‍

[00:51:01.580] - Speaker 2

You will be notified with an email as well. Tony at the end. Anything to add?

‍

[00:51:08.330] - Speaker 1

I can't think of anything else to add other than and thanks for those who've watched the webinar today. I hope it's been useful for you and I'm really keen to know if we achieved our impact, but we'll never know because we can't hear from you. But if we have that's wonderful news.

‍

[00:51:25.130] - Speaker 2

Don’t hesitate to write a few words about impact on LinkedIn or our social media where you will see where you will see the presentation. Thank you very much, we believe it was useful and see you on May 11. Take care. Bye bye.

‍

[00:51:44.490] - Speaker 1

Thanks, Pawel. Bye.