Kanban is a Tool for Continuous Improvement

Transcript

Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Todd Little. Todd is the Chairman of Kanban University and I'll ask him to tell us a bit more. So Todd, you and I have known each other a while, but I'm going to guess a fair number of our audience haven't come across you before. So who's Todd?

Introductions [00:25]

Todd Little: So who am I? So Todd Little. I've been somebody who's been an agile practitioner for a while. Accidental agileist, I would say. I got involved in agility really partially just because it was a natural way of working for me. I had been looking around. My background's actually chemical and petroleum engineering and I was developing software for oil and gas exploration and development. Really interesting stuff. And doing that, and as I got into more and more management roles, started thinking how can I get better in our software development? And started looking around and seeing all these things that didn't really make sense to me. A lot of structured approaches and being an engineer, I understand structured approaches, but they weren't making sense from a software world perspective. And so I started looking around, ran into Jim Highsmith in the late 1990s and saw what he was doing with adaptive software development and complex adaptive systems.

And at the same time, I had been involved with my company Landmark Graphics, in putting together a developer conference, a worldwide developer conference for our 700 developers. And in that process started bringing in some people and getting connected in with people that were doing interesting things. So Jim Highsmith one year, Kent Beck one year. Then I went to a Cutter Conference where Jim Highsmith was organizing it and ran into a number of the people. Ken Beck was there and a couple other people, Tom DeMarco, Tim Lister that I had worked with before as well. And then Alistair Cockburn showed that he was developing a conference, he was going to be developing an agile conference and that's how I got really into the agile community was through that. Since I had organized conferences and Alistair was running a conference, he and I, 20 years ago ran the first agile development conference in Salt Lake City, the first conference of the Agile Alliance. And so I ended up running that by myself a couple of years after that. So got involved in the Agile Alliance Board, sort of connected into the agile community in that way.

And meanwhile I was still doing my day job, trying to develop software in the oil and gas space. Eventually through the process I came to know David Anderson fairly well. As we were starting the Agile Leadership Network, he and I were involved in getting that kicked off. So I knew what he was doing in the Kanban space and eventually decided, well maybe I should get into the agile space full-time. And that's where I got into Kanban University about 6 years ago, 2017. So been sort of really trying to promote agility and reach out to what people really need. And I think that's what I really love about the Kanban world is that we really try to look, and it's all about improving the delivery of knowledge work and techniques for doing that and broadly. And so it's a very natural approach that I see, been doing and really trying to grow that message out in the Kanban space over the last few years.

Shane Hastie: But isn't Kanban just a board on a wall.

Todd Little: Kanban is a way of working that continuously improves through evolutionary change

Well, a lot of people think they're doing Kanban because it comes with their Jira board, it's an option and others think, well, maybe it's just a bunch of stickies. The Kanban method is really quite a bit more than that. From the very beginning, a large element about Kanban is the evolutionary improvement, the approach to evolutionary development of your approach starting with what you do now. So it's not something that you install, it's not a transformation. Kanban is a way of working that continuously improves through evolutionary change. And yes, it includes visualization. Visualization is a very important element. There's a lot that we gain from visualization. There's a lot we gain from metrics.

But there's a lot even more that we gain from small experimental change, understanding how to build those experiments, how to deal with resistance and using that to continuously improve. We see a lot of agile implementations that stall out because they don't really get good at continuous improvement. They follow the book but they don't know how to get beyond that. They don't know the basics foundation, they don't know the techniques for really getting better, and as a result they stall and fail to get any continuous improvement. The Kanban method is all about how do you get better? How do you get a basic foundation of continuous improvement? I think that's really what helps people thrive in this space.

Shane Hastie: Where do we start?

Start with what you do now [04:19]

Todd Little: That's the thing with Kanban is you start with what you do now, and not what you say you do, but what you actually do. And so we spend some time really to put some effort into really understanding what it is that you do, how is things working now? And then we'd also look at where are the pain points? Where are you having challenges? Where are your resistance? Where are you having resistance? Why are those pain points persisting? And from that, that's how we can get a better understanding of what we can do about it. For the formula for us is understanding where the pain is, what's the stressor, what's the stressor that's potentially there? Then we have reflection. Could be a retrospective, could just be any form of reflection that says, "Okay, now that I see where the pain is, now I'm going to do something about it." And that's an active leadership. Taking the active leadership is the closure of the feedback loop that says, "Okay, I see something I don't like, I'm going to do something about it and let's go improve on it."

And that formula, that foundational formula is something that you can really continue to build on and get really good at and get good at understanding the diagnostics. So the pains get good at understanding where the resistance is, and then empowering people to take those acts of leadership to make a difference about it.

Shane Hastie: So in order to take those acts of leadership though, don't I have to be a leader?

Leadership happens at all levels [05:34]

Todd Little: No, it's at all levels. Leadership comes at all levels. It can be very, very small changes. And that's one of the things that when I've been involved in really effective and successful agile implementations, it always happens when there's acts of leadership coming at all levels, developers stepping up and saying, "This is sort of foolish for us to be doing this, this way. Couldn't we be doing it differently?" And they can be very small changes. Someone stepping up and saying, "Well, we could be changing our test approach this way. We could be managing our dependencies in a different way. We could be eliminating some dependencies. We can do all these different things that are ... We know these things are continuously bothering us. Why do we continue doing them?" It's the team stepping up. It can be ... Many times, it might be someone who has a leadership role taking those acts of leadership or maybe it's someone who is a leader just making the place safe for others to step up. But the success happens when those acts of leadership happen throughout the organization.

Shane Hastie: So that's some of the background. How does Kanban feel? How's it look? How's it work? Start where we're at, understand our current state of work, then what?

Understand how work flows in and across teams [06:40]

Todd Little: Yeah, so the other element is trying to understand what are the services that we're delivering? And so many times, services will be a team will have a service, but also the service will be made up as a network of services. There'll be multiple teams coming together on a single project or a single product or service delivery, and trying to really understand how is the work flowing. So we look at how does the work flow and based on how work flows that insight into how work flows often will show us where we're having challenges. Where are we having bottlenecks, where are we having delays, where are we having points of frustration? It may not be delays, but it may be frustration. We want to eliminate this frustration just as much as we want to eliminate the delays because the frustrations manifest themselves in other ways and turn into other problems.

So we're looking for all sorts of challenges and we utilize a number of different techniques. We can utilize an approach called static, which is the systems thinking approach to introducing Kanban as a way of really identifying those pain points and powers, the work flowing and the steps. We can also take similar types of approach, just identifying where are the pains, and just on a simple basis, where are the pains and what might we do about those pains? And then also looking at where might we see sources of resistance? When we have sources of resistance, one of the approaches at Kanban we talk about is to be like water. Just like Bruce Lee used to talk about being like water in martial arts. And the point of being like water is that water turns into its container. So when you put water in a cup, the water becomes the cup.

And I think that's one of the challenges that agile implementations have. The agile implementations say, "Oh, well we can't do agile unless we change the culture." And I think the Kanban way approaches this is more that we adjust our approach based on the culture rather than trying to change the culture to adjust to our approach. And that's a big change and also a much more humane change because trying to change culture is really challenging. And so instead what we do is we say, we adapt to culture, figure out what you're doing now, figure out how that's working, looking at that resistance and then saying what can we do realizing that resistance is there? Do we work around the resistance? Usually that's the best answer. Just like water flows, water flows around rocks, it doesn't knock the boulders over unless it's the time for that to happen.

And so we work in a way where we work and identify the resistance, flow around the resistance and at appropriate times we will actually work to remove the resistance. But that's not usually our first wave of operation. Our first wave of operation is to try to adjust to the resistance, work around it, and we've seen miracles happen by doing that, going at it small bits at a time. We eat the elephant a little bit at a time, and eventually we've made some incredible changes, many times, much faster than expected. We've seen some substantial changes using just incremental change within a couple of months, having just amazing turnarounds.

Shane Hastie: Meeting people where they're at, working around the resistance. One of the things that I certainly see out in the community and in our interactions is what I think is possibly a fair amount of confusion between Kanban as an approach and Scrum as an approach. How do they overlap or how are they different?

Using Kanban to make Scrum better [09:59]

Todd Little: Yeah, that's great. In fact, one of the things that we have just come out with is a new class called Scrum Better With Kanban. And the idea of that is that as we say, if Kanban is starting with what you do now, if what you're doing now is some form of Scrum, then use that as your start point. There's a big talk about agile transformations. We're in a transformation. Kanban is not a transformation. Kanban is an incremental approach of evolutionary change, which can be transformational. And that, we see. We see transformational results, but it's not a transformation, it's not a noun, it's not something you install. So what we do is we work with what you're doing with Scrum and we start looking at where are your challenges? What's working for you? What's not? If it's working for you, we're not going to change it. And the thing with Kanban, Kanban is a set of tools, set of practices and principles that we have known and applied to knowledge work, not just in IT but also in multiple industries, in a way that really does work to improve your knowledge delivery, your service delivery.

So this new class that we offer Scrum Better With Kanban acknowledges that. It acknowledges you're working with Scrum, you might have a corporate mandate to use Scrum, you might be happy with what you're successful so far. But maybe you've stalled out, maybe you've hit some limits or you've got some pain points still. And we've seen these regular, and a good percentage of people that come into the Kanban world have started from Scrum, and that's what we see from our state of the Kanban report. But we also see that those people that come in are seeing some substantial results. 87% of our respondents have reported that they see the work they're doing at Kanban is significantly better or significantly better than previous approaches. So they're getting great results and they're doing so through incremental change.

So it could be they're having challenges with unplanned work. It could be they're having trouble with predictability. It could be that they're having challenges with dependencies. All of these things are approaches that we give them tools to work with from the Kanban perspective. Looking at their flow, looking at how work is flowing, getting back to first principles of flow. I think that's one of the challenges that practitioners have when they're handed a framework, they're handed a framework and say, "Go implement this framework." Well, if they don't actually understand the foundational basis of the framework, why did the framework even exist? What set it up? Then they don't necessarily know how to improve it. They don't have the basis for that. They know how to do the things, they know how to do the events and they can do that very well, but they're not necessarily getting the results, and that's because they don't know how to understand the flow of the work and they don't know how to improve it.

Those are the two things we've really hit when we started interviewing people as to where their challenges were and it came down to really getting to understanding flow and predictability and dealing with resistance. And those are really what we know, having narrowed it down to those things, these are the things we know we handle very well in the Kanban world. These are not challenges. People who really understand Kanban well know how to deal with flow because we understand the metrics, we understand the behavior of flow quite well and teach the tools to do that. And then dealing with resistance is something that's sort of core to our evolutionary change approach. We take small bites, we work through and identify the resistance, work around it, and only at the last resort do we really try to blow up the system to change it if it's necessary. So we work through that.

Shane Hastie: You mentioned metrics a number of times. If I'm a team lead in a software engineering team, what are the metrics that I should be caring about and how do we know whether they're doing okay?

Actionable metrics and visualizations [13:26]

Todd Little: So it's always contextual, although I think we know that there are several metrics which we recommend as sort of a standard set. We always like to look at lead time and lead time is something that always has to have a clarification as to what's measured from. Is it measured from when we start the work until it's done? Or is it measured from when the request was made until it's done? But any event, as long as we're consistent and we know what we're looking at, the lead time is something that we find can be very valuable because it gives us an indication of the history and the expected behavior of the system. So knowing what historical data is is far more valuable we find than trying to estimate it. Trying to estimate it without that history is really ... I think it's wishful thinking, but when we actually have real data, then we can actually make numerical calculations, at least get an indication.

If we know historically that items are taking us somewhere between 5 and 20 days, then that's good. We don't want to be promising it's going to be done in three days. 5 and 20 is a number. We don't want to necessarily promise five. We need to establish what that looks like and have the basis for understanding that. And if we have that data and collect it, then we have the ability to make some decisions around it. So lead time is something we really value.

We also like to look at run charts. So run charts give us that lead time over time, so it lets us know whether it's trending or not. If the numbers are getting higher, lead times are growing on us, then we know that our system is potentially getting worse. Perhaps it's getting more bottleneck, getting blocked in some fashion, but any event that gives us an indication of getting better or worse through the run chart.

And then we also like to look at the cumulative flow diagram. The cumulative flow diagram is a tool that gives us a number of things collected together on one chart that tells us how are things flowing through the system, through the various stages of workflow.

So those three sort of become the core that we look at and there are plenty more that can be looked at, but I always caution not to take on too much too fast. People wanting to come up with a number of metrics, they want get everything across, but there are other assumptions. Flow efficiency is a number that might be useful. We're trying to look at how often is work actually being worked on and how long is it sitting in queue just waiting there? And in many organizations that flow efficiency number can be quite low, in the single digits, less than 10% is not unusual for organizations that are struggling with that type of problem. And so if that is the type of challenge they have, then there are techniques for looking at, well, how do we improve flow efficiency? Why is that? Usually it's wait time. Usually there's communication challenges. Oftentimes the problem is they're overloaded, they've just taken on too much work.

Limit work in progress to make flow more predictable [16:00]

And so one of the premises of the Kanban method is to limit work in progress. And that's not to limit flow. We limit work in progress in order to make flow more predictable and more consistent. And so the irony is that many times managers will think, "Well, in order to get the most done, I have to make sure everyone's busy." Kanban takes the approach of not making sure that everyone's busy, but making sure that work is flowing. And in order to make work flowing, many times people aren't 100% busy. It's the counterintuitive, but actually works out quite cleanly when you look at it. And so we look at what is far more important for us to see workflow than to create a lot of inventory of work that's in progress but not completed.

Shane Hastie: You mentioned some managers have a challenge with this and I can understand why. They're often incentivized on the efficiency of their teams, having people working a lot.

Maximizing flow requires letting go of utilization as a goal [16:51]

Todd Little: Yeah, so utilization that is one of the challenges is that historical incentive is utilization. It's particularly a challenge in service organizations where their consulting business is billing out people, they want to make sure people are utilized because that's how they make money. And so that is one of those sources of resistance that may be always there. And then you have to work out how do you deal with it? Oftentimes the type of problem we have to look at is when you have a challenge like that, where the motivation is counter to the desire is what can we do with a higher goal that will help show that? So if the higher goal is actually we can replace the goal of utilization with the goal of customer satisfaction. Customer satisfaction, customers don't care how utilized your company is. They care how good your product is and how smoothly their delivery of their services that they're requesting of you.

And so that's the things that we try to do is replace some bad behavior with some higher value, that is actually seen in the organization. And those are some things that may take time to change because they're so ingrained in our thinking, we're trained in the idea, go back to The Goal from Elliot Goldrat and challenge.  He thought his goal was to optimize his utilization of all of his equipment. But in fact, the goal is actually to streamline the flow so that you have the most output and can meet the most customer demand. And that does not come from over utilization. It comes from understanding the system and building an environment where flow is smooth.

Shane Hastie: One of the challenges that I certainly see to this is the organization level incentives. The individual bonus for instance, where the more people you utilize, the better they get paid.

Incentive systems often get in the way [18:31]

Todd Little: Exactly. There are many times where we have to look at that and see how that's behaving because many times, organizations are not aware of how their incentive programs are actually driving behavior that's counter to what's beneficial to their best interest. Deming was very adamant in his 14 points about the challenges that many programs, particularly he was adamant that MBO programs, management by objectives, needed to be eliminated immediately because it was just backwards and that individual reviews were also to be abolished. The thing is that many times there's no ways to remove all of those things, so we have to nibble away at them and work through and find ways to coexist with the system. So what we find is that the key is really understanding the lay of the land, and understanding that yes, we want to work towards an environment where we're really focused on flow, focused on getting things through and satisfying customers. Yet we might be facing cultural biases, cultural basis that takes us in the wrong direction.

When we have that, that's where we need to be like water. We need to be like water and try to flow around those barriers, those cultural barriers. Occasionally you can nudge those cultural biases into another direction. Usually these things are emotionally attached because history has them emotionally attached. This is what I was taught, it's not based in any actual real theory, it's just based on some belief system, really. Belief systems are always emotionally attached. And so coming up with an emotional change to get people to think differently, it's not easy. It needs to come from a higher emotional. So that's why we try to drive towards purpose and other realities of bringing the customer perspective into this. And if we can get to that point, what it really takes in order to drive that type of behavior.

My background is predominantly in product organizations, and product organizations, I find that this is less of an issue because product organizations inherently have the feedback loop. If they're successful, people buy it. They also have a lot of customer feedback. I see these challenges being greater in organizations that are internal services to ... So IT relative to the business, they don't have those feedback loops. Those feedback loops are disconnected. And so that's where some of this bad behavior comes from. And to the extent possible, if you can bring the missing feedback loops into that behavior, the business people see it, the business people see that they're not getting what they want. Now their belief might be, well, the reason I'm not getting it is because people aren't busy, but this is where you need to help them understand it. So work them through it, in fact, the reason you're not seeing it isn't because people aren't busy. Usually people are overly busy with these situations, but they're busy on so many different things that nothing gets done. Nothing's actually making it out the way.

I had this situation, so in the company I was with, one time, I was dealing with our internal IT division that was responsible for provision of servers. And we had a situation where ... So there was four of us that were VPs that were working with this group and we would put requests in and the service requester thought that her job was to make sure that whatever we requested got started. So in the end there would be 100 items started, but nothing would ever get done. And so we had to work and restructure things and we used a Kanban approach to it where we had only a max limit of 10 items. And so instead of 100 items getting started, only 10 items could get started. And it worked out really well because things were getting done. And many times of the list of 100 items that were in the queue, half of them no longer meant anything. So they shouldn't have been worked on after a few months. They should have been killed. But no one had any feedback loop to let that happen.

So this way we only had things going into the queue that actually were going to get worked on and rather than things taking a year to get done, were getting done in less than a month. It's still probably too long. But that was a huge start and we kept getting better at it and started optimizing. And once you have the lay of the land where you're starting to get flow, that's when you can start having fun because that's when you can start optimizing it and start looking at how do we get things done even better? But when you don't have any structure around it, you don't know how things are flowing through the system. I mean, each individual functional group was doing their part, but they were handing it off and things were laying in the queues forever. Then we started having this flow-based approach to it and things were actually working because that was all that we had to work on. And that's when you start seeing results.

Shane Hastie: Good examples and some really interesting content here. Todd, if people want to continue the conversation, where do they find you?

Todd Little: So kanban.university is a great place. If they want to reach out to me directly, feel free to reach out to me on LinkedIn and have a conversation. But Kanban University, we have a number of trainers globally, over 350 trainers in our network that are delivering classes. The baseline class team Kanban practitioner, and then go into our Kanban systems design and Kanban systems improvement. But we also have this new class called Scrum Better With Kanban, we're very excited about because it's really coming in and targeting some of the known challenges, which we see from those that are implementing Scrum and SAFe. They're stalling out, they've gotten some improvements, but they really aren't seeing all the things they'd like to.

And this is where they may already be using a bit of Kanban and this is their opportunity to really learn the basics of Kanban applied in a Scrum environment, what are some of the challenges we've seen from others and what are the approaches we've used in helping those? And then we end up solving their problem directly. We have them look at the areas where they're having challenges and the last half of the class really focuses on them doing the work themselves and we guide them through that. So lots of things going on in the world of Kanban. I think it's very exciting and I think it's exciting overall in the agile space. So feel free to reach out to us and ask us what's up, what we can do to help you.

Shane Hastie: Thank you so very much.

Todd Little: Thank you, Shane.

Mentioned

• Kanban University