 Welcome to this session in Agile India 2021 by Todd and Joy on Resilience and Agility through Evolutionary Change and the Kanban Majority Model. Very excited to hear what Todd and Joy have to say. So over to you, Todd and Joy. Well, thank you. So I'm Todd Little. I'm Chairman of Kanban University. I'm joined today by Joey Spooner, who's Vice President of Agility, Community and Product Development for Kanban University. So today we're going to talk about Kanban and how it works through evolutionary change and the Kanban Majority Model. So first of all, we're talking about resilience or agility. We're talking about agility. Agility is our ability to change direction. And that's great. That's what we need in times that are tough like that we've been through. We need the ability to change direction. But we also need something else. We need resilience. And resilience is our ability to recover from adversity. And certainly that's something that we've been facing. This is what the Kanban Model, Kanban Method does. It addresses both of these questions quite well. But what is Kanban? A lot of people think Kanban is a bunch of stickies on the wall. Simple to do in progress down a visual management technique. But Kanban is much more than that. What Kanban is, from our perspective, is a tool for evolutionary change in managing knowledge work, teaching organizations how to understand, visualize and measure their systems of work to continually improve and consistently deliver results. It's a proven set of practices that scale from individuals and teams to the enterprise. How is that different from traditional change? Traditional transformation is often an A to B process. We start with a current state and we map out a future state. And then we have this thing called transformation. There are a couple of problems with this approach. Two big problems. One is that in order to do this, essentially, we need to know the future process in advance. We need to know all the details of it. It's not an emergent process, but rather a design process. And effectively, this is a big bang, a big design up front approach. And it's strange that so many agile transformations are done in this big bang design up front approach when we know from agility that big design up front doesn't work. There's a second problem with this, and that is that we are going through our dealing with people. So people go through changes. People in organizations go through changes in different ways. Joey, events? Yeah. Sorry, here we go. So in light of that, you know, what Taj is just talking about is how people resist change, but they don't resist change necessarily. They resist being changed. So when we look at it from the Combine University perspective, what we find is really people need a human approach to change. And this really comes around in the idea that change that is evolutionary in nature is actually really humane. So the idea of changing little by little piece by piece is what we're talking about here. And when we think about this, there are a couple of factors that we consider. The current state, which is kind of where you are today. So start with where you are now as a big principle for us of how we change. Where are you? And the goal is to say we're going to look at a future path, but oftentimes that future state is not that linear. We'd love it to be a straight line. That kind of is what typically happens in a lot of planned transformations, but that's not what we find when we use the Kanban method. What we find are or find is, is actually a change in the current state of the future state. And oftentimes there's a change in a level of safety, which is lost because you're now introducing something new. And at the same time, a change in patience. There's a tolerance for how long people are willing to wait for this change to take place. So these are two factors you think about when we're considering change overall. And when we consider it with evolutionary change, we tend to take a little different approach. But to note one thing in particular, this lower maturity approach here of having a big change going through a big transformation or something else usually puts the organizations under a good load of stress. And it's something recently I tweeted about the friend of mine. It's a very common thing that seems to occur because of the duration and the effort put in place for transformations. We don't necessarily do that with the Kanban method. What we look at instead is something a little different. Now, just to note, we have only about 18% success here with these kinds of big transformations, about 18% failure, and about 64% are moderately effective. And this comes from the PMI Institute's organizational change management research. So in light of that, this is how we look at it from the Kanban University perspective with evolutionary change. We tend to look at the idea that we're going to do small changes over time to really evolve and find the right path to actually become transformed versus the typical approach of one very big large change that could take quite a bit of time. So here we're looking for small learning processes, learning changes that will make to improve the overall outcome in terms of change. So start with where you are and evolve. And this is where we come from the Kanban maturity model. This is the roadmap to evolutionary change. This is work done by David Anderson and Theodore Bozo. They came up first with their book a few years back and they've come up with the second edition now and this codifies approximately 150 Kanban practices that we've observed over the past 10 years and how those practices are used in daring degrees of maturity within organizations. We focus on observable outcomes. It's not so much the practices. This is not a conformance to practice that we look at is what are the outcomes that we're looking for. If we're getting those outcomes, if we are, then great. If we're not getting those outcomes, then we want to look back and say what what helps us drive those outcomes. And it's a combination of culture and practices that help us understand what are the next practices that are appropriate given the level of maturity we're at within our organization. The Kanban maturity model is trying to eliminate two of the common failure modes we see in Kanban, Agile, really almost any type of transformation. Two common problems are number one, overreaching. So overreaching tries to take on an aborted start. We try to do too much and by doing too much the organization is not ready for that and it results in an aborted start. The second one is a whole summit plateau. It's getting to a certain point realizing some benefit and feeling like that's good enough for us when in fact there's significantly more benefit available to the organization or to the team. So if you look at this back on our jaker, what does overreaching and plateauing look like? Well overreaching is taking on too big of a change. It's taking on too big of a change and putting ourselves at very risk, risky situation of not being able to actually bring the organization to a point where it can realize the results that it's intending. The second one is plateauing and that's where we get out of the hump. We say, oh, success with this transformation. It was so painful. I'm so happy. I'm better than I was. And I don't ever want to go through that again, right? Because I've gotten to a new happy place. The real problem is that new happy place, while it's better than it was before, is nowhere near what's available. And this is, this is leaving benefits on the table that could be, could be attained. And the Kanban maturity model approach is to say, let's let's try to remove both of these problems through evolutionary change because evolutionary change has the answer for both of these problems. Great. Thanks, Todd. And one thing we want to share with you all is sort of how this looks in terms of maturity levels and what it feels like. So oftentimes, when you're looking at something that's low maturity, like oblivious, for example, you tend to find the idea of my way. Everyone's busy, but no one knows what they're actually working on. And this kind of results in individuals having sort of an ownership that's only theirs being unpredictable and unreliable in terms of service, and people are typically overburdened. And you have unhappy customers and happy managers and happy people as a result of this. So what are some of the solutions to this? We recommend that people consider things like visualizing work at the team level, limiting how much work is in progress, defining some policies to get started, and really having conversations to these feedback groups that we call the Kanban meeting. Now, if you can evolve from that, you'll find that you're probably in a team focused situation. Now you're kind of working together, but the result is never the same way twice. Here's an example from internet equipment manufacturer out in the world, and they said, hey, every team reports that they were delivering on their commitments, but I know that customers are waiting longer than six months for delivery. That indicates that we're not doing the right thing in terms of servicing the customer. So we're missing out on the customer here. And what we recommend is you look at a service orientation workflow board. That means servicing the customer and orienting yourself in that way. And actually conducting flow reviews, looking at how well the work is moving through the board, considering how you work together as a team, how you solve problems together as a team and reduce the delay, solve the quality problems that are there and really meet the customer's expectations. If you do step into this, which is really maturity level to what you may find is something along the lines of never the same result twice. So you have a lot of managerial heroics trying to wrap up the final end of something, a lot of delays and potentially last minute tension, despite the team coordinated effort. So there's definitely a chance of the ball to be dropped here and getting it to the customer. There's a hard time in finding a consistency with the delivery that you're trying to make happen here. And this is what we find typically maturity level to. Instead of this, we say, Hey, what are the options to really improve what you've got? Well, set up some lead time tracking. Some of you may know about this. Others may not yet, but that's a really good thing to look at. Lead time is really how long it took for you to start the work and then finish the work and get it back in the customer's hands. That's one example of it. And so additionally, you might want to have someone wear hat that's called the service delivery manager role. And that's really focusing on making sure work moves through the flow of the board or the system that's there that we talk about. That's the idea of tracking work and making sure work moves along without letting it hang around too long. And then also we kind of grow up what we had previously in terms of our feedback meetings. We have what's called a service delivery review. That's really exciting. That's what we're saying. How's it working for our teams? How's it working for our customers? Are we really hitting the mark for what they want? If we are, then great. We're starting to move in that direction of being really what we call fit for purpose. If you get more mature as you develop this idea of delivery that's predictable, you really become fit for that customer's needs. That's your goal. You're trying to say, hey, the customer has these needs. Are we really meeting those needs? Are we fit for those needs in particular? Some of that really comes around predictable delivery. You don't have heroes anymore. You really have a process that is what we call under control. You can see things flowing through the system reasonably well. You can predict things with some level of quality here. The advance beyond that is an organization truly. You're moving into what's called risk hedged. You're actually taking on risks. You're playing with risks at the organizational level. It's a lot of fun actually. But it's also a lot of thinking and a lot of math to make sure things go well. You're triaging the demand that's coming into your organization. You're making some good decisions around what to do next. And it really can vary depending on your organization size. But what comes out of this is you're really having predictable delivery and you're also having no more surprises. That's a big change in your organization. Usually there's a lot of delight in here. And if we move beyond that, you'll typically find that you're really developing into a market leader. So beyond just having predictable delivery, beyond just becoming a risk hedging organization, you can actually make the best decisions, provide the best quality of service, the best product. And typically there you're focusing on marginal gains because you actually have a larger scale opportunity here as a business. And you're paying attention to every little detail. So quality is the highest value here in this case. So you're looking for a lot of good outcomes. And there's a team effort all around for sure. Now we have this level of six, which is kind of unique. A few organizations have achieved this in terms of their ability to reinvent themselves. So in keep in mind, we're looking for challenging the identity of the organization. We're definitely looking for a new purpose all the time. And our example here that we have is the Wright Brothers. They worked with bicycles to begin with, and then they moved to Plains. So they weren't necessarily saying we're in the bicycle business to build the best possible bicycles. They might have been at one point in time, but they decided, hey, let's try out the Plains and see if we can do something with those. And there they changed and became very involved in Plains. The same thing can happen, by the way, like Virgin Airlines or Virgin brand is another good example we're talking about here where they can easily go into the record business and then switch over and do something else such as spaceflight. So when we're looking at evolutionary change and the maturity model, this is how it kind of unfolds. You start with where you are now and we're using a bicycle metaphor for the simplicity sake of it all. But we're looking at things like start with where you are now. So you might be at level zero. You might be just riding the tricycle to get started, all your safety gears in place. And your goal is to ultimately really become competitive with bicycling. So as you grow a little bit more, you'll find yourself at level one with some training wheels. You're kind of getting closer to riding that bicycle the way you wanted to. Then you move up to level two, and you're getting more mature. You're getting a little bit better. You can really operate independently. You're finding a lot of freedom here. But sometimes you might need to roll back because at this point you might have some issues. You might take on a little too much change, add on a little too much in terms of how you improve, and you might have to fall back a little bit. That's OK by the way in the compound method. It's OK to change gears and try something different. If you do, you probably will roll forward and find a lot more maturity as a result. So your pathway will definitely be unique. But as you continue to evolve into these additional levels of maturity, you'll find that you can really do what you want to do as far as a business or as a team and organize yourself in such a way that's really fit for your purpose. And that's what we're getting after with this maturity model. Yes, so what I wanted to talk about next is the application of this, the case study at Vanguard, done by David Hughes. And at Vanguard, they had been using Scrum for a while, and they've been doing OK, but they've been sort of stalled out a bit. Yeah. Yeah. So pre-state, they were in Scrum, and they had sort of a stall out point where their lead time was up there in 38 to 57 days, and things weren't going OK, but they weren't really happening. They really didn't understand everything about the system. So what did they do? Well, they started working with the Kanban method, started implementing some things. They got to what we would say roughly level two in the Kanban method. They had a lot of work in progress. They did some work to reduce that work in progress, but they didn't fully get to a point of limiting it. But they did a lot of the other practices. And the result of this was quite substantial. They were able to, when looking at their flow metrics, they were able to significantly decrease their lead time. They had dropping it from, on average, from in the range of 60 days down to 15 days, it would turn out to be about a 78% improvement in roughly 90 days. And they had nothing, none sort of outliers. This is another team that they worked with. A big part of their success factor was visualizing the work. So they made a big board. It was huge for them. They used a tool called static systems thinking approach to introducing Kanban and very similar results. But they actually did even better in some sense from the Kanban maturity model. They had learned from the previous team's situation. They still got about the same improvement, 77% improvement in lead time. But because they were able to do some more work on limiting with, they were actually able to get not just significant improvement in lead time, but also significant improvements in throughput through the results. So if you look at the next slide, this is the cumulative flow diagram as they're advancing from KMM level one to two, which was sort of scrum and beginning stages of some of their Kanban work, they were getting some results. When they really were able to advance to KMM level three was when their throughput really took off and got almost a fourfold improvement in their throughput. What they looked at as their critical success factors was having a big visible Kanban board, doing some upstream filtering, meaning making sure that they actually vetted the incoming request, incoming service request, and had an approach for managing that demand. They focused on bottlenecks. That was a huge part of it. And then they utilized the Kanban maturity model as a tool for understanding where they were at and how they could continuously improve. We see similar results. This is the situation here at Kanban, Kanban Impact at Accenture in Brazil. This is just before and after they took training and we saw some significant improvements in their throughput as a result of just starting to use a few of these practices. So these are not big, big changes, but they are transformational. So it's not a transformation. It's about being transformational. Yeah, thanks, Todd. And just to wrap up here, if you want to learn more about the Kanban method, we have an official guide to it at our website, Kanban. University. And there's also more information here. You can definitely reach out to us through our website if you want to learn and get some training or work with a coach or work within a consultant. So just let us know through Kanban University's website. And thank you very much for having us here today. That's time, I believe, correct? That's time. That's amazing. Thank you. That was very, that was super speed for all those different levels and great examples as well. Thank you, Joey, and Todd for that. So we do have one question and thankfully right now it's given that we don't have too much time, we can take it right away. Krishna is asking, do you suggest an approach to adopt Kanban majority model based on type of environment and organization? Yeah, so I would say the first step is, is understanding what your organization, how your organization is behaving today. So we always say with the Kanban method, start with where you are today, start with what you do now. You say you do what you actually do. And so one of the approaches that we use as a standard approach is the static method, the systems thinking approach to introducing Kanban, where we really try to deeply understand what you do today and utilize that as the means by which to start the roadmap. And the reason we go deep in understanding what you do today is there's a good reason why you do what you do today, we want to understand it. And the second is if we really deeply understand it, that's how we can start planning out experiments for incremental change. It's really hard to do incremental change and if you really don't fully understand your system. So that's how we say start, start with understanding your current work, regardless of where you're at. We have implemented Kanban in all sorts of different environments, working with, obviously in software development, a big part of it, IT operations. But also, we see it used in, we've been seeing it used in farms, we've been seeing it used in banking, we've been seeing it used in business process optimization operations, all sorts of areas. It's a tool that's anywhere with knowledge work, it can work. It's just about understanding what you do today. Thank you. So we are actually out of time. Thank you so much, Joy and Todd for this wonderful session. I know it was a little rushed, but it was very insightful. I'm sure everyone got a lot of value. Thank you. Bye bye.