Bio Karl Scotland is a Lean/Agile coach with 20 years of experience, a founding member of the Lean Systems Society and the Limited WIP Society, and a pioneer and advocate of using Kanban Systems. Download the Kanban Canvas here.
Every day, Agile practitioners and thought leaders are defining and refining new and existing practices that bring Agile’s values and principles to our world of work, play and service. Agile2014 reinforces our understanding of proven methods and illuminates some of the exciting new innovations that represent the future of Agile.
1. Thank you Karl for coming to have an interview with InfoQ at Agile 2014. Just very quickly to start this off, can you just tell me about yourself and also what’s brought you up to this point of the conference?
Sure, well I mean thank you for talking to me. I’ve not been to the conferences for a couple of years now, so it felt like a good time to come back to this great group of people here and having some great conversations, but also gives me an opportunity to get feedback on and explore some of the things I’m working on at the moment and particularly around the Kanban Space, so I’m a coach, I’m a consultant, I’ve recently gone independent, so setting up my own business, and one of the things I’m wanting to do is, a part of that is really develop the work and the ideas that’s been having around using Kanban with teams, helping organizations, design Kanban Systems and approaches to doing that.
Yes, so one of the things I’m going to be doing is doing a talk later on, introducing the Kanban Canvas, I have a copy here. So it’s a format which is trying to model the way I think about teams and Kanban Systems, so that I can help teams going through that process of figuring out what do we do. We are trying to solve a problem, we want to put a system in place, we want to improve our processes, what does that involve and taking the ideas that the Kanban movement has been working on and developing, in order to do that.
3. If we have to look at the diagram, so this will be downloadable on the site along side this interview, so if someone will download that, before they do, can you give us a quick explanation of the ideas behind this, so this is a summary?
Yes, so the idea is this, this will print out on A0 format, so print it out on a huge piece of paper that you can put on a wall or just have on the centre of a table and it becomes a format that people can collaborate around and co-create something, and the basic elements are that the central section here is understanding the system. So because we are defining and designing the Kanban System then we’re taking elements of Systems Thinking, understanding what is the problem we are trying to solve. And then there’s three arrows coming out of this, so when we solve the system problem, or we put that Kanban System in place, we want to have an impact, we want to have some way of understanding whether the things are getting better, but one of the principles behind this is not defining a specific outcome, so we are not going to go in and say: “This is what the end stage is going to look like”, but we can understand whether we are heading in the right direction. And I generally think about that in terms of flow, value and potential, so flow is the process getting better generally, value is ‘are we delivering better product’ and then potentially is this going to be sustainable and is it going to be adaptable over a long term.
So understanding whether we are going to make an impact, and there is some language there around fitness landscapes and fitness criteria and essentially: Is the system fit for purpose? And then there’s 5 arrows that feed into the system here and I call these interventions, so how are we going to interact with the system, what can we do with the system to understand it better, come up with ideas for improvements. So studying the system, getting knowledge about the system, starting to share our knowledge, share our understanding, putting some things in place which is going to stabilize the system, so that we can start improving it, sensing how well the system is working, sensing capabilities so that again we can start understanding are we getting better or worse, and then starting to search the landscape and search for the opportunities and run experiments. That’s the kind of the high level process that I take teams through. Having it printed on A0 paper means you capture all this information on sticky notes and all the context is there for you.
The results – well,the feedback has certainly been good, what seems to work nicely with it is, because it’s all on a piece of paper, so as you are working around it you can go back and cross reference and feedback and say: “Well, we think it will be useful to measure something here because it’ll tell us whether we’re increasing our potential” for example, or “we studied the system here, we captured some headlines around key points in our process and those are the things that we want to start visualizing and sharing here”. It’s also then become something that teams can take away and reference back, so: Why did we design our system this way and why did we make these decisions so we can go back and reference that, and my hope is, this is relatively new doing this way, my hope is that it becomes a continuing, almost a document or an artifact that we can keep going back to, as the systems evolves and we learn more because it’s going to change over time.
Somebody else has asked me exact question and my answer was, the problem that I’m trying to solve is how to solve problems, which is a bit of a recursive answer, but one of the things that I like about taking a Kanban approach, is that I have a way of thinking about systems and processes that allows me to solve problems. So instead of taking of out of the box solution and taking somebody else’s solution, I can design my own solution. But that is not going to happen by chance, so there are some structured ways that you can do this, so you are not going to be able to read this, but there is kind of small text here, these are questions, so each of these things is what I call a Heuristics, so the notion of Heuristics is something that we can use to help us solve a problem that hasn’t been solved before. I like the idea that the root of Heuristic is the same root as the word “eureka” and I like to say if you don’t have a eureka moment about something that you already knew. So each of these sections has a little question and what I’m helping teams do is answer those questions, I’m not giving them the answer but I’m giving them some questions so they can take away and figure out their own answers too. My hope and my intention in doing that, is that by answering their own questions they understand whether those answers come from and then as the situation changes, as the problem changes, as the context changes, they can then figure out new answers over time.
6. Can you take me through a little scenario perhaps where you’re dealing with the system, you’ll have an impact, just say in one of those areas, either flow or potential value, if that’s possible, and show how the input affected that. Is it possible just to take us through a very, very simple example?
So a system problem, a common system problem is maybe, predictability. So there’s somebody in an organization that is getting frustrated because they don’t know when they’re going to get their software, so maybe we could say that as a really simple system problem. One of the ways I answer this question is I like the Pixar Pitch, so it’s a little template format which says, once upon a time there was a situation, because of that situation every day something happened and then one day something different happened because of that, because of that, until finally. So the idea is that any Pixar Film animation you could fit into that format, so it might be that “Once upon the time there was an executive and every day he would ask the team: “When am I getting my software?” until one day the company went bust because the software never got delivered”, because of that ( there was probably a few, “because of that’s”), because of that the company went bust. And they I say, because of that we decided we need to put a Kanban System in place to help us improve. And then the until finally bit is, how do we want this story to end, we’re designing a Kanban System and we can think about, well I like teams to think about the impossibly good ending and the impossibly bad ending.
No, I’d start with the, what’s the story that let us to this point?
Katherine: Ok, so start with a story…
And then how do we want the story to finish?
Katherine: Ok, and is that in relation to the impact?
Yes. So the impact is the impossibly good impact and the impossibly bad impact, and the impossibly bad impact is sometimes what might go horribly wrong if we don’t make any changes. So actually the impossibly bad impact might be that the company goes bust, the impossibly good ending to the story might be that, the software is going delivered and we are doing continuous deployment every day and the stakeholders are now just getting continuous releases of highly valuable software and the organization is now able to respond to any change to the market and competition that they want. So those are probably sort of things that we’re now looking to aim for but it’s very much thinking about the direction rather than the impact isn’t that, we have a release case every month and we have this process, and a value stream looks like this and we are capturing these measures. Those are the things we want to do in order to help us have that impact.
Katherine: So we’ve established then in this scenario, the worst case and the best case through a story format.
And that’s just one way of doing it, it’s just a fun way of doing a better…..
So then we maybe start studying the system, so I think of that in three ways, so this kind of looking at this section, and looking at our customer and stakeholders, having some empathy, so we could do some empathy mapping with them to understand what their needs are, why they have those needs, we can do some demand analysis, demand profiling and looking at the nature of the work that we are doing and what can we learn from that and we can do something like value stream mapping of some variation of that to understand the processes that are going through. So I still think of those as interventions because there is usually some interaction with the system, we are getting knowledge. Then we move on to, maybe in this example were really interested in the workflow and sometimes we call it the knowledge discovery process, what are those key points in a process where there might be feedback loops or delays or decision points or batches, and there’s these things that we really want to make sure everybody understands so we start sharing that understanding; how do we take those pieces of information and visualize them?
So one of the other patterns I use is what I call token inscription placement, so we have a piece of information, a cue, how do we use maybe the tokens, the cards, different sizes, colors, materials to convey that information, or maybe it’s something that we inscribe on the card or an adornment or a dot or some way we use formatting on the card or maybe it’s the placement of the card, so for a cue quite often it’s everything that’s within a vertical column is the cue. So we are using the placement of the card to indicate a cue of work. So looking at some different visualization patterns and deciding we are going to use these visualization patterns to display this piece of information.
Katherine's full question: So just feeding back to you then this Kanban Canvas is more of a collaborative strategy document where we are looking at how we might go about looking at the system, having a view of the impacts of that system and then how we might change it, and so is this something that you would do specifically in a session so in a … similar to that of a retrospective or a planning session or would it be something that’s continual?
So I’ve typically done this in a 2 day workshop, so we spend a couple of days with a team working through this, so it’s very collaborative, it’s co-creation, it’s not one person going through this and saying: “Here is your system”, it’s let’s work together and make some collaborative decisions on this that we then have consensus over that we all agree with, we all understand why it’s that way. But the last piece is searching and experimentation, so let’s run some hypothesis and make some changes that we think that if we make this change to the process will get this result, well we can measure that in this way there are these steps that we need to go through, this is what validation of the experiment looks like, this is how we invalidate the experiment, so it would be something that falsify and it also need to be something that it’s safe and reversible, so as we learn that it’s not helping we should be able to back out of it very easily.
Katherine: So reflection and then projection and so on.
Yes, and in fact cadence is also part of this so when I’m talking about how can teams get a sense of that capability, have a sense of how well the system is performing, there are two aspects to that, one is just what metrics are we going to use but it also what meetings we are going to use. So schedulingmeetings, planning meetings, prioritization meetings, review meetings, demo meetings, learning meetings, retrospection meetings, all of these types of meetings that we recommend teams do, let’s make sure we understand which ones we are going to do, how often we are going to do them, so put in some policies around that, and one of those should be assessing the fitness of the system and how are our experiments are running and what new experiments do we want to try.
11. Ok, so back to the example that we are doing, I just wanted to clarify what sort of tool the Kanban Canvas is, back to it we got to the point where are we going to, we were studying the system and then we got to the point where we now were sharing?
So we’ve studied, we’ve maybe done part of that as a value stream mapping exercise, we’ve now visualized and shared the value stream in some way, now we want to maybe stabilize the work. So what working process limits might we want to put in place, and what strategies for that, are we going to have a single limit in the whole system or we are going to be limits by swim lanes, limits by columns, limits by work types; different approaches that are going to help us work on less stuff, focus on finishing work rather than starting work, that’s probably going to help us out, and what are the policies that we want to place, so if we have a number of stages in a process, what does it mean for a piece of work to be ready to moved from one stage to the next stage, so entry criteria, exit criteria, definitions of ready, definitions of done, quality criteria, lots of different languages that teams can use, but those are effectively of this is the way we are going to work as a baseline for improvement, so not this is the way we are going to work forever, but this is our understanding of what good quality work is and what it means for us to get work through the system effectively, let’s define that, let’s agree on that and it’s generally a set of check lists, just some simple bullet points, nothing heavy weight and then we make some, run some experiments on that.
So then we are moving into sensing and what measures are we going to put in place, what meetings we are going to put in place that we’ve just talked about, and effectively we’re now starting to get into defining experiments and then we go back and maybe say: “We think this policy here, this exit criteria, we need to add one or we don’t think that’s quite right, we need to take one away or we need to slightly change the wording on that”. So policy might be all code is unit tested or we have a code coverage policy of code coverage must to remain at 90%. Let’s run an experiment as well will happen if that’s only 80%....and that’s 95%, because we don’t know which is picking a number after the age and only that seems like a good number.
12. Picking up on the words that you said there, heavyweight, so I can imagine that some of these discussions can get quite involved and people might be getting a little bit obsessed about detail. So in utilizing something like the Kanban Canvas, what have you used or what advice can you give to ensure that you do just enough, or keep it lightweight enough?
One of the ways is just by having this as a single sheet of paper and bringing it back on sticky notes that fit in these gaps, there’s only a certain matter of information you put on that. Now you might do a deeper dive so going back to studying for doing a value stream mapping we might go off and do that on a white board or on a Post It note, but then when I’m looking at is, like what headlines do we want to get out of that, because there is a lot of information there, what are the key, the top three or top five things that we want to focus on and takes out of that. So when I talk to teams about sharing the information, I talk about the dimensions of the project, multidimensional, there are a lot of things that we could visualize scope, time, quality, dependencies, risks, people, deadlines. If we try and visualize everything, we’ll get information overload and by visualizing everything we are not really highlighting what’s important, so we need to decide “that stuff we don’t need to visualize, this is the important stuff to visualize”. So again I often start things by saying “just pick three to five, there to five things” and people kind of say, “three to five, oh can’t we have six, can’t we have seven?”, and I quite often let people go up to that but if we say like: “Lets visualize everything” it just becomes a mess.
Katherine's full question: I like the fact that you are using the physical limitation of the Canvas itself to keep it so focused. So you would advice people to keep focusing in on the headlines of things, yes? Would you recommend things like voting, the importance of certain suggestions, are there processes that you would use - like you mentioned moving out to do a value stream map, are there things that you would do with the team to decide between different options?
That tends to happen organically in that, I’ll break things out, so if I’ve got a team of ten people I can break that out into three little groups of three or four people each, so then each of those groups of people would then have a discussion as does each group want to take a different topic to work through and then we’ll come back and share that and we’ll do some, getting some consensus or merge stuff or theme stuff. So there is facilitation techniques, so sometimes when I’ll do.. if we are doing policies, we’ll have kind of three groups, we’ll have three sets of policies, each group takes a different policy and then we’ll rotate the people around the policies, so people are building on previous pieces of work. So essentially we are trying to get everybody’s voice in the room but across a broad spectrum of topics, but the topics that are important to the people in the room. So I’ve not really done any kind of dot voting or prioritisation but it’s certainly a technique that you could use. A lot of it is working with the people in the room and it’s different every time, you have to kind of go with the dynamic.
I was chatting with somebody, so one of the things that I’ve been doing with this as people download it, I’ve been contacting people and saying “if you are willing and able, I’m happy to have an hour on the phone with you or on a hang out with you, to talk you through it and get feedback”. So that’s my way of getting a feedback because this is just what I’ve done with it, and one of the people that I was talking to did say: “Well I’m an internal coach, I’m not going to be able to get people in the room for two days” and my answer was like: “Ok, go off and run your own experiments, I’m not precious about how people are using this”, I could imagine somebody using this as a, in some ways like you would use a traditional problem A3 where you work through it and then go and talk to people about it, this is what I think, get feedback on it and then you come back and you do another iteration on it, and so that might be using it, you might use it on this size piece of paper, or on an A3 where you are writing on it with pencil rather than using sticky notes. But still it’s there you are using it, getting the same principle of why A3s work because this is a simple piece of paper so it’s a simple communication and collaboration mechanism where you can go around and get the feedback and opinions from a number of different people. You are doing that individually asynchronously rather than getting people together in a room to do that. That’s not something that I’ve tried but I’d love somebody to try that and let me know how it works.
In the spirit of not defining outcomes I don’t know. I hope, I’d like to think that it has some impact and that impact is that people to take it and use it and are able to design systems with teams, and those teams themselves then have their own impact. So I’ve just making this available, it’s there for download, it’s creative commons license, it’s kind of a, I just want to put it out there for people to use. If people don’t download it then that’s good feedback for me, so it’s my own little experiment, are people going to download it, are people going to use it. At the moment people are downloading it, I’ve had , 4 or 5 hangouts with people over the course of just the first couple of weeks, so I’m in the process of… so I put together a pressie that talks through it and the order and some of the things we’ve talk about today that I’ll make available on the website. I’m going to write a little of how to guide and ultimately I’m writing a book and my vision at the moment is the book is going to be “Here is how to work through the Canvas” and it’ll go into some of the theories and principles and LIttle’s Law and Queuing theory, and maybe go into the details of how to do empathy mapping. One of the things I’d like to do with this is help people understand why certain practices work, so why do WIP limits work, because they stabilize the system, why would we use value stream mapping, because it helps us to study the system. All these practices are really useful, but if we just doing them because somebody just told us to do them and we don’t really understand what the intent and why they are valuable and how they all fit together, then we might just end up with a Frankenstein’s monster of a process.
Katherine: So it’s trying to inject a balanced way of dealing with the system, contextually driven.
Yes, so there is a whole lot of experience that is out there, so we want to help teams design their own processes and I don’t want to go in and tell people this is the right process for you, but equally I don’t want to leave teams just starting from reinventing the world from scratch, so that’s where the Heuristics is come into this, Heuristics are some things based on our experience, we can give some guidance on how to help people, here are some useful things you might want to consider but I’m not going to give you the answer.
Katherine: Excellent, I look forward to the book, thank you!