Karl Scotland

Thanks everybody, thanks for having me. I should probably explain before I start, I've been suffering from a quite bad cold for the last week, so my throat is a little bit croaky this morning and I may need to pause for water regularly. And I'll just set my visual indicator.
So who knows the well-known business consultant, Dean Karnasas?
Who's heard of him? We have one hand in the air. Nobody else heard of him?
Okay, trick question, he's not a business consultant. He's an ultra marathon runner. So I'm into running, kind of enthusiastic amateur runner. So one of the things I tend to do nowadays is read running magazines, blogs, articles and end up looking at the lessons from running and athletics and applying them to business. And this guy, I saw this quote from him, always encourage people to try new things and experiment to find out what works best for them. And I thought that's the perfect quote to start this talk with because this is what I think we should be doing as organisations. We don't want to be copying other people's best practices, we want to be trying new things and experimenting and finding what works for them. So that quote came from an article by someone called Sam Murphy in Runner's World magazine. And the title of that article was, Don't be a tabby cat trying to emulate a cheetah. And I thought it was a really good metaphor. So a lot of the time, we're trying to copy organizations who are cheaters, and our organizations are mere tabby cats. They're the athletic, they're kind of really elite athletes that go and represent their country, win medals, they're the cheaters. And I'm just a tabby cat. There's no way I'm going to be able to run like a cheetah. I can look at their training plans and I can look at the way they train and can try and copy that, but just copy. Copying the way an elite athlete trains isn't going to turn me into an elite athlete. I don't have the DNA for it. I don't have whatever else is needed. It's not just a case of copying.
So we can take an example. I presume everybody knows who this is. Come on. Mo Farah. Everybody on your feet. Come on. Everybody on your feet. Thank you, Olaf.
Let's do the MoBot. Okay.
Thank you. No reason for doing that, just because I can.
But I have this up here because let's look at one of Mo Farah's training schedules before he won gold at the European, no, the International Athletics recently. So he starts off and he does a mile in just under four minutes and then he does a couple of laps recovery. And then he does 1200 meters in just under three minutes with a couple of laps recovery. 1,000 metres at 2.27. If you're doing the maths in your head, you'll work out that his pace is getting quicker each of these little sessions. 800 meters in just under two minutes, 600 meters in 80 seconds, 400 meters in 50 seconds, 200 meters in 25 seconds, all with two laps recovery. So he's doing shorter distances at faster pace with this recovery time. And by the way, he's doing it at 1300 feet as well.
If I try to copy that, I would not be able to run like Mo Farah.
Just as reference, I did a timed mile run earlier this year, and I did it in about six and a half minutes, and it killed me.
So just following a training plan, just copying what somebody else is going to do isn't going to work. We need to find our own ways of working. So I could look at some of the strategies and some of the reasoning and the rationale behind why Mo Farah does his training this way, and I might be able to copy some of those things. But just doing that on its own isn't going to turn me into an idiot.
And we do that with organisations though, don't we? We look at the way an organisation works, particularly a successful organisation, and we try and copy it. It's a trendy thing to do. But that doesn't work, so we need to find our own operating system. For our own business. Jason Little did a talk recently and he posted the slides and they got tweeted and I thought I want one of those slides because he's kind of saying the same thing. Because Spotify is the latest trendy one, isn't it? Let's install the Spotify model. Jason has some great slides with animation and this is just a screenshot. But it's not going to work.
And instead, this is where I think strategy deployment comes in. We can use strategy deployment as a different and a new way of booting our own operating system. So it's like a little kernel in there. We can install the kernel, and then strategy deployment gives us approaches, gives us methods where we can now design our own operating system. We can run experiments. We can figure out what works for our organizations. For me, that's the secret of the way we're going to scale Agile and scale agility. We don't do it by copying other people and taking best practice from other organizations and just implementing them ourselves. We need to figure out what works for us. So that's what strategy deployment does. And I have this notion of the ambidextrous methodology. This is what strategy deployment will turn you into.
I'm aware that... Not necessarily a native English language, so I'll just make sure people know what ambidextrous means. If you can write with both your left and your right hand, you're ambidextrous. So you can use both your left and right hand equally. And I find that in the software world, the agile world, people are not ambidextrous.
Because they hold on to their opinions, they're right-handed, and they say, estimating is bad, I'm a right-handed person, and estimation is bad, therefore I will never estimate. And then they come up with a left-handed person who says, actually, I'm a left-handed person, and I think estimation's good.
So we need to weigh those things up. What are the pros and cons of estimation?
Balance them together, maybe run some experiments, figure out how do we use estimation, where is estimation going to work for us or not work for us. So rather than just holding on to our ideals, either a right-handed ideal or a left-handed ideal, let's learn to use both our hands. Let's not get hung up by one side of an argument or another side of the argument. Be open-minded about it. So the scissors here, if you kind of look closely, there's a left-handed pair of scissors and a right-handed pair of scissors. We want to be able to pick the right pair of scissors for the right job, left-handed or right-handed.
So strategy deployment is this operating system. I should probably explain a little bit more about what that is. It comes from the Japanese word Hoshinkanri. So like most great ideas, it came from Japan.
And the literal translation is the one at the bottom, direction management. So it's the way lean organizations and the original Japanese organizations said, how do we make the whole organization work together in the same direction? How do we manage the organization? And it's managing for direction rather than managing for implementation or managing for the jobs that people actually do. Let's set a direction and let's help people figure out how do we go in that direction together. The slightly richer, more metaphorical description is the one at the top. Ship in a storm going in the right direction. I really like that one. The idea that your organisation is a ship in stormy waters and we need to get that ship from the stormy waters into safe harbour after the storm. So we need to get everybody on the ship, everybody in the organisation working together, set a clear direction of that's where the harbour is, let's all get the ship out of the storm into the safe harbour.
So it's moving from organisations on this side, on your left, which are kind of, just do this, don't think about it, don't ask any questions. People have friends that work for organisations like that? Yeah, I have friends that work for organisations like that. for organizations like that. And we're trying to move them into this side on the right-hand side. Look at this idea. I've got this idea about something we could do. What do you think about that idea? Let's talk about it. What questions do you have about the idea? So it's a much more collaborative, much more inclusive way of working. And that's moving from governing constraints. So governing constraints is that just do this, follow the rules. Governing constraints are constraints which guide and tell us what we shouldn't be doing. They're very constraining and very limiting. And we want to move to having, we still need constraints, but we want to have enabling constraints. So enabling constraints, by contrast, they guide us, they tell us what might be. They open up creativity. We can figure things out for ourselves and come up with new ideas with enabling constraints. So the metaphor is the skeleton.
So you've got the endoskeleton and the exoskeleton. The endoskeleton is an internal skeleton and the exoskeleton is the external skeleton. Exoskeletons are like governing constraints. They put a limit around something, they stop something growing. They're very constraining in a limiting way. Versus the internal skeleton, so that's the type of skeleton we have, endoskeleton. They just keep us together, they keep everything cohesive, but we can all grow in different ways on top of that. So the starfish has the endoskeleton, it kind of enables new growth, different growth, rather than a snail or a crab which have the exoskeleton, which constrains the growth. Everything is limited to growing inside the skeleton.
So we want to use those enabling constraints then to get alignment. Strategy deployment is about getting the whole organization aligned, moving in that same direction. So Stephen Bungay has some good ideas about this.
He says we need to get alignment and close the gap between the outcomes that we want to have, the plans we put in place to achieve those outcomes, and the actions that we actually do to achieve those outcomes, and then back to what outcomes do we actually get. So he talks about this in the book called The Art of Action. We're trying to close those gaps, get everybody involved. So if everybody understands and has a real clarity around what outcomes are we looking for,
What are our plans? What are our strategies for achieving those outcomes? And then actually, what are we going to do to achieve those outcomes? What are our actions? And then we can loop that back, get that feedback to what outcomes are we actually getting. If everybody has clear visibility there, then we get alignment. Simon Sinek has some similar material on it. So anybody read Start With Why? So another really good book. So he has his model, the golden circle, and he says successful organizations start with a really strong, powerful why, message of why they exist. Then once you understand why the organization exists, then you can start looking at how we're going to do that. What's our strategy for meeting our why? And then once you have your how, your strategy, you can then move on to what are we actually going to do to implement that strategy. The missing piece I think he has is the whether. Whether our why, how and what are aligned.
So I'm just going to add that into his model.
Stephen Parry has some good ideas around this as well. So he talks about organizations having a very clear purpose. That's the passion. It's a bit like the why. And then from your purpose, you develop a vision. What's the world you wish to create?
Make sure everybody has a really good, solid, single understanding of purpose and vision. And then your strategy is how you're going to get there. How are you going to achieve your purpose? How are you going to get your vision? And then the tactics, the things you're going to do to survive your journey.
Similarly, Mikhail Belikov talks about the goal, the goal, the results we want to get, the broad primary outcome that we want to achieve, that's the why. Then the strategy is the general approach we're going to take to achieve that goal.
And then we have objectives, which are measurable steps we take to achieve the strategy.
The key thing there with objectives is the way he talks about measurable. We need some way of measuring whether our strategy is working, and then the tactics or the tools we're going to do in pursuing the objective associated with the strategy. So those four elements are the key things, and we need to get really strong and clear alignment between them. If we have that, then we can start using strategy deployment.
And then we can start understanding how we use Agile. So thinking about in terms of strategies and tactics, for me, agility is a strategy. If we go back to the manifesto, I think what they were talking about there was agility as a strategy. The processes and the practices and the techniques that we use are tactics. So we want to make sure that we don't just dive in with tactics and start doing agile. What agile processes and tools and processes and practices we use, the tactics that we use, should be aligned to our strategy. How is agility going to help, or increasing our organization agility, is going to help our organization meet its goals? We can get those things aligned, then we can start scaling it a deal. If we just focus on the tactics, you're going to get little islands of agile, but you're not going to meet your strategy, you're not going to meet your goals.
So that's a very theoretical introduction to strategy deployment. When I first came across strategy deployment, it was just theory to me. I couldn't quite get my head around actually how you implemented that. Then I came across a tool called the X-Matrix. So this is what I'm going to introduce now. For me, it's a way of visualizing all those different elements and how well aligned they are and how coherent your strategy is. So it looks something like this, very simple version of it.
And we'll walk through it, but you've got those four main elements I talked about. The results at the bottom, the strategies you're going to use to achieve those results, indicators, these are the measurable indicators of whether your strategy is working on this side, and at the top, your tactics.
So if we start with the results, basically this is why we need to improve. So strategy deployment makes a basic assumption that we need to improve in some way. ...implemented that. Then I came across a tool called the X-Matrix. So this is what I'm going to introduce now. For me, it's a way of visualizing all those different elements and how well aligned they are and how coherent your strategy is. So it looks something like this, a very simple version of it. And we'll walk through it. But you've got those four main elements I talked about. The results at the bottom, the strategies you're going to use to achieve those results, indicators, these are the measurable indicators of whether your strategy is working on this side and at the top your tactics.
So if we start with the results, basically this is why we need to improve. So strategy deployment makes a basic assumption that we need to improve in some way. What's our strategy? Our strategy is needed because we need to improve, so why do we want to improve? Don's in the room, Don talks about economic models. Generally when I'm working with organisations and we're trying to figure out what results, how do we measure your results, what results are the right results to measure, it comes back to what's the economic model? How do you measure whether you're successful or not? And those become the primary goals and objectives. Just getting clarity on that is sometimes quite a difficult conversation because people have differing understanding or maybe just no visibility of what results does our organisation want to achieve this year.
Usually it's revenue based or it's financial based. So this is the model that Chris Match talks about. I've still never figured out whether he came up with it or whether I just picked it up from him. But he talks about value in terms of either increasing revenue or maintaining revenue. And that might be in terms of increasing sales, increasing the number of customers you have, increasing the number of transactions you make, those things that are going to get you new money or avoid you losing money, losing customers, losing transactions, or you want to reduce cost. And that might be decreasing existing cost or avoiding incurring costs that you don't currently have. So that might be reducing your development costs or some form of administrative costs, or maybe it's reducing some kind of failure demand. If you're reducing failure demand, there's usually cost involved in that, so that might be something like reducing the number of warranty claims you have.
Recognizing those financials, and even when we have not-profit organizations, every organization requires some kind of money, even if it's not there to generate money. So what I found when you do this for not-profit organizations, this is generally a cost element. Not-for-profit organizations, Reducing cost is really important because their financial resources are limited. And then revenue is more the donations that they need to have to come in. But also then there's usually an aspect around
what their purpose is as a not-for-profit. So it might be a number of lives saved if you're in the health service. That would be a good result to have.
So once we've got our results, then we can start thinking about how are we going to achieve those results? And specifically, what do we need to improve to achieve those results? So how can we improve our competitive capabilities? And what significant breakthroughs are required to achieve those results? What are the big things we need to do differently? Those generally need us to think about what our strategies are.
So again, I mentioned agility as a strategy. I think when the guys were writing the Agile Manifesto, that's kind of what they were thinking about. They weren't using those languages. So I'm going to ask you to kind of squint slightly as you look at the Agile Manifesto. And we're going to try and imagine what this might look like if we started using the word strategy. So first of all, we'd say we're uncovering better ways of developing software by doing it and helping others do it. Through this work, our strategies have become two. They're talking about values, but I think they're talking about strategies. So then we need to turn these four statements into strategy statements. I think when we're talking about individuals'interactions over processes and tools, we're talking about people working together, we're talking about reducing delays. So the strategy then is to prefer economies of flow. When we're talking about working software over comprehensive documentation, I think we're talking about a strategy of reducing the batch size of knowledge discovery. That's what getting that working software out there is. Smaller batches of working software so we can get The feedback from it. Customer collaboration over contract negotiation. I think that's really about delivering services with fitness for purpose. We're going to kind of frame that in lean and Kanban terms. It's really about making sure that we're delivering the right thing. That's why we want the customer interaction. And then responding to change over following a plan. I think that's about sensing and responding to feedback.
So it's a little bit of a kind of have to squinted it to get those out of there. But that's the way I think about it now. Ron Jeffries just put a post out in the last few days where he's talking about thinking that they should have focused more on practices and get rid of all the brands and just focus on practices. And I don't think I agree with that. I think, no, if I would go back and get those guys to do the Agile Manifesto differently, I'd want them to go in this direction and think about, you know what? What we're doing is taking some different strategies to traditional strategies. That's what Agile is about, different strategies.
Just to kind of throw some of my stuff in there, so if you came to my talk last year, I was talking about a Kanban thinking model. The impact side of this is relevant when we're talking about strategies. I think we want strategies which have an impact on increasing flow. Increasing the flow of the software, flow of knowledge discovery, increasing the potential of the organization, so that long-term survivability, sustainable organization, what are our strategies around that, and strategies around increasing value and maximizing the sort of value deliver. So those are... Useful guides for thinking about strategies as well. And then the other thing, nice ideas I like are from Larry Mascheroni. So when he did his work on the software development productivity index, he came up with these six dimensions, productivity, predictability, responsiveness, quality, customer satisfaction, and employee engagement. I think those six, again, are useful ways of thinking about should we have a strategy to improve any of these six areas? So I don't think any of those are strategies in themselves, but they're good ways of thinking about how do we use Agile in a strategic way. In order to improve our business.
So once we've thought about the strategies that we want to use in order to achieve our results, we then move on to the indicators.
How are we going to know whether we're actually improving? We know whether our competitive capabilities are improving. So these are proxy variables. If we think of the results as trailing variables, these indicators here are more leading indicators, leading variables, that are going to give us some indication in advance about whether we think we're going to get the results.
So again, Larry's work on ODEM is useful here. And the reason here that I like to go from strategies to indicators and leave tactics to last is so that we avoid jumping to solutions quite often. And I'm certainly guilty of this. When I go into an organization, the first thing I want to do is suggest solutions, less practices. So I find this is a way for me to hold back from jumping in and assuming that I know the answer and thinking about, okay, what's the strategy here? How are we going to know whether that strategy is working? And then we can figure out what the right solutions are. So that's figuring out what are the outcomes. The outcomes are the results that we want to achieve. The decisions that we want to make are going to be based on the strategies that we're using. And then what insights do we want to get in order to figure out what the strategies are working? That's going to lead us to think about what are we going to measure? So these measurements then become indicators of whether the effect is working. helps us make decisions and hopefully it's going to lead us back into delivering the right outcomes.
And there's a whole load of indicators out there. I'm not going to run through all of these, but you can think of most of the lean and agile measures, metrics out there that we use are good ones to use.
But make sure we're using them for the right reason. We're using them because they're going to help us understand whether we're meeting our strategy, whether our strategy is working.
So the last thing I said, the last thing we do is then we move into tactics. We can now start thinking about actually what are we going to invest in in order to make improvements? What things are we going to do to improve? What processes, practices, technologies, et cetera, can we actually experiment with in order to move the needle on the indicators, implement the strategies to achieve the results?
So Dave Snowden's work is useful here. Thinking about what are the range of things we could do, because these are all experiments, these are all hypotheses. We don't know whether any particular practice is going to work or not. So we're running experiments and we're using these tactics as ways of learning what is the right thing to do in order to get the results. So maybe some of them are going to be contradictory because we don't know which ones are going to work or not. Maybe we can take some oblique ones. So instead of attacking the problem directly, we attack it indirectly and do something which is going to work on the environment. around the problem rather than the problem itself. And maybe we could take a naive view. So the naive view here is, let's get somebody in or get some opinion from somebody who doesn't have the same domain experience that we do. And they might come in with a fresh perspective and fresh ideas. So there's a range of ideas we can use there to think about what are the possible things we could do rather than just what single thing we can do. And then we might be able to run multiple experiments.
So again, this is where we can start looking at what are all the individual practices. I picked, I just went on to, I think I went on to the Agile Alliance website that has a kind of a list of Agile practices and bunged them in there. But there's a range of stuff and you can go down to the really small stuff, there's TDD, let's just get TDD going. Or you might go to some of the big stuff and say, well actually I think it might be worth trying SAFE. Or Nexus or one of the scaled agile approaches. Or maybe we want to focus on the business side of things. So let's try some of the BDD, that BDD stuff. Or maybe it's DevOps. There's a whole load of stuff. There's lots of really, really good ideas out there. Don't copy them just because another organization's copied them. Copy them because they're going to help you meet your strategy.
They're going to help you move the needle on your measures and your indicators. And ultimately, you can now understand how they're going to help you achieve your results.
The last thing then, and this is why this is called the X matrix, are these matrices in the corners. So this is where we start looking at the correlations between all these different elements that we've talked about. How well do they correlate with each other? Where is there strong alignment, or maybe where there's weak or no alignment? So we start filling in dots. So the solid dots here indicate really strong alignment. So this is saying that I think that if we decrease lead time, that's going to really help us reduce the amount of churn, customer churn, and that's one of the results we want to do. Whereas this one here, there's kind of some alignment here, but it's not a really, really strong alignment. But it's worth noting. So I think increasing in H3, so H3 is Horizon 3 perspective, so investing in things that are not going to generate any immediate return for a few years.
Might have some impact on reducing churn, maybe not. And where there's a gap, this means I don't think there's any correlation at all. So I don't think increasing throughput is going to have any relation to reducing our churn at all.
I'm going to ask you to spend a minute looking at that and maybe turn to the person next to you. There's one thing I kind of put in there, which I think... is an interesting observation. I'm going to see if you can spot it just by looking. So looking at those results, strategies, tactics, indicators, and the correlations, is there anything obvious that stands out that you think doesn't make sense or you'd want to ask questions about? Spend a minute having a look at that and maybe have a chat with the person next to you about it.
While I drink some water.
Anybody want to be brave enough to shout out any ideas?
Sorry, which one?
So there's one, so let me, I think you're on the like lines. There's one I put in here, and actually I took some dots out. If you look at product ownership at the top as a tactic, you'll notice that it's got no correlation to two of the strategies and only a weak correlation to one of them. And the product ownership as a tactic only has one indicator. So I'll be looking at that and kind of going, well, is product ownership the right thing to be doing? So one of the things you're looking for this is looking for those gaps and those holes and where you don't think you're doing the right thing. Equally, you could look at that and say, you know what, actually, I think product ownership does have a strong correlation to giving the best user experience. I think if we have good product ownership, we will get a better user experience. So I think there's a strong correlation there. You could have that argument. So one of the things this gives you is a nice, single, visual way of provoking these conversations. You want to be looking at this, looking, what don't I understand there? What doesn't make sense? And if something doesn't make sense or you think something's wrong, you can then have a conversation about it.
And it's the conversations that are important with this. So Thomas Jackson is the guy that kind of wrote the Bible on The X matrix, as far as I'm concerned. And this is the quote that jumped out at me that he says about it. It's the memory of what was said and felt that creates alignment, not the final piece of paper. So the X matrix is not something that somebody on high fills in and says, here's how it's going to be and passes it down. It's a form of A3. So just like other A3, single piece of paper, it's there to have a conversation around. Really simple, concise visualization of a model that you can then talk about.
If you've read Jeff Patton's book, Jeff Patton has this great metaphor of holiday photographs. People read that? So he uses the idea that if he looks at a holiday photograph or shows somebody a holiday photograph who's on the holiday with them, there's a lot of meaning and there's a lot of memories behind that holiday photograph. But if you show it to somebody else who wasn't on the holiday, it's just a picture. And I think it's the same with the X matrix, the same with A3 thinking. So actually, this picture there is my daughter on holiday this year. Probably it's not a great photograph, it's quite blurry. But to me, lots of memories behind that. That was a great night. Not a great photograph, but a great night. So it's got a lot of meaning for me.
So that's what we're trying to get. We're trying to get alignment through the conversation. And just to ram the point home, Dewitt Sobek, who wrote one of the great books on A3 thinking generally, he says the same thing. And it's the second sentence here that's the important one. It's the process of creating the report that becomes the thing of value, not the report itself. So creating a report, having those conversations, that's where the value is. You get a document at the end of it, but that's just a nice byproduct.
So the way we have those conversations then is this process called catch-all. Catch-all again is one of those things that I read about, I didn't quite grasp what it meant, but for me the X matrix makes it something tangible. So it's the way we try and avoid that strategy kind of implementation from the top, just do this, you know, more tactic deployment than strategy deployment. How do we get everybody's conversations, get everybody's input? So it's a bit like decentralized decision making. Anybody recognize this roundabout?
Okay, a few hands going up. It's the magic roundabout in Swindon. So it's the one Dave Snowden uses a lot. And it's a really good example, I think, of distributed decision making. You've got the lines, the white lines are the kind of the enabling constraints. There's some soft boundaries. You don't have to stick within the lines, but generally it's good practice too.
But everybody individually can decide what's the best route around that roundabout. And if a bit of the roundabout snarls up, you can take another route round. So actually it's got lots of traffic, really good traffic flow, and it's safe. There's another example. So I'm going to play a bit of video. I think we've got time to cover most of this.
It's not a roundabout, but it's just showing some of the differences using a traffic example of creating enabling constraints and getting distributed cognition as well and getting better results from it. Lines are the kind of the enabling constraints. There's some soft boundaries. You don't have to stick within the lines, but generally it's good practice too.
But everybody individually can decide what's the best route around that roundabout. And if a bit of the roundabout snarls up, you can take another route round. So actually it's got lots of traffic, good, really good traffic flow, and it's safe. There's another example. So I'm going to play a bit of video. I think we've got time to cover most of this.
Just to, it's not a roundabout, but it's kind of just showing some of the differences using a traffic example of creating enabling constraints and getting distributed cognition as well and getting better results from it.
Do we have audio?
I've worked here for about 10 years and it's been the same all the time. Having to cross one lot of traffic lights, then to wait for the other set of traffic lights. Traffic's coming from you all angles, turning left, right, it's horrendous.
It's a very busy junction. Obviously the main arterial route is London Road, so it's a lot of the high squares. It's not the safest of junctions. We have quite a number of accidents here.
If I'm trying to cross the road, I get stuck in the aisle and it's a bit of a crowd. That's a little bit dangerous, especially the traffic goes quite fast sometimes.
So, I've been in the city, which is pretty catastrophic.
Over the years, the increase in traffic and the steps taken to try to appeal the badge have changed this place from being the heart of the village into being merely a traffic signal control wasteland. Of course, what it does is it cuts off one half of the village from the other. So people who live over here on the west side have to cross four lanes of traffic to get to the high street. People can now buy all their goods and services from other town and city stores or off the internet. There's no functional necessity for interpointing at all.
We're here to revitalise the village centre. The status quo isn't really an option. You can see how bad it is now. We've got to do something. We looked at pedestrianisation, we looked at opening up side roads, and everything we looked at didn't actually do anything for Poynter. It just moved traffic faster.
Our challenge is to find a way to accommodate that flow of traffic that doesn't cut the city in half. And to do that, the scheme is about creating slow, speedy, continuous traffic movement.
There's a misconception that if you take away the light, people will drive fast. Actually, the opposite is true. It's the green light that encourages the speed, that licenses the aggression. If you take away the light and there's uncertainty at the junction, people naturally approach slowly and filter. That's absolutely true.
He's absolutely right, isn't he? People sit there and track out, revving the engine, waiting to get away. If they come up to a junction where there's no light, they do go slowly.
All the examples that people can quote from Sweden, Morton and the Netherlands are in very, very low traffic volumes. It's a huge chalkboard. I honestly passionately believe you cannot make a junction as busy as this into shared space.
No, I think it's a nightmare idea to be honest. I think two roundabouts, a massively busy junction, people are going to know what to do.
It is a high traffic junction, that's clearly one of our concerns. We've been to see examples of this elsewhere. We've taken real data from points and microcirculation says it will work. These won't be roundabouts, they'll be rambles. I'll feel a little bit like roundabouts, which I feel here is a place, like a square, a plus. It's essential that you tell drivers the right story from further back. And so we're locating data on each of the approaches. The traveler senses something that completely changes scale. The highway ends and points at the beginning. Shared space is a term which simply describes a shift.
away from the regulated highway, towards using the natural skills that humans are blessed with to negotiate movement and to allow normal civilities of life to continue. Shared space is not new. Troy streets have always been since we've had cities, since we've had streets.
It's only in the last 50 or 60 years that we believe it's important to segregate traffic from other aspects of life. Once you bring speeds down, you get a completely different relationship between pedestrians and drivers.
A new hierarchy emerges with vulnerable road users at the top. Pedestrians in the shared space scenario, where there are no lights to dictate behaviour, are seen as fellow road users rather than obstacles in the way of the next line.
That's a fair point. That's a very fair point, and of course all motorists are pedestrians.
The scheme will hugely increase the space available to pedestrians by about 100%, by doubling the amount of space. Because as we reduce the speeds, the amount of space needed for vehicles diminishes. So we can extend the payments substantially around the lovely churchyard and around the almshouses, and of course around the principal businesses and shops that surround the region. In the same way that we've done in Park Lane. Park Lane used to have very narrow payments. Because we reduced the fees and the limit to extend the payments, there was a feeling of vitality about the street which was lacking before.
The street becomes much easier to cross the narrower the space you have to cross.
Well, I found it better crossing that than being crossing when it is through the middle. The new stuff for me is traffic.
We've had to reduce the lanes from two approach lanes to one. You have two lanes. The amount of time it takes for a pedestrian to cross the traffic means you have to have traffic signals. The sooner you've got traffic signals, you've got built-in delay factor. There's 26,000 vehicles running between Stoke-on-Trent and Manchester. We can at least not make the congestion worse than it is now, and probably improve it. This will be the most ambitious street design scheme yet seen in the UK. Nobody until now has applied these principles to such a busy intersection. It is, in our view, the only way to retain the quality of the pointing, whilst keeping the highway country going. I've seen what's happened on part of the lane, I'm fully in favour of it, and when that gets finished at this junction and the whole thing comes together as well, we'll find out more about how it's going to happen. I hope my words to this do not concern you. I think it would be fine, I think I would have brilliant. The guiding light has got to be what is best appointed in the long term. Maybe you're meeting your...
I'm out of here, yeah.
It's been hell living here whilst this has been going on.
Anybody who's ever had a new kitchen or a new bathroom will know that you have to go through some pain to get what you want in the end. We won't be doing it if we thought it was going to make the place worse. We would not have gone to the trouble we have to get the investment to put it into point if we didn't think it had some chance of success.
It's just, you just have to round it really. So you've got to give it a go. Definitely, yeah.
The most important thing was revitalising the point of the point of the time. But the vehicle movement and the traffic that found its place was key to the success of the revitalisation.
It's always hugely exciting to see a scheme finally in place after so many years of difficulties of persuasion and struggle and testing.
Somebody who lives here and goes through it every day, I have two emotions. One is that I'm glad that the bulk of the work is done. Secondly, I'm delighted that so much more vitality about the village centre.
I remember when we first sketched on a bit of paper this double round book here, and it began to emerge in my mind, well, will this work? And at the time, so many people said, that's impossible.
I was a little bit sceptical at first about it, when I heard that there were going to be no pavements or edges between the pavements and the road. So that might be just working really well now.
I think I was a hardened, not really sure, quite against it maybe.
So I'll pause it there because it still goes on a bit. I just think there's so many lessons in that video that we could take. But the key ones for me, particularly in relation to strategy deployment, are the way they got rid of those hard boundaries, the traffic lights and the pavements with the edges, which are those governing constraints. They stop you from moving and they stop you from driving in places. And people switch off to moving to no traffic lights.
And just a shared space, so no pavements, no edges. But you'll notice that there's kind of demarcated zones, so there's different coloured paving and different layouts, which kind of give a hint, so they're more enabling constraints. They kind of guide you maybe in what you could be doing and what you should be doing, but there's nothing to stop you doing anything else if you need to. And I think you can start seeing the way the traffic is flowing now and that generally the people are happy with it. So for me, that's what... That's what we're trying to do with strategy deployment and with catch ball. Use strategy to set the enabling constraints that we can then pass around the organization and allow everybody in the organization to decide what's the right thing to do and get everybody's input. No one person at the top of the organization has the answer. Everybody has a little bit of knowledge. Everybody has experience. Everybody can input into what is a good way of working. What things might we try and experiment with?
So there's this notion of catch, reflect, improve, pass.
So you take an X matrix, you take a strategy, and you pass it for feedback. So a group, a team will then catch that, they'll have a look at it, and they're going to reflect on it. And they're going to ask questions about it. And they're hopefully going to improve it. So they'll add to it, they'll build on it, they'll come up with even better ideas, and then they're going to pass it on. They'll either pass it back, here's our feedback, here's the way we would change it or improve it, or maybe they'll pass it on to another team or another group of people that they think have some good knowledge and good ideas.
So you get kind of nested sets of teams. This isn't, again, this isn't top down. This is just lots of teams as it kind of spreads out and around the organization. It'll start off with a central team. You're going to get a leadership team that are going to ultimately guide and set the initial strategy and probably set the initial results. But then each of these people will take one of those high-level tactics. Say, okay, I'm going to take away and I'm going to work with some people in the rest of the organization for that. And they'll go and create another little sub-team. And each of these sub-teams then takes the X matrix and they may work on another version of the X matrix which focuses in on a specific area or a specific part of the strategy. And they'll come up with some next level down, some more detailed tactics. And they might go and form some more teams. So this way it's spreading out. And it's not top down, it's not hierarchical. The kind of different colours here represent different bits of the organisation. So we're getting feedback, we're getting input. It is up and down the organisation, but it's also round the organisation as well. It's getting passed around, it's getting passed up, it's getting passed back.
So you ended up with nested experiments. So your first X matrix, your first idea of a strategy and high-level tactics is a hypothesis. So you're going to do some experiments on that. And the first tactics that you start working on, the first improvements you start working on, at the very first do in here. But in order to run that experiment, because it's potentially a year-long experiment, you break that down into smaller experiments. So that's what that kind of next level of sub-teams do. And they're saying, okay, let's take this big hypothesis and let's run some smaller hypotheses as a way of getting feedback on it. And then each of those gets broken down into some more experiments. So you've got nested experiments that start off at your annual, Hoshin, your annual X matrix, and end up down at probably the monthly level where you're doing really small experiments. And they're all aligned. They're all feed back up to the top. So you're constantly creating data, constantly checking in and seeing whether the indicators are moving in the way that you want them to move or not.
This is the way we did it when I was at Rally Software. So this is where I first experimented with this. And we used to get 100 people in the room for a two-day planning meeting around about the start of each financial year. And that was representatives of all departments, all levels of the organization, and we used to bring customers in as well.
So of those 100 people, maybe 10 of them were customers. And you can see here, this is going to photograph of people, they've broken out into small working groups. I think at this point we'd had the strategy presented and we were asking teams, okay, what do you think we should do? What are the tactics do you think we should do and how do you think, what do you think would be the right measures to do these? You can see it's a bit blurry, just kind of right at the top in the corner here, you can see we actually created a giant X matrix on the wall and it was kind of six foot high that looked something like this.
So we drew this out and through the course of the two days, these 100 people in the room slowly start populated. One of the interesting things we did, you can see here we've got, we actually started off with seven strategies. I wouldn't recommend having seven strategies. Because otherwise they're not really strategies. Strategies, while they guide you on what you should do, they should also guide you on what not to do as well. Otherwise, they become strategic horoscopes, I like to call them. I picked that up from Zach Neese. You know, you look at a horoscope, and horoscopes are generally so vaguely worded that, oh, yeah, that came true for me today. Because they could apply to anything. So you don't want your strategies to be like horoscopes, where you can basically use them to justify any piece of work. You should be able to use your strategy and use it to rule. We shouldn't be doing that because it doesn't meet the strategy. But what we did here was we started with the seven because the leadership team generally wanted input from the whole organization on what the strategy should be. I started off with seven strategies. I wouldn't recommend having seven strategies because otherwise they're not really strategies. Strategies, while they guide you on what you should do, they should also guide you on what not to do as well. Otherwise, they become strategic horoscopes, I like to call them. I picked that up from Zagnis. You know, you look at a horoscope and horoscopes are generally so vaguely worded that, oh, yeah, that came true for me today. Because they could apply to anything. So you don't want your strategies to be like horoscopes, where you can basically use them to justify any piece of work. You should be able to use your strategy and use it to rule. We shouldn't be doing that because it doesn't meet the strategy. But what we did here was we started with the seven, because the leadership team generally wanted input from the whole organization on what the strategy should be. And then you can see we've started filling in the correlations at the top here. And at the end of the two days, the leadership group took this away, looked at the correlations, looked at the input and the feedback they got from people and decided and narrowed it down to three strategies. And I think they kind of merged a few and blended them and reworded them, but we ended up with three strategies. So that was a two-day process, 100 people in one room starting to get feedback, where the people in the room were creating the tactics and then forming subgroups and taking those tactics. And then throughout the year, we would then check back in on how those tactics were working.
The other metaphor I like around this for catch-all is improvisation. So Neil Malarkey is a... a UK improv guy who used to, he's kind of one of the, I think, founding members of the Comedy Store in London. But he now goes around and does business consulting where he teaches improv to businesses because he's kind of come across the same idea that effectively, in the modern day, the modern environment, businesses need to be able to improvise. And that's what experimentation is. We're improvising on what do we think we should do? Let's try things out. So he has his rules of improv, which are conveniently spelled LAGA. So listen actively for offers. So listening for offers is that catch bit of catch ball. Take the offer, take the X matrix and accept it. So you don't just kind of go, that's rubbish. You accept it for what it is. And you reflect and improve on it. So that's the giving offers in return. So you build on it. And in building on it, you're exploring your assumptions, your assumptions, the other person's assumptions. So what assumptions came into this? What assumptions do I have about it? And we incorporate into that. So that's really the improved bit before we pass it on. So I like it. It's another kind of nice way of thinking about, I think, how catchable should work.
So how we actually do this with Agile, generally I find that you can't go into the top one organization and kind of go, you know, you guys, you should be doing strategy deployment and you should be filling in an X matrix. So I find we start in the middle. So as an Agile coach and consultant, I go in, generally I'm brought in as part of an Agile transformation. So I kind of start in the middle where actually I think I'm going to do an X matrix just about the Agile transformation. And that's because what I find is that agile transformation is a tactic that an organization has chosen to use in order to meet its strategies. So once we get that in context, we can now start linking why are we doing this Agile transformation, what are the organizational strategies that Agile is actually helping us towards, how are we going to measure whether Agile is working or not, and then what are we going to do? So then we can say, within our Agile transformation, how are we going to start rolling this out? Should we start rolling it out to particular customers, or maybe you've got multiple locations, let's pick a location and work on it there, or maybe there's a key project that we want to work on. And then we can drill down to the next level, say, having picked, let's say we're going to work with a customer. And our kind of a key tactic is to help a particular customer become more agile or work with a customer for one of their projects to be more agile, we can then say, okay, what methods, practices or techniques maybe should we be using?
We deploy it down. get the people who are working with that customer to figure it out. But they have the context that this is part of the Agile transformation, and the context that the Agile transformation is part of a larger organizational improvement. It's not a siloed thing. It's not just IT. It's not just engineering. But it's just something that we're doing that's been deployed down to us to help.
Don's in the room, so I'll have to quote him.
When we're doing strategy deployment, our strategies are unpredictable things. Every strategy is a hypothesis. We don't know whether it's going to work out. So using cadence, and I love this quote from Don about using cadence to turn unpredictable events into predictable events, we're using the same principles there. So we have our indicators. Let's check back in on the indicators on a regular cadence to see whether they're working or not. Because it may be that you discover that your indicators are not improving in the way that you want it to do, and you need to revisit your tactics. Or maybe you discover that you've got the wrong indicators and you think there's something else you should be going. Or on occasions, and we did get this at Rally once, you just decided that you've got the wrong strategy. So having a regular cadence that forces you to go check in, how are we doing against what we said we were going to be doing and what changes should we make. And we need to be ready to fail and to learn.
Kind of next public question, who knows who Lupita Nyong'o is?
Another well-known business consultant. No. She's an actress. She was in 12 Years a Slave, and more importantly, she's in Star Wars 7, The Force Awakens.
But I just really like this quote as well.
If you don't risk failure, you don't discover things. So this is a cheesy definition of failure, but I quite like it as well. We only learn when we fail. So if we're going to do strategy deployment and we're going to run experiments and treat the things that we're doing in our agile transformation as a set of experiments, we need to be ready and recognize the fact that some things are not going to work out the way we thought they were going to do. And that's okay because we're going to learn from that and then we can do something different and we can hopefully improve over time.
So, just to wrap things up then, we don't want to be copying other organizations'solutions. We need to figure out what our own solution is. We need to find our own operating system, and we can use strategy deployment to do that. So maybe the three steps, the three takeaways that you can take from this is you can just go off and populate an X matrix on your own. Just sit down, and this is what I do a lot of the time. To me, it's as much a mental model to help me think about context and problems as it is as an actual physical tool. But just get a piece of paper. What results do you think you're trying to achieve? What are your strategies to achieve that? How are you going to know whether you're achieving the results and whether the strategy is working? What are your tactics? What are the correlations like? Are you doing the right things? Are there strong correlations? Is it all coherent? If you've got an extra metrics, then you can start passing it around. Start playing a little bit of catch ball with it. Give it to somebody else. See what they think. Get some feedback on it. See how they can improve it. And then start getting feedback.
Start generating those feedback cycles from your indicators. Are the things that you're doing actually working or not? So populate, play, and then propagate. You know, the three Ps that I invented.
Because this is what we're trying to do. And this is one of the questions that's kind of set me off down in the path because I go into organizations and you spend a few days there as part of an agile transformation. And then somebody is inevitably going to ask, how do we know whether agile is working or not?
To which I generally say, well, how do you know if anything's working? It's not about whether Agile is working or not. It's about is the business improving? Is the business getting the results it wants? Agile is there to help that. Agility is the strategy. So if you can figure out whether anything is working, Agile just fits under that umbrella. Otherwise, you get bogged down by kind of going, are we doing Agile? Are we doing the tactics? You might be doing the tactics but not getting the results.
So last quote, back to Dean Karnasas.
And I kind of say this then as we go into the rest of the conference. So you're going to be spending two days listening to lots of ideas. People are going to be saying, this worked for me. I think this is a really good idea. Listen to everybody, but follow no one. And I hate to say it, but that applies to me as well. So listen to my talk. Hopefully you've listened to it. Don't just blindly do it just because I've said it. Think about whether it's a good idea. Discard it if you want to. Try it out. Maybe it'll work. Maybe it won't work. But don't just blindly follow things. Take all the ideas, put them in your context, figure out whether you think they're going to work, run some experiments with them.
These are the two books that are kind of mostly influenced this, the kind of the topics of this talk. This one here, Hoshin Kanri for the Lean Enterprise. This is kind of the X-Matrix Bible, if you like.
It comes with a health warning. It's a very dull, dry book, but with some real nuggets of gold in there. It's a kind of classic lean manufacturing book, so there's a little bit in there you're kind of going, this is not relevant. But if you can kind of get over that and get beyond it, it's also expensive, but it comes with a CD, so that's okay.
Worth reading, but just don't expect it to be kind of a page turner. And then Getting the Right Things Done is a slightly easier read. Talks more about strategy deployment generally, more about the kind of the traditional A3 thinking and strategic A3s. But the two of them together, I think, are a good combination. The third one, if you want another one, would be Stephen Bungay's Art of Action. I've not put it on there just because I've actually not, I don't think I've read it well enough to be able to recommend it, but lots of people have recommended it and what I've read of it so far. It's highly relevant as well, kind of taking, what he's done is taking some of the military lessons. and effectively the successful military organisations are doing strategy deployment.
Okay, I'm done. I'm not sure whether we have time for questions. Otherwise, I'm around for the next two days, so just come and grab me or email me or tweet or something else. Thank you.

Transcript