Andy Carmichael
Transcript
If this is us, then we're a select group, and so do treat this as an interactive session and ask questions as we go. I'm going to talk about the Kanban test in... The litmus test in Kanban, which is really about what is the nature of the Kanban method and are people using it. So we'll talk a little bit about the motivation for that test coming into it. Just before that I want to do a little bit of a plug because some French colleagues have been working hard on translating this book which is Essential Kanban Condensed and if you'd like to download it
You can download it from Dropbox on this URL. So this is probably a 0.1 edition of the translation. We're looking for feedback from people. So if you'd like to do that, you can get this book on Amazon or also download it from this URL. And the French PDF will also be on this link. But for the moment, you can download it today from this link here.
L'essentiel sur cambins en condensé. How was that? Pretty bad. Yeah.
That's why I'm speaking in English today. I really apologize for that.
Okay, so enough on that.
I just have a few of those, so if anyone wants to give me 10 euros for those, that's cheaper than you can get them from Amazon.
But we don't have a store here.
Let us dive in.
Are you using Kanban, the acid test?
Is this... No, I shall just use a clicker.
So if you want to tweet, that's my Twitter handle. I've put it on there as well just because this slide will disappear. Um, And...
Here is a plug for the book again. So this is the free download. Get the PDF from there. You can distribute it freely through the company. If you'd like the physical books, obviously I encourage you to do that as well. They are available on Amazon. And the sort of cheapest price is a bit over 10 euros.
So if you'd like to have a look at those, there are some copies there. So we included the litmus test in the guide. And so the idea of the litmus test is a very simple way of looking at, okay, You've heard of Kanban, you've started putting stickies on the wall, you say you're using Kanban. Are you actually using the Kanban method? And encouraging people to go in deeper. There's the same reason, really, that I got involved with David Anderson on writing this guide, because...
I'm a relative newbie to Kanban. I went on, so I started getting involved with people using Kanban in 2012 and I did one of the training courses there and I went on David's masterclass in 2013, which is basically David Anderson talking for five days about all his thoughts, you know, sort of pouring out over it. So if you like that sort of stuff, and I happen to, That's a really good way to get behind the actual method, and it's not just a case of, okay, it's the same as what Toyota were doing in Kanban systems in production. It's not just sticking post-its on the wall. There's some thought behind this about a flexible way to define processes and to improve them continuously. Here's a test. Are you using Kanban?
I don't know if you know the origin of the test for measuring acid. You know, you put the paper in and if you've got a red one and it goes blue, then it is...
alkali and if you've got a blue one and it goes red then it's acid. It's a very simple test and actually it was invented by an alchemist in about 1300 AD. He discovered that this lichen on some stones has this property of changing colour when
when you add it to acid. So it's a very simple test to sort of try it in there. So that's the reason behind it, using that word. And what we're really looking at in using the Kanban test is to help organisations look at what they're doing with Kanban and saying, is this in any way getting into the depth of what the method is? I must watch the time because we are, I think, on a shorter... It would be helpful if someone can discover what time I'm meant to stop, but I think we're back on the ordinary schedule. So I'm aiming for half past.
So a lot of people start doing Kanban like this. Scrum is too complicated, it's got too many rules, it's got too many constraints. All I need to do is get my work on the wall, you can see what we're doing, the stuff that I'm to do, the stuff that's doing and then the stuff that gets done. And this is the way a lot of people start and say, well, Scrum's too complicated. complicated I'll use I'll use Kanban this is actually and if you're interested in Wikipedia I don't know what it's like in French but the the English pages for both Kanban and Kanban board are pretty poor and so get in there and make it better
and maybe think of a better example than this particular set of post-it notes which illustrates a Kanban board. So the other purpose of it is that maybe this will suggest areas where companies using a flow system, Kanban,
or other methods can look at ways to get improvements. Where are the areas you should look? And to provoke and challenge shallow implementations of the Kanban method so that we can actually move these things forward into more mature ideas.
So, I have a history of this. So, I went, as I say, I went to David's masterclass in 2013, basically with the purpose of saying, what is Kanban? I know what Scrum is because I can download the 16-page guide that tells me the rules of Scrum. And there's any number of books. In addition to that, but in those 16 pages, Ken Schwaber and Jeff Sutherland have explained what they mean by the rules of Scrum. And it's a very good method, and I agree with more or less everything in it. apart from the last sentence which says you can't change the rules. So apart from that, it's a very good starting point for a framework of the process that you're using to develop software.
Kanban has got a more general focus than that.
It's about knowledge work. How do we improve knowledge work? So there's not anything specific in terms of developing products or developing software that is part of it. So what is Kanban?
So in 2013, having gone to David's masterclass and listened to him talking for five days, I sort of think, okay, now I think I know what Kanban is. How could I summarize those five days? So I had a go on Twitter.
This was my attempt.
If you want to start using Kanban, you need to see your workers flow, you need to start from where you are, you need to make your work visible and your policies visible, and you need to make improvements validating them as you go. So that was my summary in the shortest possible. Can you do 140 characters in French? Try this out. What is your summary of how to start using Kanban? See flow, start here, with visible work and policies validate your improvements. Now, the interesting thing about these three steps is that two of them involve doing nothing.
C-Flow is just a different way of looking at the work that is going on in your organisation. Starting from here is the old joke. You ask the guy by the fence who's leaning over the fence, say, how do I get to where you're trying to get to, this village deep in the countryside. And so the farmer looks at you and he says, you can't actually get to that village from here.
Okay, you've got to start where you are. And so Kanban is also known as the start with what you do now process. So, okay, so I made it short, but that doesn't necessarily mean it's helpful. I've revisited this recently, and having done the summary in about 40 pages of the definition of the method,
Could we summarise the sort of three key elements of it, which are two sets of principles, the change management principles and the...
and the service delivery principles, and the six practices of Kanban. And also, these fit into tweets as well. So here's the first one, change management, start from here, agree to evolve, and lead everywhere by everyone.
Leadership is a key part of doing it. And the service principles you can go with, put the customer first, manage the work, not the workers, and evolve policies for outcomes.
And finally, the practices. You can look these up on Twitter if you... It's only recently I did this, so 10th of November, whatever.
The general practices of a Kanban process Make the process visual, make it whip limited, make it flow, make it explicit, make it responsive, that's talking about the feedback loops, and make it evolve.
That sort of Kanban as a starting point. So it's not surprising. People can start doing Kanban, as I said, without doing anything, by putting different glasses on and seeing their workers flow and starting from here and beginning to improve. You're doing Kanban if you're starting from there. Of course, the practices, the very first one is usually where people stop, make it visual.
the practices gradually come into play as you do that. And I think the other thing about this, and I think some of the things Jim Benson was saying this morning, that it's quite good to go slowly. It's quite good rather than saying, hang on a minute,
We tried Scrum for five years. We want to do something different. Let's scrap all that. We'll do a big analysis of what it is, and then we'll bring in a new process and call it Kanban. Actually, that's not terribly helpful. It's good to make small steps towards a better process. That is good that you can do Kanban without changing the world first. But when you are doing it or when you've done a little bit of it, as Jim was saying, the columns on the wall, particularly if you use sticky date for the columns and you get an artist to draw the... The names of the columns at the top, it becomes a bureaucracy that is difficult to change. So we've always got to be looking for ways to move on. And hopefully the litmus test is one of those ways that can help you move on, can challenge the status quo, can challenge the bureaucracy and say, Are we doing these things? Are we getting these benefits? And there are four questions. Here they are. When you are doing it, or when you've done a little bit of it, as Jim was saying, the columns on the wall, particularly if you use sticky date for the columns and you get an artist to draw the names of the columns at the top, it becomes a bureaucracy that is difficult to change. So we've always got to be looking for ways to move on. And hopefully the litmus test is one of those ways that can help you move on, can challenge the status quo, can challenge the bureaucracy and say, are we doing these things? Are we getting these benefits? And there are four questions. Here they are.
The first question is about management behaviour.
Not so much talking about misbehaviour or whatever, but is the way managers work in the organisation consistent with the principles of Kanban?
Has management behaviour changed to enable Kanban? The second one is about how we interact with customers. An important part of that is asking yourselves in the process where you're using Kanban, who is the customer? Who is my customer? Again, Jim mentioned it in the keynote. If people respond immediately and say, who's the customer? And they say he is, then we probably aren't really thinking about who are the beneficiaries of the service that we provide in our organisation? And what makes the service that we provide to them fit for the purpose that they have? I've sort of got another rule here when we're talking about customers, is if when you answer the question, when you get to the depths of why your group exists, why your department or your service or whatever your team,
if the people that you are serving are within your organisation, Carry on asking the question until you get outside the organisation, until you get to people that are benefiting from the services that your organisation gives, because that's key. We'll talk a little bit about optimising from a system point of view, but that's key to it. So customer, and the first question about customer is what's the interface with the customer? Has that changed because of Kanban?
The third question is, has the customer contract changed, informed by Cameron? So the problem with contract there is we think about written bits of paper and whatever. It's more about understanding what the customer needs from us and how they understand that interaction, having understood the interface, first of all, to the customer. How does that change and how is the agreement of what we deliver to them? And finally, has a service delivery business model changed to exploit Kanban? And that brings us into lots of other areas, focusing on value, focusing on what the purpose of the service is in terms of revenue generation or... Service to a particular sector or whatever it is. So I'm going to expand those four. That's the whole thing. I'm going to talk about each one in turn. So the first one is, has management behaviour changed to enable Kanban? So here's a little diagram. Diagram off the front of the book, where we drew the principles of Kanban in two groups. So if you're familiar with this, so in 2013 there were four principles, nice and easy. But when I was, the first meeting David and I had about this book was, I said to David, look, there's four principles in Kanban, but actually I think there's only three, because two of them say the same thing, which is start from here, not changing any roles or responsibilities of the people in your service, and start from here using the process that is actually practiced at the moment. They are both saying this, start from here, start from what you do now. And so those three principles, start from what you do, agree to pursue evolutionary change, encourage acts of leadership at every level, they are very much about how leadership can do. So Kanban succeeds when the managers in the process respect the Kanban system policies. You may notice if you're very observant, looking at this slide, that there is Kanban with a capital K on this slide and Kappa Kanban with a small k. So we have to make the distinction because unfortunately in 2007, I say unfortunately, I think it's not a bad name, but the method that we're talking about got named Kanban. Kanban is an existing word in Japanese. It means sign or visual signal or visual, a visual way of controlling a flow process used in Toyota systems since the 40s.
We are using systems like that in knowledge work in the Kanban method. So that's why there's sometimes Kanban with a capital K and sometimes Kanban with a small k.
The Kanban method, the Kanban community, the Kanban... Talking about those things, capital K, and Kanban boards, Kanban systems, Kanbans as the actual physical signals or virtual signals in a knowledge-based system that control work in progress.
So, back to the point, Kanban succeeds when managers respect the Kanban system policies, embrace customer focus, and manage in line with the service delivery principles, these things. And this is mainly about customer focus.
So we suggested from this framework a few supplementary questions. The first of which is, is management behaviour consistent with Kanban's deferred commitment and pull system approach? So this does mean that we've got to unpack some of these words and actually say what they mean.
The first one, deferred commitment. Is very important. If we want to have a system which flows, we don't want work to be pushed into that system on a random basis without consideration of can that request for a service be fulfilled. by the service itself.
I realise I'm using the word service an awful lot and in multiple different ways, but hopefully you can unpack that into, if you're translating this into your head in French, you're a cleverer person than I am.
So deferred commitment. So the first thing is that on a Kanban board, or at least in a Kanban system when we understand it, There's a point where work enters the system and a point where we say it's complete. That is the scope of this service from when we select items to be done and when we say they're complete.
In other words, the entry point and the exit point of the system needs to be understood. And within that, we need to limit the work in progress so that there is a predictable lead time, there's a predictable nature to the system.
The second thing Because whip limits are the main way that we use to achieve this predictable flow through the system itself,
we need to look at whip limits in terms of its system, not just in terms of limiting overburdening for the individuals in the process. This is one of the ways, again, Once people have got over the idea that Kanban is sticking post-its on a wall with what you're doing at the moment, the next step... Okay, we want to stop people multitasking. We want to limit what they do. And a good way to do that is to introduce this idea of avatars or maybe to have swim lanes per person where we can see what that person is doing. Have they got too much on their plate and therefore are they a bottleneck on too much parts of the process? So this is a good simple evolution from just getting the work visible.
But we call this a proto-Kanban system because it's not a system where the flow is looked at as a whole.
And particularly you can see when you use the, you know, I've got three avatars for each person here, so the maximum number of tickets that that person could be working on is three, it doesn't actually limit work in progress in this column here because there are a few cars that nobody's working on. So you can get work going into the system without people working on even though you are limiting it per person. So that's the first thing to get an understanding that the Kanban system is limiting work in progress as a system as a whole and getting management to understand that and actually support that all the way through. Otherwise, it's just seen as a way of making the work visible and then carry on pushing work into the system. Now, these kinds of systems... and Dave has classified a number of them called proto-Kanban systems. They are stepping stones on the way to a full Kanban system, and they are useful stepping stones to, you know, as you start visualising your work and understanding the policies that can... They make the work transparent, we can see what's going on, there's relief from overburdening in particular if we're using something like the Avatar system to reduce multitasking, there's potentially improved quality and better collaboration and greater empathy and so on, and improved levels of social capital through it. So it's valuable, we just don't want people to stop there. That's really the idea of the Kanban litmus test. Don't stop. Keep asking these questions, and then when you've asked them all, you've hopefully got the idea that there's more to do. So our next common proto-Kanban system is the team Kanban system, where you have a backlog, you have stuff in progress, and you have work being done. So this could be your product backlog and your sprint backlog and you're in progress and you're done.
Which is, if that's your system and that's your service, that's a fine way of managing it. When we actually put multiple scrum teams together, this is not the whole system. And that's where it becomes to be non-optimal in terms of looking at the end-to-end thing. So we are limiting, here's our commitment point here, and here's our done point here, our completion point. So all the work is controlled in terms of not putting too, not starting work that we can't finish, but we aren't controlling the queues here. In a larger system where there are multiple teams working, this can be problematic because we're getting these infinite queues coming in overall.
So, for example, there's multiple ways you can join Kanban systems together.
You can see this has been done on a board here where we've got a development team and a testing team. And the development team is looking at their process. They're limiting work in progress in their ongoing thing and they're putting completed work here. And the same with the testing team here. They have an input queue, they are limiting the work in progress until work is done. But that infinite queue in the middle is effectively meaning that we aren't controlling the work in progress over the whole system. So this really is a plea as you look at the systems, that you look at the whole scope of what is going on and you see...
Are we actually controlling the work in progress over the whole scope so that we get predictable throughput? and lead times.
So, yeah, I think I've covered that. So the third thing on management behaviour is, do we all understand, and from a manager's point of view, that we should focus on the customer? So is customer focus always an understood reason for change? And this relates to one of the other sides of this pillar, the values side and customer focus as a key part of the values in Kanban.
Focus on the customer, focus on making the service you provide fit for their purpose so things can improve.
The first thing, and this is actually one of the service delivery principles, focus on the work rather than the workers. Several people I've heard speaking yesterday and today talking about this need to not to keep people busy, but to look at the work flowing through a system so that the work receives attention at the right time. You've got to have some flexibility in there so that sometimes people are working for work to arrive rather than fully focused, fully engaged on previous work. At Lean Kanban Central Europe, Nicholas Modig was talking about a system for diagnosing children with ADHD. And the change that he was talking about is this change from keeping expensive resources like doctors and nurses and clinics and so on fully utilised, so that the work receives attention at the right time. You've got to have some flexibility in there so that sometimes people are working for work to arrive rather than fully focused, fully engaged on previous work. At Lean Kanban Central Europe, Nicholas Modig was talking about a system for diagnosing children with ADHD. And the change that he was talking about is this change from keeping expensive resources like doctors and nurses and clinics and so on fully utilised.
So that we don't waste any of their time because they don't have someone to work on. And changing that round to look at the process from the point of view of the patient, in this case a child being diagnosed with ADHD. The interesting thing when you do that and you focus on the work that you have to do and the stages the work goes through and you optimise for the patient, you also get better throughput, you also get a better delivery rate. So it's not all cost in focusing on the customer
and not focusing on the managers, on the workers, but effectively encouraging people to self-organise and to improve the way they work.
work and what are the blockages in the work itself. So those are three things and this management principle, we had discussions because it started off as number four and it's pretty obvious that needs to be number one because it's all about how we are looking to improve the way we work.
And to get that leadership at all levels going through the use of Kanban and allowing people to get that idea we want to continuously improve from where we are. So the second question in the litmus test is the interface with the customers. Has your customer interface changed in line with Kanban?
And what do we mean by this? Well, we're going to come back to this aspect of deferred commitment and flow systems and how we can actually stop work being pushed into a system and then blocking up the system and causing a worse service to be delivered as a result.
So the elements of this, we need deferred commitment, we need a replenishment strategy to schedule and service and select the work so that we maximise the value but also so that we don't start work that can't be completed within this thing. So that's a key aspect. So we're focusing on the customer interface, on the maximizing the flow of value and exploiting the constraints of the system. Maybe we're constrained in terms of resources, that's likely in the short term, at least in the short term. But there are other constraints that we can't change immediately. We work within that to find the best way to deliver service fit for purpose of the customer. So again, there's some supplementary questions to ask in this one. That's not a good colour for this screen, but it's a bit like the previous one I did. Requests come in here, we select some, we develop some, we accept them, and then they're complete. There's a little column over here which says released. So, is this a Kanban system? Small k. Well, not yet. We need to identify the commitment and delivery point. So we defined the scope of the system, and then we say this potentially is a Kanban system, provided we have some mechanism to limit the work in progress. And this is the most common way that we see... Kanban systems being defined in knowledge work with numbers here. So I sort of, this is a four, so it's red because you can't put any more. This is a six. This is a one.
I recommend this pattern, by the way, of using within... A part of your process that you've got ongoing and ready. There are different ways people indicate that work is is ready for the next stage of a process like this. Sometimes it's a marker or mark it as done in some way or have a done column. Sometimes there's a queue in between this which is shared, but you can push items from here to here because it's part of this process. What you don't want to do is to push it into the next stage because again you want each part of the process, particularly if it's an independent service of some kind or independent work,
We want that to be pulled into the next stage. So these guys have got capacity to pull these two tickets into the next stage of the process.
So a pull system with limited work in progress. And I think the other thing to say about whip limits is this is not a precise science. I see Don sitting at the back of the room and he's given us some pretty good science and maths around what kind of levels of whip limits give you the best balance between
throughput or delivery rate and lead time. No WIP limits gives you the problem that it's possible you're going to get a variation in demand, a lot of work arrives, it gets pushed into the system, and the throughput will collapse because of the congestion and dependency between too much work in progress. If you over-constrain a Kanban system and put very small, painful limits, you will get less throughput, or at least beyond a certain point you will get less throughput. Now sometimes you will hear coaches saying, that's a good thing, because it causes pain in the process. We're trying to get work done. We don't have anything to do because we're waiting on the next stage of the process. So these BAs defining all the requirements here can't push their work on here and then start on something else. So what do they do? You know, it's a frustration. Now, if we are encouraging collaboration, we're talking about it every time we get together at the stand-up or whatever, this fact, I haven't got anything to do at the moment, causes a discussion about how we can elaborate, how we can maybe break some of the, or support some of the parts of the process that are congested and do have too much work. If there is not collaboration going on here, those very tight whip limits will cause throughput to drop. Even though you're going to get a better lead time. So don't treat your whip limits as set in stone. I was reviewing a camber board the other day and beautifully laid out and post-it notes and good stuff as you expect to see. But I noticed that the whip limits had been drawn in and it was 3-3-3-3 across these columns. And they had been written in and never rubbed out, never questioned. Somebody said it would be a good idea if we had a whip limit on 3 in the development column here. And challenge that. You know, it's these points of pain when you think, what on earth do I do now because the whip limit says I can't work, that should cause some discussion. Again, if you went to Dimitar's workshop yesterday, he was actually simulating the effect of whip limits where there's low collaboration. And you can not only get a collapse in terms of, well, a collapse in terms of the throughput is going to happen if that takes place. So whip limits and collaboration need to go together. So, the second subliminal question on the customer interface things is, are the commitment and delivery points clearly defined and are we recording lead times and delivery rates? And this sounds like I want you to get into lots of graphs and collecting numbers and this is process magic, isn't it?
Really, this isn't hard. Tri McGuinness has recently published some spreadsheets which are really helpful in just, if you just collect the date items go into a Kanban system from the date they come out, you get a lot of information about what is going on, what's the variability in the process, what's the variability of demand and so on. It's not for the purpose of doing it in itself, it is for the purpose for knowing where to improve it. We see it feeds into the next stage in the Kanban. Limits test as well.
Here is what we mean by lead time. I've labelled it system lead time and that will become clear in a moment. So from the commitment point of your system to the delivery point of your system, you're capturing the lead times so that you understand where the bottlenecks are, what the kind of service that you can offer to customers is.
And what the variability is and so on. And the other fundamental that comes out of this is how much is being delivered, the delivery rate.
There are various ways in which you can display this data, but these are two of the most common ones, a scatter plot of lead times and a cumulative flow diagram, which sort of shows the entry into the system and the exit from the system. When you see very stripy cumulative flow diagrams, that may be useful to you, but in terms of just explaining what a cumulative flow diagram is, just plotting the entry point point, the commitment point on your system and the exit or delivery point in your system is a useful starting point. You can immediately see then what the work in progress is at any point in time and you can get indications of how this is changing, if WIP is increasing, what's happening to the lead times and so on. And the gradient of this line gives you the delivery rate or throughput.
I said I'd explain system lead time because this is about the customer interface and we need to consider what the customer experiences on lead time. And generally speaking we have a situation something like this. Here's the system that, you know, this is our team, this is what we're doing and we're very proud of the the lead time that we have with the system lead time within there from commitment point to delivery point this is what we do but what about the customer the customer when he makes a request expect some kind of service I've made the request I put it in on the on the website or I've asked for this feature or I've agreed with sales or whatever.
And so he is waiting from this point. We are counting from this point. And at the other end, here we are, we've done all the work. All that needs to be done now is the route to live. And here's the system lead time when we start work to when we deliver it is two weeks. It's ready to go. And the route to live is 16 weeks.
That we have to look at this whole thing in context. So this is about changing the customer interface. Has the customer interface changed to your service because you're using Kanban? And this is a lot about this end, first of all,
When a customer makes a request, does that mean you're going to work on it? Well, not if we're limiting work in progress. Just requesting something doesn't mean that we have capacity to fulfill that request. And we need to make that visible to the customer.
Us saying at this point that we have delivered work doesn't mean the customer has it. There's some point later when it actually goes live or when the live system turns on this feature they've asked for. So that doesn't cut it.
What we're looking for is something like this, where
The customer understands making a request is not the same as the service committing to deliver it. We have explained to the customer why we do this. This means we have predictable lead times that we can give you an SLA. an agreement of what kind of service we're going to provide. Why would a customer accept this?
You know, sort of, hang on a minute, I want a system, if I tell you I need this stuff, I need you to work on it. Why would the customer say, oh, this is going to be better, so I wait till you tell me you're going to do it. Is that good? Well, yes, it is if we are involving the customer in the process, if we're making this queue visible. And actually, really what we're doing is we are moving responsibility for this work into the customer's domain. I'll give you an analogy, which I hope is helpful in a moment. At the other end... What are we doing about the development team saying this stuff is done and the customer not getting it for 16 weeks? Well, we have to make this explicit. Now, in this case, I've shown this on a regular cadence rather than on a WIP limited element. But if we have a regular cadence of release, this is one way to limit the amount of work in progress overall, provided that however much stuff gets done,
on the point where this goes live, it's done on a regular cadence. It's not to say that we can, well, the main thing about this is we are not ignoring the customer experience in terms of when they get the service they've asked for.
A sushi restaurant and an ordinary restaurant. Was anyone here at the Barcelona Kanban Leadership event?
We had a little session drawing posters of how to explain Kanban to your grandmother.
If you're as old as me, that's a long time ago that I could have done that. But your mother, how do you explain Kanban to your mother?
Well, we came up with the idea of two restaurants, a sushi restaurant and an ordinary restaurant. And actually, the team that decided to do a motorway and actually showing all the mechanisms of getting flow on a motorway was a much better way of explaining Kanban. But I still think we came up with a good idea here, so I'm going to tell you anyway. leadership event.
We had a little session drawing posters of how to explain Kanban to your grandmother.
If you're as old as me, that's a long time ago that I could have done that. But your mother, how do you explain Kanban to your mother?
Well, we came up with the idea of two restaurants, a sushi restaurant and an ordinary restaurant. And actually the team that decided to do a motorway and actually showing all the mechanisms of getting flow on a motorway was a much better way of explaining Kanban. But I still think we came up with a good idea here, so I'm going to tell you anyway.
This is lunchtime. Paris is very good. I'm not going to use Paris because there's too many good places that you should queue and you should enjoy lunch. So in London, it's very important to get lunch quickly. And customers choose restaurants, yes, in terms of quality and what kind of food they're going to have and what they fancy and how long they've got. But also on speed and certainty of getting food in a certain thing. So just contrast the two processes in a sushi restaurant. When you get into the restaurant, you sit at the table and the food comes by. And within... A dozen plates passing you, the one you want is there and you take it and you eat it and you can eat as much as you like and then you go. And the chef at the end of the day is looking at which food is being eaten and he replaces those on the conveyor belt. Very good. When you go into an ordinary restaurant,
You've got a queue outside the door, but once you get into the door, you sit down at a table and you wait till the waitress comes and asks you what would you like to drink. And then you wait, depending on how long that takes in terms of making the drinks, till the drinks arrive. And then you're asked what would you like to eat. And there's another cue which you have no visibility of, the chef preparing that meal and bringing it to the table and serving it.
In other words, there are in... visible queues here which you can't see. This queue is visible. It's outside the door. These are both very popular restaurants. It's that once you get inside this one, the restaurant can tell you how long it's going to be before you get the five dishes you want.
That's, it's the queues are external and they're under the control of the customer. When the customer sees these two queues outside the restaurant, customer can decide, I think I really want to eat in this restaurant, so I will wait. I can see roughly how fast the queue is moving. Or not, or I can go to a sandwich bar and just get a sandwich. So it's making the queues visible. So that's really what we're trying to do in this process. This part of the process should be visible to the customer and to a certain extent under the customer's control because it's not under the service's control.
So this is really just to stress deferred commitment. There's no commitment on the restaurant to give you a meal until you get through the door. And then they're committed to giving you food. And most importantly, the customer's committed to eat the food. Okay, I know you can walk out. I know if you look at the menu and you hate it. Yeah, I've done that as well. But it's really embarrassing. So that doesn't happen too often. Once you get over the commitment point, you're both committed. to this contractor prepare and eat the food. Not necessarily eat it. Predictable customer lead time. So don't just think of it in terms of lead time. So we're still on number two.
I'm out of time.
And feedback is a key thing. So I'm going to move very quickly through the rest of it.
Customer contract is about, okay, we're collecting lead times and throughput rates and so on over time. We can now, because we're controlling the work in progress, so the process is more predictable, we can provide... An SLA or we can fulfill the customer's expectation in terms of lead time. Always understanding that we move the commitment point to a shared commitment point.
So we're focusing on, again, fitness for purpose. It can either be an explicit arrangement. This is why it says, you know, the customer contract has changed. It's very rarely a contract in my view, although sometimes it is. But we can make explicit... And probably probabilistic views of what the service that we can provide from this team. And if the customer has service level expectations, once I get inside the restaurant, I'm going to get food within a certain amount of time. So the commitments are based on agreed or understood levels.
Sorry, I'm going in the wrong direction. And we can, because we're capturing lead times and delivery rates, we can also use probabilistic forecasting. This is Troy McGinnis'spreadsheet. I think there's a reference at the end. Of
to actually be predictable in terms of what the customer is expecting from the service. Within the variability that is known, and it's again making this visible in terms of the expectations that the customer has for the level of service that they get.
And finally, has the service delivery business model changed as a result of Kanban to exploit Kanban? This is where we have a focus on value. So we have got a predictable system. We have got an understanding between the customer of a service and the deliverer of a service. There's a mutually agreed commitment point, and there's a predictable, within ranges of variability, there's a predictable rate that we can go through there. But we can also, we can go further in terms of exploiting some of the other aspects of Kanban, like classes of service, like capacity out. allocation and reservation, like demand shaping and differential pricing.
Differential pricing is an interesting one, but of course, if you have classes of service, we know that very often first class service costs more than second class service. So that's a common model in business and we can use that in service delivery.
The supplementary questions here.
First one, does the service business model use classes of service appropriately? So the idea of classes of service is sometimes confused in Kanban with types of work.
Very often there are different types of work that comes in, bug fixes and new features and big initiatives and small bets.
We need to distinguish between types of work if we're trying to analyse lead times and delivery rates because they will vary depending on the type of work you're doing. An emergency bug compared with a new feature which needs validation with the user community and so on. So make distinctions between the type of work, but you may attach different policies to the different types of work or to work with different costs of delay. And the idea of cost of service and the idea of these archetypes. Which came from David's Blue Book. So David's blue book was 2010, so he's been around a fair amount of time. So these are quite mature, but what I would encourage people is to look at the principle behind this in your context, not just to say every Kanban board has an expedite lane, for example. Generally speaking,
expedite lanes get put on Kanban systems because people have read it in Davisburg or seen these archetypes or whatever.
And yeah, when we get items where the delay, if we delay these things at all, we're going to get hit with very high costs. For example, the server is down and we can't take orders. You know, the whole revenue of the company is at risk here until we get that back up. Or if we don't release this by this date, we get fined by the regulator. Again, there's a very clear point at which the cost of delay changes. So these are useful to understand, but also to look in your context where you might design classes of service for the context you're doing. The danger with putting expedite lanes on Kanban systems is that the CEO comes in, sees an expedite lane, says, oh yeah, I've got this pet feature, I'd like it to go in the expedite lane. You need to have the discussions about why you have an expedite lane and what it's for and so on. So be careful before just taking this stuff on. And applying it. There's some other interesting stuff. that people have talked about in the Kanban community and are being used in various places.
And the general statement behind it is, is there capacity in the system to hedge risks from different sources of demand and different types of work? So do we use resources within the resources available to the service in different ways depending on the type of work coming in? For example, can resources be diverted to priority tasks during high periods of demand?
Let's just look at this. So, again, Don's at the back of the room. I went on Don's Costa Delay course this year. I thought since I'd already written part of the book on Costa Delay, I'd better talk to the source, which is very helpful. And we immediately did a second edition.
So... These are some of the things that in Don's course he talks about in terms of how we handle variability. Knowledge work is fundamentally dealing with variable work. It's not like a mechanized production line. So we need to expect variability and we also actually need to welcome variability. It's not something to eliminate from the process. But there are different ways that we can limit using WIP limits, using class of service, using different kinds of ways to limit WIP like con WIP, actually purging WIPs when we get
congestion collapse because there's too much work in progress, redefining the endpoint before the backlog is completed. The one that I wanted, rather than talk about that, I don't have time to talk about that, but we sort of covered it.
There's also another side in terms of exploiting this flow system, which is to think about how we deploy resources.
Again, we get stuck into thinking just one model. So bureaucratic systems with siloed departments where people do the same kind of work versus multidisciplinary cross-functional teams where you bring together people to solve a particular problem. Both those are valid.
In their context. And there are also variants that we can design given the constraints and the particular needs to deliver value to our customer. So the idea of resource pulling, where we can move resources to areas of high demand for resources, is like using BAs for testing.
We can...
We can ensure that we use the classes of service or the classification of the type of work we're doing, that we always include some intangible benefit work, which is interruptible in times of
high demand or whatever, and not loading services fully with planned work. We're doing portfolio planning in the bank that I'm working with at the moment, and the rule in that is that teams do not reserve work more than they don't reserve more than 50% of their time for the work that is being planned three months ahead. It turns out that that increases the throughput overall because we have slack in the system, because we don't just jam up. When we load teams fully, what you find is all the stuff at the end of the three months is not, you know, none of the stuff, sorry, has been done. And so not loading services fully with planned work is an important thing. T-SHEP people, you've probably heard this kind of idea where more experienced resources that have a broad range of skills but still have their specialisms.
Of a kind of very useful resource to have in teams. And by using people, rather than saying, okay, here's new work coming in, we put the most experienced person with the most range of skills on the first work that comes in. Those people are kept in, we use them as flexible experts, and we assign work generally. So this is more or less where I can see that I've overrun. And so I'll just put the summary slide up. And very quickly, are there any questions? That's it.
Any questions? I will put the slides on SlideShare.
There's my Twitter handle there if you want to contact me directly. And do download the French version of that and give your comments to Dimitri. He's coordinating that effort to have the physical book available as soon as possible. Thanks for your time.