Karl Scotland
Transcript
Alright, let's start with a little exercise.
What I'd like you to do is pretend you've got a pen in your hand.
And look up to the ceiling and draw a big clockwise circle on the ceiling. Nice big clockwise. It's really important that you do it clockwise, otherwise this isn't going to work. Everybody know clockwise? It's the way the hands on a clock go round, that direction. Alright, while you're drawing this big clockwise circle above you, I want you to slowly bring the circle down.
Keep it bringing me down. Keep it going clockwise until it's run about down your waist. About down here. Keep it going in the same direction.
Now then, I'm just going to walk down here. You keep going, I'm going to stop.
What direction is the circle going in?
It doesn't look like clockwise.
It's counterclockwise.
Counterclockwise, anti-clockwise. Is anybody doing it clockwise? I told you to do it clockwise.
So what happened? Why are you all drawing anti-clockwise circles? Because it's a change of perspective.
So how many times have you been into an organization or you've been working in your own organization and you get into a conversation with somebody and you start having
a heated debate about my perspective versus your perspective?
And I'm saying, no, no, no, no, no, no, no. The circle's going clockwise. And you're saying, no, no, no, no, don't be stupid. It's going counterclockwise. And actually, we're both talking about the same thing. We're just looking at these things from different perspectives. What I'm going to talk about today is a way of looking at our organizations and our processes and our practices from different perspectives. Not so that we can argue about them from different perspectives, but so we can understand and learn that the... different perspectives exists and if we can start seeing that we're actually talking about the same thing from different perspectives, we might be able to move forward together.
So that for me is why Kanban is about learning and why Kanban is a way of creating learning organisations. When I first came across Kanban back in 2007 when I heard David talking about it at the conference in Washington, The thing that I took from it was that I could go back to my teams at Yahoo that I was struggling with, or we were struggling with Scrum, and it gave me a way of looking at the processes from these different perspectives so that now I had a way of figuring out how to solve the problems myself. Rather than taking a solution that I'd read elsewhere and just trying to implement that solution, I had a way of trying to come up with my own solutions, solving my own problems. So I'm going to talk about a way of not giving you a solution, but a way of you solving your own problems. I'm not going to give you any answers in this talk, I'm afraid. This is not a kind of Kanban basics, go back to your organizations and do these practices. This is a talk about, here's a set of questions. That you can use to think about your organization, your processes from different perspectives, and then you can answer those questions yourself. Come up with your own answers and come up with your solutions. So this is what, there's various copies, and you should have one in front of you. This is the English version. There is a French translation. It was kindly done by Fabrice Emeti. Unfortunately, he's not here. But there are some copies of those, and I'll show you the URL. You can download these yourselves, the English and the French version.
Let me just talk quickly through this model, and then we're going to work through it in a little bit more detail, and we're going to stop at various points, and I'm going to give you the opportunity to talk to each other about these questions and how you might answer these questions for your context and your situations. I use questions because I think of these as heuristics. So again, going back to this idea that we're trying to solve problems, we're trying to come up with our own eureka moments, and eureka and heuristic of the same root. So we don't have eureka moments about problems that we've already solved. We have eureka moments when we solve a new problem. So we use heuristics, and one way of thinking about heuristics is thinking in terms of questions rather than answers. We can use those questions to help us solve problems. So each of these sections has a little question in it, and we'll work through those questions. In the centre of this, is my laser working? There we go. Not very well. We have the system. So we talk about systems thinking with Kanban. First thing we need to do is understand the system that we're working with, what the scope of the system is, what the systemic problem is. And then on this side here, the right side as you're looking at it, we have three impacts. When we're working on a system, we want to make make changes to that system such that they have a positive impact. If we have a positive impact, then the changes we'll make are good changes. If we don't have a positive impact, if we have a negative impact, then we've probably not made some good changes and we want to look at reversing them. And we can think about impact in terms of flow, value and potential. So I like to look at it from the three different perspectives there. So we have a system. We're going to make some changes to that system. We want those changes to have a positive impact. The changes that we make are the interventions. So then on the left-hand side, we have these interventions, study, share, stabilize, sense, and search, deliberately all beginning with S.
To try and make them memorable, they're my own little five S's. So study is finding out more about the current situation, sharing that common understanding with everybody through visualisation, starting to stabilise the system so we get it under control so that we can start improving it, sensing the capability so that we know whether we're improving it, and starting to search the landscape, search the adjacent possibilities, search for new ways of working that we think will improve. So let's start working through this, and we're going to start with the system. So the question here is, what holistic problem, difficulty or frustration are we trying to address, and who is experiencing it? What's the scope of the system? Are we dealing with a really small system, whether we've got just a few... local people or are we trying to do a huge system where actually we're trying to solve world peace? It's probably somewhere in between is the right idea but trying to understand what is the problem. We were dealing with a team problem, a business unit problem, an organizational problem or a market problem. Normally we're trying to deal with business problems so normally it's a business problem and we're talking about trying to solve problems for the business people, the executives, or maybe senior stakeholders or even our customers, direct customers. A good way of thinking about this is by looking for stories and looking for patterns.
So at least one talk here has had the Kanban iceberg. I like the iceberg metaphor as well, and systems thinking uses a systems thinking iceberg as well, where at the top, the bit of the iceberg that pokes out of the water are the events that we see, individual events. But under the water, you start seeing patterns of events. Multiple events causing patterns and we can start understanding those patterns to start anticipating problems. But actually those patterns are caused by the next level down in the iceberg, which is the system design. So the way the system designs causes those patterns of behaviour, but actually what we see are individual events. And at the bottom of the iceberg, we have mindset, the way we think about. So the way that we think about things actually leads us to design our organizations in certain ways, which leads us to design our organizations in certain ways. which leads to events. So trying to get down underneath the water of the iceberg, a good way of doing that is through looking at stories, telling stories. And there's a nice little story format called the Pixar Pitch. Anybody know the Pixar Pitch format? Just do that. Interesting. So this is a little template that you can tell any Pixar film story with. So we have, once upon a time, there was a widow clownfish called Marlin who had a son called Nemo. Every day he'd tell Nemo, don't go out swimming in the big, bad, wide ocean because it's dangerous out there. But one day, Nemo did just that. He went out, had a bit of a tantrum, went swimming out on his own. Because of that, he got caught by some fishermen and ended up in a fish tank in a dentist in Sweden. Because of that, his father had to go off and try and rescue him and go on a big adventure and make lots of friends and ended up rescuing him. So until finally they all lived happily ever after. Very basically. I think the actual Pixar pitch is slightly more refined than my telling of it. But we can use that format to think about how can we put together, tell some stories about what's been happening in our organisations to start understanding the system problems that we're trying to solve. So who's the story about is going to help us understand the scope.
If we can tell a story about a senior stakeholder or a key customer and the challenges that they're having, so what's happening to them every day, what are the key moments, the one-day events that are really significant, and what are the consequences of that, what are the because-of-that moments?
We can start getting a feel for what's going on with the system and we can use this as a basis for designing a system to improve some of those challenges. So now is the time for you to do a little bit of work. I'm going to give you two minutes, and two minutes isn't very long deliberately because we've only got an hour. Turn to the person next to you, or maybe a group of three, and talk about how you would answer this question for a business problem, a business context that you're currently in. So what holistic problem, difficulty or frustration are you trying to address and who is experiencing that problem? Two minutes, and then what I'll do is I'm going to stand here at two minutes and raise my hand. And if you see me raise my hand, what it means is you stop talking and you raise your hand as well. And we'll see how quickly it takes for the room to become quiet. And we'll do this multiple times, and hopefully you'll get better at that as well. All right, two minutes to answer this question with the person next to you.
Very good. Just a little anecdote, a little tangent. I was recently working with an organisation that we taught this technique to. We were doing a release planning session with around about 400 people in the room, and they are so well trained on this that they facilitate to put their hand up, and within two or three seconds, 400 people went silent. Very useful technique to learn.
So you'll notice at the bottom of this template, I've got the last because of that is because of that we want to use the Kanban canvas. So the idea is we tell the story and we get to the point of the now is. Very good.
Just a little anecdote, sorry, a little tangent. I was recently working with an organisation that we taught this technique to. We were doing a release planning session with around about 400 people in the room, and they are so well trained on this that they facilitate to put their hand up, and within two or three seconds, 400 people went silent. Very useful technique to learn.
So you'll notice at the bottom of this template, I've got the last because of that is because of that we want to use the Kanban canvas. So the idea is we tell the story and we get to the point of the now is. We're now going to design a Kanban system. We now want to go through some kind of transformational change. And then the until finally I've grayed out because the until finally is the impact we want to have. So we move on to talking about what impact do we want to have, not in terms of what do we want the end solution to look like, but how are we going to assess the fitness of any end solution? How are we going to define some fitness criteria? So David talks about fitness for purpose. This is a similar concept. We don't necessarily know what the end solution is going to look like, but we can use some techniques to help us assess, is this a solution, a good solution or a bad solution? Are these practices that we're using working or not working? So that's what I mean by impact. And it's a term that comes from complexity science. Complex systems have an impact.
The first of these impacts is flow. So now we're telling stories about the future. What stories do we want to be told in the future? Or how do we want our Pixar pitch story to end? But what stories might be told about the work going through a perfect process which has reliability and efficiency? So flow is mostly about the process, about the way we do things. So if we have good process, good flow, we're doing the thing right.
Perfect process and when we get good flow we have reliable processes. The work goes into the system, it flows through the system, it comes out the other end nice and smoothly and we get of when we expect to get stuff. So that's reliability. And we tend to talk about process efficiency. So if we're focusing on flow, we are talking about process efficiency, spending more time on value-adding stuff and less time on less value-adding stuff. So that's all about process efficiency.
So when we're telling stories about having really good flow in the future, we want to be telling stories about what would the impossibly good ending be in the future. And really exaggerating the ending, because again, we're not really focusing on really specific details. We're saying, let's imagine we have this utopian future, this perfect future. But another way of looking at it is the other end of the scale. Let's imagine this all goes horribly wrong, or we don't do anything. What would be the impossibly bad ending, the dystopian future? And if we get these two extremes, then as we get into the change process, as we start implementing this Kanban system, we can start asking questions. Is the current situation more like these utopian stories we talked about? Or is this situation more like these dystopian futures we talked about? If they're more like the dystopian ones, then probably things are not working out so well. If they're more like the utopian futures and the impossibly good futures, probably we're moving in the right direction. So telling stories about the future is a good way of helping us understand whether we're having impact. So we do that for flow and the process, but we don't just want to have really good flow. Flow because we can just be delivering crap. We want to be delivering value as well. So the second impact is value. So here we're going to tell stories about the work creating an unbeatable product, which has validity and effectiveness. So if flow is the process, value is the product. If flow is reliability, then value is validity. So we want the work to be doing to be the right work. So now we're not just doing the thing right, we're doing the right thing as well. And if flow is about efficiency, then value is about effectiveness, about what we're doing. And we need both of those. So it's not about an either or. It's not about one being good and one being bad. We need some element of both. We need some flow and some value. And again, think about stories in the future with impossibly good endings and impossibly bad endings. And then the third one is what I call potential. So here we're now thinking about stories that might be told in the future about work being done by passionate people who have flexibility and euphoria. So this is the third point of the little triangle we're creating here, flow, value and potential. Product, so process, product and people. We can get a really good flow and we can deliver a really great product, but we do it by beating up our people.
If we do that, then the organisation has no long-term potential. So potential is about doing the thing sustainably.
And that also means having flexibility in the future. So flexibility then goes alongside reliability and validity. As the landscape changes, as the market changes, as our customers change, as technology changes, we need flexibility to adapt to that. And euphoria sits alongside efficiency and effectiveness. So euphoria was the closest I could come up with with the third F word. But people being happy. The third side, the third point of the triangle. So again, thinking from that potential perspective, what stories would we want to tell in the future if we have absolutely perfect potential?
And the dystopian stories about having no potential at all. I'm going to give you two minutes again, thinking about the system that you just talked about. Now spend two minutes talking about the utopian, dystopian futures that you might want, we want to have or want to avoid, with respect to flow, value and potential. I'll give you two minutes and then I'll raise my hand again to get some quiet.
So the reason for starting with systems and impacts is to try and avoid that temptation that we naturally have to dive into solutions and want to put practices in place. So I'm deliberately trying to push that off and really get people thinking about what is it we're trying to do here? What problem are we trying to solve? What future are we trying to create? Get people thinking about that before we start thinking about, okay, what are we actually going to do? That's the next section now, and this is what we call interventions. So system interventions, actually getting involved with something. An intervention is something you get involved with when you intervene in an argument, when you intervene in some other kind of situation, you get involved in it. This isn't something you're doing externally. So an intervention is something that we can actually do with the system, within the system, in order to hopefully have a positive impact.
The first of those is study. So the question here is what could be done to learn more about customer and stakeholder needs, the resultant demand and how that demand is processed. There's three bits to that really. One is let's understand, learn more about our customers, our stakeholders, the people whose problem we're trying to solve. And we can do that with something like empathy mapping. Anybody familiar with empathy mapping?
So a few hands are going up. So this is where you spend time having empathy, getting into your customer's shoes. And there's a simple little format that you can capture on a sheet. What do they say? What do they do? What do they think? What do they feel? And out of that, getting some understanding of your customers or your stakeholders, you can come with simple statements such as, my customer needs a way to solve this problem because these are the consequences. So it's drilling down a little bit deeper into understanding your customers and their problems.
But your customers come to you generally with some demand, with some work they'd like to do. So we can do some demand analysis on that, and we can start you looking at techniques such as classes of service or looking at cost of delay. To get a better understanding of the work that we're doing, because not all work is equal, not all work is homogenous. And maybe using concepts such as value demand and failure demand. What work should we be doing more of? What work should we be doing less of? Because we're going to treat that work differently.
And then the third then is how that demand is processed. And we can start looking at techniques such as value stream mapping here to look at how do we do the work? What are the key points in our process? And whether we call it a value stream or a knowledge discovery process or a value network, it doesn't really matter. For me, the point behind that is we're studying. We're studying to learn more about the current situation. So we talk in Kanban about start where you are now. To start where we are now, we need to study where we are now, we need to learn more about where we are now. So that's where some of these practices start fitting in to give us the knowledge that we can then use to start making some changes. So looking at things like entity mapping to understand more about the customer, some kind of demand analysis techniques to learn more about the work, value stream mapping to learn more about the process, and the three things I tend to look for, not exclusively, but these are the main three things, where do we have delays in the work?
Where are the key decision points? Where do we get knowledge that we're going to use to make decisions in the process? And where are the feedback loops, main feedback loops in the process? Either feedback loops which are good because we're getting knowledge from them or feedback loops that are negative ones that are causing rework. So understanding those three things helps us then, gives us some knowledge, gives us some information as to what can we start doing to improve. So two minutes again to answer this question. What could you do to learn more about your customers and stakeholder needs, the resultant demand and how that demand is processed? Thinking about what would you like to learn, what techniques might you use to learn and get that information. I'll give you two minutes again.
So let's imagine now you've done some
You've got some more information and you've got some really good knowledge about your current situation. What you want to do now is make sure you can share that, make sure everybody within your organisation, within your team has a common understanding. There's no point in you having an understanding but somebody else having a different understanding. So this is what I mean by sharing the information. So what information is it important to share? And how can tokens, the inscriptions on them, and the placements provide a single visual model? So this is really talking about visualization and Kanban boards. It's that aspect to it. I like to talk about it in terms of sharing because, to me, that's the underlying intent, creating this shared understanding. I've seen too many teams where the Kanban board is hidden under the desk or is hidden away in a fire escape. Or in one example I heard of was locked in the boss's office and you had to go and get permission and make an appointment to go in and look at it and change it. Not really creating a shared understanding.
So when you're designing boards and you're trying to create this shared understanding, what information is it that you want to share? There's lots of information out there. So I talk about these as being dimensions of the work, lots of dimensions. The work we do is multidimensional. Scope, time, cost, quality are the four. Points of the iron triangle. And then you've got all the other priority status capability and lots more, and there's probably other ones that I haven't even thought of. Different information is different to you. teams will want to share different information. If we try and share everything, we're just going to create noise. So what is it that you want to share, and then how are you going to convey that information? So this is where I talk about token inscription and placement. The token is the card or the post-it note or some other form which represents usually a piece of work. That's the token. And the token itself can then have multiple aspects to it. Size, colour, material. All those things can mean different things. So we can start mapping something like, let's say we're looking at demand and value demand. Value demand, failure demand. We can use colour to represent that. So we could use a green token to represent value demand, a red token to represent failure demand. So how can we use the token and the different aspects of a token to represent information? And then what information are we going to put on the token? That's the inscription. What words do we want to put on there? What dates? Initials? Avatars? People put little sticky dots or other little flags on there. Each of those then can be mapped onto a different useful piece of information. So who's working on it? Let's use an avatar and inscribe the token with an avatar. We want to track start and end date. Well, that makes sense to inscribe it onto the token. Let's do the start date in the lower left-hand corner. Let's do the end date in the lower right-hand corner. So creating some patterns and some... Commonality and standardization around the token design And then where are we going to place that card on our board and what information is that going to convey? So typically we have columns, we have swim lanes. So columns, and the most common is some form of status. But maybe it doesn't have to be. Swim lanes, maybe we'll use swim lanes to represent class of service, but they could represent something else. I've seen teams come up with bullseye type designs where actually instead of the work flowing left to right, the work flows from the outside in. So the placement on the board will also represent some form of information.
So you're now going to think about, given the information that you wanted to learn from studying, how might you choose that information? What information would you choose to share? And how would you represent that information using the token inscription placement model? So spend a couple of minutes on that, and then we'll move on to the next section.
So hopefully you now would have a visualization, a board, you've started to share the information. Now we want to start stabilizing our system. So I talk about having a stable system to make the distinction between the two extremes on either side of it. So if we have too much bureaucracy, too many rules, too tight constraints, then we end up with a brittle system. And as soon as something unexpected happens, the system's going to break. We don't want that. And at the other end, if we have no constraints and no rules, we have chaos. So we're trying to find a nice sweet spot in the middle where we have a stable system that can adapt to change. We have that flexibility, but doesn't break as soon as something unexpected happens. So this is why we use policies in Kanban. Policies are a way of creating some of those loose constraints and loose boundaries. And we want loose constraints with policies that we can simply update. So as we learn, and we use these policies as a baseline for improvement, as we learn unexpected things happen that we hadn't anticipated, we update the policies. And then the system remains stable. There are two main types of policies. Working process limits. They're effectively a policy type, and they're the key type of policy within Kanban. So if we're looking at policies, and the question here is what policies can help limit working process and remove unnecessary and unexpected delays or rework, you'd think about here, you need to think about what's your approach to WIP limits? Not necessarily what's the exact number going to be, but where in your system do you have too much work that you think it would be a good place to start reducing that amount of work? Where can you put WIP limits in place that are going to help you have flow? Are you going to have a single WIP limit across the whole system? Are you going to do WIP limits per individual column? Do you want to start limiting WIP by class of service? or other type of work.
All good things to talk about because it's going to help you create a stable system. And then policies are typically entry or exit policies. What does it mean to have clean work as it flows through the system? When is work ready to be pulled and to be worked on in the next stage in the process? Enter your exit policies, definition of ready and definition of done in Agile teams. That's effectively what you've got here, some simple policies or other form of quality criteria. So these sorts of policies are the ones that avoid the unnecessary rework really, trying to focus on quality so when the work flows through the system it doesn't have to go back, it doesn't get blocked and cause delays because there are problems.
So you're going to answer this question now. So what policies in your system for your problem do you think you need to put in place, work and process limits that are going to help you remove unnecessary or unexpected delays and rework? I'm going to actually, I'm running a little bit late, so I'm going to cut it down to a minute and a half this time.
So if we've now got a system in place and we've got some WIP limits and we've got some policies, we still don't really know how good we are, how good the system is, what's the capability of the system. So this is where we get into sensing. I like to use the word sensing because I think it conveys both the qualitative and the quantitative aspect of understanding how good we are, how good the system is. So this is what measures and meetings might we use that are going to create insights and guide decisions on potential interventions. How would you know how good we are? What information can we get against to help us learn more about how good we are that we can then use to start making some changes, running some experiments that we're going to get into next?
So when we're looking at measurements, this is when we can really start going back and thinking about when we talked about what impact we want to have. Given the impact we want to have on the system and some of those future stories that we imagined, what outcomes, we can now drill down and become a little bit more concrete, what outcomes might lead just to having that impact? So for outcomes, I'm talking about things like we want to become more predictable. If we have greater predictability, then we could probably have greater flow. Or if we have greater customer satisfaction, then we're probably delivering more value. So we can start thinking about specific outcomes that we can measure. And then thinking about what metrics can we start capturing that are going to tell us whether we're achieving those outcomes in order to have that impact. So we drill down from impacts and outcomes down into metrics. And this is building on work from Larry Mascheroni, a former colleague at Raleigh. He has what he calls the O-DIM. Way of working where you start with outcomes then you think about what decisions do I need to make to achieve those outcomes then to make those decisions I need some insights and to get those insights I need to have some metrics so working back to metrics from outcomes
And then also thinking about if we have these metrics, what behavior do we think that might drive? We hope. it's going to drive positive behavior, but probably we should think about what negative behavior it's going to drive as well, because then we can start thinking about what trade-offs we need to make. So if I want to have an impact on flow, and I think, well, to get good flow, probably a good outcome that will give me good flow would be more responsive.
So I have an outcome of being more responsive. The metric that I'm going to capture there is lead time.
Time between committing to taking on a request and delivering that request, what behaviours is that going to drive? Well, hopefully it's going to drive people to stop starting and start finishing and focus on getting work through the system more quickly, but maybe it's going to drive a negative behaviour of people cutting quality. Cutting corners and actually that's going to reduce my quality. So I need to be aware of those trade-offs but then that allows me to start thinking about a range of balancing metrics. So if I think that I might be putting quality at risk I can maybe start thinking about quality as another outcome I want to measure. How am I going to measure quality? Is that defects in the field or is it something, some metric I can get from customer service desks? And then you back into then what behaviours is that going to drive? And you end up with hopefully three, four, five balancing metrics, which you think are good metrics that are going to tell you how good your system is. How capable, it's going to give you a sense of your system. system capability. So that's very much the quantitative side of things. The qualitative side of then is our feedback cadence. So this is where feedback loops come in and typically feedback loops come in through our meetings. There's a whole range of meetings that we could put in place, scheduling, planning, reporting, reviewing, etc. And there's some other ones in there. So your daily stand-up meeting is a way of sensing on a daily basis how well you're doing. Is the work progressing in the way that you would like it to?
That's the thing with the time box, the Agile time box, is it's a really simple way of putting some feedback cadences in that pull in a lot of these ways of sensing capability.
But by understanding it in terms of sensing and feedback cadences, we can start decoupling these things and running them at different cadences.
So you're now going to have a quick conversation to answer this question. So what measures and meetings might create insights and guide your decisions on potential interventions? So I'll give you another minute and a half to talk about that, and then we'll get on to actually starting to make real change and start running some experiments.
So the fifth and final intervention, beginning with S, is search. So what we're getting into now is starting to run some experiments. We're searching the landscape around us, searching the evolutionary potential. There's no one right answer. There's no one perfect system design. What we want to do is have a look around us, try some different things out, and using some of the sensing techniques that we've just used, decide which ones are going to work well, and those ones that are working well we want to do more of, we want to amplify, and maybe some of them we'll discover are not going to work as well as we thought they would. So we want to dampen those down, we want to do less of those. So we want to run some small experiments, and what small experiments could be run to safely learn the impact of different interventions. So as we're trying different things out, we can use some of those measures that we've just talked about and use some of those feedback cadences to learn, are some good practices, some good techniques, Good or bad? Do we want to do more of them and less of them? One of the key phrases there is to safely learn. So we don't want to spend a lot of money, a lot of time, a lot of emotional energy potentially, putting something new in place, only discover that it's not the right thing. Because then we've wasted the money, we've wasted the time. and we've probably pissed our people off in the process. Not a good way of doing things. So we can make some lots of small experiments that we can get the feedback from quickly, learn quickly, and then decide whether we want to keep doing it or we want to back it off. So we're coming up with hypotheses. So there's a really little template there.
We think that if we make some change, it will improve some outcome because, and we have some rationale, so we want these experiments to be coherent. We're not just doing random things. But the three elements to that, what are we going to do?
What impact or what outcome do we think that's going to help us with and why?
How are we going to measure that? So we do need some way of measuring it to both validate the hypothesis or invalidate it and falsify it.
And then if we decide that we falsified it and it's an invalid hypothesis, how can we make sure that we can safely recover from that?
There's some techniques you can use. This is where you can start using things like A3 thinking, experiment sheets, to drill down into a little bit more detail and think through it. A3s and those sorts of templates work really well because, again, they just stop you jumping to conclusions. They kind of force you to, if you know Kainaman, engage your system too and think things through in a little bit more detail so that we can come up with some things that are not just impulsive reactions. So the last conversation then is thinking about everything you've talked about so far. If you're going to make some changes and make some interventions, what would your hypothesis be? What experiment might you run? How would you measure it to validate or invalidate it, and how would you make it safe? So I'll give you two minutes again on this one, and then we'll wrap up.
So we've just done a really rapid fly-through of using this model to think through how you would design a Kanban system, why you're designing a Kanban system. What I would normally do is print this out on a big A0 piece of paper, stick it on the wall, and then ideally spend a couple of days working through it, doing some deep dives into some of the practices, doing an actual value stream mapping exercise, coming up with an initial board design, coming up with some initial whip limits and policies, etc.
Just for the last couple of minutes, does anybody want to share any of the conversations that they had? Anybody want to grab the mic? Anybody feeling brave enough?
Or are we out of time?
One minute, okay. If you'd like to come and talk to me about some of the things you talked about, I'd love to hear it. Otherwise, you can download the canvas so that you can print it out big if you want to. Obviously, come talk to me if you'd like me to come in and facilitate a session with it. And there's another URL there. Otherwise, thank you very much.