 Welcome everyone to the session by Todd Little about turbocharging your scrum. We are glad that Todd could come and join us today. Great to be here with Agile India. It's been a long time appreciating the work done by the team in India to keep the Agile India movement going. So today I'm going to talk about turbocharging your scrum with Kanban. I'm Todd Little, I'm chairman of Kanban University. And I've been around the Agile space really since before I was Agile, and been involved in a number of and seeing how it's evolved. And what I've seen now is that scrum has become quite dominant, but there's I think the settlement of Kanban that can be utilized to help scrum. And I think it's a lot of misconceptions about what Kanban is. So when we talk about scrum, I'm talking really about the standard scrum framework. And I think everyone's quite familiar with the scrum framework. In particular, I think the scrum guys calls out the 353, the three roles, the three events and three artifacts. And to a large extent, that's what people are ending up doing in their scrum implementations. And so that's what we're going to start with. If we look at how I see in the world the scenarios of what come out of scrum transformations, there's a group of people that where scrum has worked for us, and we continue to get better. There's another group where scrum has helped a bit, but we haven't really gotten better lately, stall out. For other people, scrum has been a complete disaster or been called out as a disaster. And in some cases it really didn't help, but it really didn't hurt either. The challenge is that many people have influences from quite dominant, but they're not getting the results they want. Jeff Sutherland's on record is saying 58% of scrum implementations are late over budget with unhappy customers. It's a real challenge. We're not getting out of scrum what we really hope for. And it's not entirely scrum's fault. I mean, scrum can do a lot of things. And I think the thing that we see, though, is that when people are stalling, there are things we can do to help. And part of this issue comes back to the core foundation why we see transformations fail in the first place. And the problem with transformation is the whole concept of transformation is based on a mindset of, we're going to do a traditional change process. We're going to go from a current state to a future process to a future state. And in the process, we're going to have to do a transformation. And this is sort of the fundamental challenge that we have in bigger bang transformations. The challenge is that this only works when the future process is designed in advance. Or if there's good, and so if you're making this big chance use, you have to, you're making a big leap of faith that the steps that you're making are going to make you improve. And the challenge with these types of transformations is effectively, they're reverting back to a big design up front. And we know that the agile will really try to avoid a big design up front. So what do we do? Why does this happen? If we look at a transformation and we on the Y axis, we're looking at the capability of the organization and X axis being time. What we've sort of hoped for is that we start with the current state, and we're going to take this time to do a transformation and get ourselves to the future state. And we're hoping that this gives us a nice path that eventually be improved nicely. And the reality is what happens in real transformations, we see it over and over again, and this is really pointed out well by Virginia Satir, who saw this type of behavior happening in working with addict families, that the addict families and alcoholics or drug addict families, when they had reached this point of stability of how they had operated together, but when they introduced a change in the environment to try to fix the problem, fix the perpetuating problem, things actually got worse for a period of time. And then over time, if they could, if they could get themselves out of the deep valley, eventually things would get better. And so this is called commonly referred to as the Satir change model. And we've noticed that this type of behavior happens almost any type of change, and we see it in transformations. And the reason for this is that we are making a change to something that has reached the sort of status quo in steady state, and that actually makes things worse for a period of time. The challenge with this is that that change of that transformation is too big, that valley can be very deep. So there's an element of safety. And the other element is that it's too big the time is too long and we lose patience. We say, oh, we didn't, we didn't see results soon enough. And so we need to, and many times what happens under a lower maturity situation is the organizations will panic under stress, and they'll abandon their hope of getting better. And these types of problems are very, very real. And if we look at some results from the PMI, the Project Management Institute, we see that very few transformations are actually not successful. Only 18% are really outright successful. 68% have some degree of moderate effectiveness and 18% have outright failure. And this is the challenge we have with the bigger bank transformations. What we try to do, what we look to do in the Cambent world is avoid two problems, one of overreaching and the other a false sum of plateau, because these are problems that we see regularly. Trying to take on too much and hitting a point where you get to a new happy place and that new happy place prevents you from getting better. The Cambent has worked towards these and looking back at the change curve, what it means is that rather than going with the overreaching here is taking on too big of a change. So we looked at not taking on such a big change. The other happened is the false sum of plateau come out of that in a mode where we're happier than we were before and the pain was so great that we say now that we got to a new happy point, we're going to stop improving. We're going to give up any really chance of improving because we don't ever want to go through that big change yet. The Kanban method approaches this differently because we're missing that benefit. We want to use evolutionary change, not revolutionary change. And that's the whole element of the Kanban method is to, to make our changes small enough and continuous enough that we get continuous improvement. So looking back at our problem is rather than going on this, this line, the Kanban method approaches from a very different approach. Let's not worry about designing these at front. Let's take smaller increments, make those J curves or the valleys much smaller and continuously update based on new information. And that's evolutionary change in action and that's really what the Kanban method is about. And this is what we can bring to Scrum. Kanban can help your Scrum by utilizing a lot of what we've learned in the Kanban world that's quite complementary to the Scrum approach. What many people think Kanban is, is just a bunch of stickies on the wall. And that's not true at all. The Kanban method is far richer than that. I think the other thing that people can often think of is to think in terms of Kanban versus Scrum, which is, again, not true. The Kanban method is not a framework. Scrum is a framework. The Kanban method is not just a board. It's not something you install. It's not even a transformation. And any real comparison of Scrum versus Kanban really makes no sense because they're not the same. They're not the same in any sense. Scrum is a framework. It's an incomplete methodology. It's a guidance of structure that you put in place and then you can build on top of that. Kanban starts with what you do now. It's a management method for improving delivery of knowledge work using evolution and change. We start with what you do now. Whatever you do now is perfectly fine. We started proving it based on that. And while it's not a transformation, Kanban can be quite transformational. And I'll give some examples of that later on as to how we've been able to make some significant improvements in various areas. Other than being a framework, I look at Kanban as a fun framework. It's something that is there that it's not something that you can compare to Scrum or many other agile approaches. It's something that we do to improve your existing process and continuously improve your existing process. So start with what you do now. If you're using Scrum, that's great. We're going to use Scrum as your starting point. There's nothing wrong with it. There's nothing in it whether we have to throw out your Scrum and come in with Kanban. That whole concept is just flawed. What we do is we start with what you do now in your Scrum and we start working on how it can improve it. The thing with Kanban is because it's a start with where you are, it's a great unifier. You can start anywhere. You could be waterfall, you could be in safe. You could be in chaos. You could have no predefined method that you're working with. And still, Kanban can help you by starting with what you do now and improving it. You can be Scrum. You can be CMMI. Any of those will all be fine. And you can be any of those within an organization to have multiple of those going on at the same time. And Kanban could be there as a unifier that pulls that together and uses it as an improvement technique. Kanban is not first reorganizing into pods, squads, chapters, flocks, birds, mobs, packs or mobs. We don't do reorganization. Reorganization is a last resort and we don't come in with all these fancy, you know, like a consultant company coming in and saying, the first thing you got to do is follow this pattern. No, we don't reorganize. We don't give everyone new job titles. We don't take those big hits in the transformation model. What we do is we first focus on what we do now and then we start looking at where's the pain and then what we do about it. So it's really more structured by introspection, looking at what you're already doing and then improving it. So with that, let me just quickly introduce some of the key concepts of Kanban and how they really apply within a Scrum world. So first of all, we'll talk to the Kanban change management principles. So the change management principles are quite basic. Number one, we start with what you do now. And this requires us to really dig in and understand your current processes as they're actually practiced. Not how you have documented them, but as they're actually practiced. You want to really fully understand what's the status quo, what is, how are you working? And then we can get better about it. We also expect we respect existing roles, responsibilities and job titles. We don't give everyone new job titles. We don't tell them reorganize into new teams or anything like that. We start with what you do now and reorganization becomes a gain agreement to pursue improvement through evolutionary change. And in order for that to happen, we need to encourage passive leadership at all levels. So everyone comes, takes on active leadership, steps up and work towards the improvement of the system. So if we look at Scrum and Kanban different perspectives, let's introduce two characters here. We have Sal Vador and he's a long time from practitioner. And then we have Rosie and she's going to talk about how she can bounce. Yes, we can. So in this, the first change management principle, we start with what you do now. Now in the Scrum world, this is, this is one of those things that's a little different because typically what you're doing in a reorganization in your transformation is reorganizing into cross functional teams with the three roles of product owner Scrum master and team member. And that's, if that is what you have done from a Kanban perspective, that's okay. The Kanban does not explicitly require cross functional teams. If you already have built cross functional teams, that's fine. That would be your new starting point. The Kanban reorganization is generally a last resort. So if you're in Scrum and you've done this and you've done the reorganization you've built the cross functional teams and that part's working, then we continue with it. Now, of course, we may have to go along if you continue to explore and improve and there may be future changes to that. But if that's a working model for you, we don't really want to break that up. If we look at to agree to evolutionary change. This is an area where where there is quite a bit of overlap with scrum. And the scrum is based on empiricism, which done well, continues to evolve. What unfortunately I see frequently is that many implementations stall out or revert. I come into organizations many time and look at and talk to them and and frequently they say, well, we were we were struggling with with what we're doing and so we reverted to exactly what we were taught. If you're doing scrum the way you were taught, you likely aren't doing scrum very well. The whole point is to continuously inspect and adapt and continuously improve. And unfortunately, that's one of the big problems that I see in scrum implementations is that that is not done well that continuous improvement is not done well. And I think in the Kanban method, because it's core to a DNA continuously improve and we have structures and models for how to do that. The approach we take is start with what you do now almost implicitly requires that you get continuously better because we're making small changes. So you've got to fully understand the current process in order to improve it. I think that's one of the challenges that people come in the scrum world is that they're given a framework and said, okay, go use this go install this framework. And by the way, improve it, but they don't necessarily fully understand how the framework works. They don't have the fully inner workings of the framework to understand what knobs and knobs and dials they have to work with to improve. Whereas in the Kanban world, part of the approach to it is to really spend the time necessary to understand your current process so that you can continuously improve it. We then use guidance experiments that can be measured to establish this mindset of continuous improvement. So it's getting that change mindset in place in order to get continuous improvement. So change management principle number three is encourage active leadership at all levels. And this again in the scrum world self organization can be a really key element to encourage active leadership. But what I see a lot of times is that the the product owner or the scrum master or the team manager will be viewed as leaders and the same number simply come followers. So this is something that we we want to call out is that we want everybody to be stepping up as a leader. And taking not necessarily stepping in with a leader, but at least taking acts of leadership acts of leadership certain steps, stepping forward with ideas for improvements. So we work to create a safe environment to encourage active leadership at all levels. So those are the three change management principles. Moving on from that we have the six general practices of the camp. And these six general practices are to visualize your work. Limit work in progress. Manage your flow. Make your policies explicit. Establishing feedback loops and improving collaboratively evolving experiment. Through each of these, looking at this from a scrum and a candidate perspective. So it's visualized. We see that many strong teams make a visual board either physically or using electronic tool is a very very common aspect of the strong strong approach and I think it's a good start to start with having at least visual board. And in either physical board which we love, or electronic versions of that which are, are good as well, and really help when you're distributed. So the way we look at it from cabinet if you're not already done so. And map out your workflow and map out your workflow as a series of knowledge discovery steps by building this out this helps give you a little bit more detailed understanding of the state of where you're at in the knowledge discovery and gives you a better sense of how things are flowing. So the visualization that you want to include is, is to go broader to the more you can see that exposes where, where the where things are impacting flow. That's a great thing. So we're looking to visualize in order to see flow. The other thing about visualization in addition to this the board is other things such as your policies we're going to get to that visualizing your policies and visualizing some of your metrics. The metrics can tell you great story they can tell your story of how your flow is working. So visualizing the board visualizing the policies, visualizing the metrics, everything that we can visualize it just gives us a better insight into what we're doing. And you can see a large number of scrum people already using Kanban, most likely this 81%. Most likely their view of using Kanban is they're using a Kanban board because that's what it's called and many of you can hear or ADO. But so the idea of utilizing Kanban in scrum very clear it's, it's people are already doing it, and they work well together to work well together Kanban can really help from. So limiting work in progress. How does that look from a scrum perspective. So scrum limits work to look at work in progress to some extent, really by creating small batches so by by limiting yourself to small batches, what you can fit within the sprint. And that has some degree of limiting work in progress now it doesn't oh, I think that the, the extra step we take in the Kanban world, really is to set when whip limits for each step in the work, each step in the process. It gives proof control and improved predictability. So, when we get some degree of whip limiting through through the small batches, I think the extent to which we can control that better, reduce the, you know, keep the focus and reducing the work in progress across each of the individual steps, gives us a much better control over our flow much better predictability, and gives us much better continuous flow. So managing flow, and this is the key, the key to the Kanban method is that we want to be managing flow we want to be focused on managing flow, more than we focus on managing the workers. We want the flow of work to happen we want to focus on flow efficiency, making the workflow, not so much on worker efficiency making sure people are busy. Getting people busy is not good to is not useful to the extent that sometimes actually creates barriers to flow. So let's look at from a scrum perspective. Again, with managing flow, the challenge is that, while we have self organization, many times the implementations are not. You know, if your daily scrum is sounding like a status report, then you've probably got some room for improvements I saw this very, very early on in the early scrum days, particularly when the three questions were very popular that the, the responses from those three questions almost invariably came down to a status report rather than what we really intended to be, which is how are we planning our work for the day what are we looking at this in our ways, you can make continuous progress. So, but I think it's just typical that when people don't fully understand scrum and are are practicing it just in name. It reverts to a status report and if that's what it's looking like this room for improvement. When we look at also some of the metrics we have in the scrum or common metric, although not called out explicitly in the scrum guide is velocity from from your story points. Velocity can be useful or it can be misused I've seen it. I've actually seen it probably misused as often or more often than I find it to be useful. In the scrum in the campaign world, we really focus on the work and let the workers self organize. We walk the board asking what is preventing items from flowing so we focus on the work items. What is the work item. What's a work item telling us, not what is the worker telling us. We don't need to know that somebody spent, you know, yesterday, fixing their build environment because that's what that means is that they're justifying their time. We're really working about looking at what's keeping us from this item from flowing. What do we need to do going forward so more of a future look forward. What we need to do to keep this moving. We collect and display metrics such as the time run chart and keep the flow diagrams. And as we learn about how those metrics work, it just tells us a great story about what are opportunities for improvements, making policies explicit. This is something many scrum teams do they've made a few policies explicit like definition of done or definition of ready. And these can be great policies. Absolutely. These are these are things that make make a lot of sense and are really, really helpful to understand how the teams working in the world we look even broader than that and start looking at other policies which could be made explicit, such as poor criteria, what are classes of service classes of service or essentially identifying a form of prioritization, you call it that we tend to stay away from privatization but it's basically indicating a service level that we're going to apply to different, different work items. And associated with that one of the, what sort of service level agreements do we have so coming up with different policies and we don't want a lot of policies, but we want just policies that really help the team understand, how are they working together. What can they rely on other team members. Feedback and feedback loops. This is a big, big key to me because I think the many people think about feedback loops and they talk about this, and they conflate feedback with feedback loops and there's a big difference between feedback feedback loops. And what that is, is that we look at this picture here this is the cover of David Anderson's flu book, and then great book actually absolutely recommended as a great starting point for you if you're wanting to learn more about We look at this and there's a lot of information coming back the information coming back is feedback. The reports back from the individual to see back the board itself is providing some feedback. You've got some reports and metrics that's providing some feedback. The key thing with a feedback loop is this last one. Let's do something about it. Doing something about it closes the loop. If we don't do something about it. We have an open loop. We have feedback but it's open loop it's not being closed. Nothing's happening. So feedback loops is about taking information the feedback and then taking the active leadership that closes the loop. So in the scrum world. From has the five events for the feedback. And unfortunately, well many religiously do the ceremonies. Many fail to do something about it. Now, this is something that high performing from teams absolutely have this figured out that figured out the feedback loops are key to making this all work. So you have to do something about it. The scrum guide states the improvements may even be added to the print backlog than express. So there's a there's a. It's clearly in the scrum guides from DNA. This challenges many people struggle to figure out how to do it. In the can bed world we have cadences, which if you're starting with from events, the cadences can be the idea of the cadences is you start with what you do now so you start with your events that you already have and then we work from there. And the key is to utilizing feedback and taking the active leadership to do something about it. And that ends up closing the feedback loop. So let's look at the cadences and the events and how they relate to one another. We have the five scrum events the sprint the split planning the daily scrum sprint review and the sprint retrospective. There's almost a one to one correlation between the camera and cadences and sprints and the and the scrum events, but there are some nuances that are different. For example, sprint itself sprints are not the required element in can ban, you don't have to have them and in fact many people don't. But if you like sprints, it's okay to keep them can then does not say you don't have sprints it just says you're optional if you want them you have them. And if you're starting scum you probably will start with them. But many, many people as they evolve will end up breaking out of the sprints. If they if they feel that they're no longer necessary sprint planning. There's a very somewhat analogous element of the replenishment meeting and this is where we pulled new work items into the system. The main difference, usually is that the replenishment meeting itself as we call it out does not involve planning. But if you were to start with scrum your, your version of replenishment meeting would probably be your sprint planning and you would continue to do the planning until you decide that there may be better ways to do that. So that would be up to you. There's a daily scrum and in the campaign world we have the campaign meeting. Probably our main shift here is to really focus on flow, which I think many people have already done in their scrum daily in their daily scrums has shifted to the approach we take in the campaign way of looking at walking the board or working on looking at how items are flowing. The sprint review, we have a service blurry review. I think the key element of our service delivery review is that we really try to review the metrics and focus on what the metrics are telling us and how does that impact some of the decisions that be making. And then lastly the sprint retrospective. This can be kept or dropped. And then we can have any implementations that will start with the perspective if they were doing one, and they frequently they'll end up dropping the formality of a retrospective and handle improvement more continuously through the review so that it's not that they're not doing it is just they're not doing it as a form of that. The challenge I see was frequently with retrospectives that are done as formal events is that there's a lot of emphasis on the ceremony of the retrospective and on the doing of the retrospective. Unfortunately, there's not too much of the closing the loop there's not the act of leadership often that are necessary to actually take action on that. It sounds like this I held a retrospective and all I got with this lousy t shirt, did you actually do something about it. And if not, why are you holding retrospective let's do something else that actually works better. So lastly the improve collaboratively evolve experimentally from aims to be based on empiricism and continues evolve if you're doing what you're taught you probably aren't doing from experiments experiments might be a bit of a misnomer. As we have lots of pragmatic guidance now for many years of Kanban, Kanban maturity model is a great guide, but might be appropriate. So speaking of the Kanban maturity model. Let me introduce that briefly this is something that's come out in the last few years David Anderson and the door both of them have been worked on putting together this model in a Britain, a book with now has a second edition. And really is, is there to document how we have mapped out over 150 specific Kanban practices to observable business outcomes and mapped out over seven levels organizational charity. And this is really looking at three key elements culture practices, and how these outcomes, and then what you do to manage the evolution so how, given that we're talking about making these small steps. How have we seen organizations make these steps and it really depends on where they're at now as to what the next appropriate next step is. So we map these out from the level zero oblivious we call it this is the my way this is where a lot of people are working individually. Everyone's busy but what are they producing their individualism and predictable and reliable service overburden people, which means unhappy customers unhappy managers unhappy people in general. So, this is where we start frequently, then we move into more team focused. It's never quite the same way twice. We see that every team reports to deliver on dividends, but I know customers are waiting longer than six months for delivery means the teams are thinking they're doing great, but when it actually comes to pulling that together multiple teams involved in it. Nobody's looking at how it pulls together how in the end workflow as all come together. So the customer level ml2 we have customer driven never quite the same result twice, but they're better better service or better meeting customer needs. And this comes together to manage area heroics. So delays and last minute tension despite coordinated team effort so they're getting better pulling together better at focusing on customer needs. But the integration of the teams is happening so heroics as opposed to being really structured from the yet. At level three were fit for purpose we're hitting towards a particular delivery. We're no longer having heroes. The processes are under control. We have an understanding of system of the end to end system and we're pulling together so this is really starting to scale, how we scaling it out to actually get good delivery. At level four risk edge everyone's happy no more surprises not only do we have a well defined system, but we're at the point where we can actually anticipate changes in demands we've got quantitative measurements that are helping us really understand how are things coming so that when something comes in it's not a surprise. Basically, at this level we're really moving on beyond and highly predictable and highly predictable even in uncertain times. So we look at this, look at this as a bit of a metaphor with bicycles and all metaphors are a flood that some are useful. For level zero we start on the tricycle we're starting with what we're doing now. We move up we get new training wheels. As we get to training wheels we think we're on a bike but actually we keep falling off the bike so we roll back and we pull back for it again. We're starting to get really good at the bikes we got a bigger bike and faster bike maybe have some gearing on that bike, we're really doing well we think we're really agile on our bikes. But as we mature and we get more fit for purpose and really, really start to look at where are we going to be utilizing the bike, we may have a specialization of bike so the, the, the individual is the organization, and the bicycle is sort of the evolution of the process. And that's what we're looking at here as we're getting better and better and improving on our as we're going. And this is all evolving maturity. So let's go through quickly a case study. This is a positive science, a case study where they were starting from. They were doing some brain plasticity work, it was a very, very high research type activity by a neuroscientist, Dr. Michael Meredith. It's not brain surgery it's not rocket science, but it is brain science. So, as a background, they had started with strong as their development process it was working fine and really helped them initially get the first product out the door they thought it was really good they really liked from they didn't really want to move away. From it they thought it really helped, but they started to have some problems using they just didn't feel like it was that the scrum was holding that it was allowing them to operate the way the business was operating. And they have some magic coaches from outside and they just weren't doing scrum properly. That was the problem. There was no problem with scrum, they just weren't doing scrum properly and then maybe there was something to that that doesn't what they felt like the team didn't feel that that was the case they felt that there was something else. So what they did is they looked at where their sources dissatisfaction with their motivation for change. Stories were not getting finished deadlines for being missed. These were looking to customer perspective and internally there's a lot of fragmentation they're pulling in any directions priority priorities changing. They were doing these task based estimates which they felt just useless inaccurate too much effort to produce and really weren't helping them in any way. So, their initial campaign implementation was very simple they don't want to break things they didn't want to they really were sort of happy with scrum but they like this idea that maybe they should take some baby steps here. So instead, what they did is they did to two steps really in their implementation initial initial implementation one is they stopped task estimation, and did their user story estimation by T shirt sizing. They actually got out of the quantitative estimation. And then the other thing they did is the implement of per person with limit. So, very, very simple starting points. They started with their initial strong or they just made a little bit of variation of that. So, that was their scrum board out of camp and board and then they set up three with three items per person with limit and they encouraged collaboration on items as well. So just very, very basic starting points and that was that helped them a bit. It really provided some relief from the overburdening they just were felt like they were just trying to tackle too much and this gave them some structure around that. It also gave them a rich language for expressing the frustrations. Gage them motivated and motivational for the next level of change. So then they did this again they looked at what are some of the sources of frustration. The customers were still feeling like they were too busy to discuss new work the stories weren't being finished. The deadlines are being missed. Many of the same things but the team started to get a little bit more detail and understanding what really happened in those six, six months is they started to really understand the workflow. Where were their challenges would expose them to having that conversation that they could have the rich conversation the meaningful conversation, the feedback that then they could say, let's do something about it. Let's take smash. So what did they do. They created some goals of the new system what did they want to happen. What did they do using the conflict context switching using work in progress dead year workflow, really focusing on flow in clear priorities. So after they made some more changes this is their incremental update they went, they dropped the concept of iterations and went to a flow and service level agreement. They did a script planning, they, they did a replenishment meeting, and then they did the planning just in time per feature so they did the planning rather than doing it all at once they did it on demand. They changed some of the structures and how they did the demos and retrospectives. So they had a replenishment meeting and they created this thing called a top 10 list was very simple so just, this was a structure within rather than trying to prioritize the backlog, they said, let's just tell me what the next top 10 are. And once you have top 10 will just pull from that top 10 so you basically you're committing as product owner that these are the top 10 items, and we can pull them. The colors here are indicating the service level, the service, the class of service, and you know the higher level of the pink ones of the expedites and so they get pulled faster, but others. The team had agreements and cold criteria on how they would pull items in into the board. So this is, you know, structure the board they had a backlog, they pull items into the top 10 list once it pulled in, then they start pulling features in and breaking the stories down and pulling that group. So this is just a very natural extension of how they have been working in Scrum but it was a richer, a richer model that really helped them improve and understand what they were doing. So here we have the board that they actually use. And a whip limit, the various described the understood where were their pain points and what are the what are the actions we can take against those pain points so putting a whip limit on the product owner, hold them accountable, and they put the board next to the the executive so that when that board got fulled up and it was stopping things. Everyone would get on top of the product owner and make sure that the items in the accept column were passed through. So, had deployment bottleneck they wanted to protect. And they wanted to create smooth flow through clinical testing these were all that was especially a shared service clinical testing shared service, and so they wanted to make sure that that was managed appropriately. And then the next but that way. This is one more case study and that is the cabinet Vanguard, and this is a case study that was presented by David Hughes at the Academy Global Summit 2019. And this is the case where they had been very much using utilizing Scrum. And they had some, they had again had some sources of frustration, they weren't really feeling like they were improving in this room they had had reached what David called strong stall they've gotten some improvements, but then they just weren't getting any better. They had average delivery times ranging from 3857 days for their work items. So what they started to do was implement. Can ban and you can see over time here with one year of scrum things would have been operating in that that range of what with 38 to 57 days. And once they started implementing can ban and make and correct collecting the data, they really could really focus on that and get their average lead times down substantially. As you can see from the blue line as it drops. And the other thing was they had no real outliers. They were able to manage their workflow so they had no outliers and they could bring their average work item the time. So it's 98% improvement in approximately 90 days. So that was what's one, one team. This was team two we really, they really went to understanding and building out the focus on visualization as a key element and visualizing out the workflow. And it was great to have a big board that they worked with. And again, they ended up coming up with about 77% improvement within 90 days. So the strong we have at this point in this team we actually have a little bit more data on collecting on how they've been doing with scrum. And as they work with can banding drastically improved and only very few outliers so they really were able to get to improve their productivity substantially as well as improve their, their lead time. And not only did they improve the lead time, but you can also see from the chemo flow diagram, the slope of the chemo flow diagram that up until here really sort of when they're in scrum world. They were operating probably where we call a KMM level one to two team level or maybe a higher level customer focus level. They were able to really drive through the improvement process to KMM level three, which gave them about a four, four X improvement in throughput so remember that again this is from a team that was starting from scrum so you know, we were getting one fourth lead time on top of scrum. And this was done through big visible physical can band board upstream filtering, keeping things from getting entering the system that really didn't belong. A focus on bottlenecks, really making sure that flow is working and then leveraging the can band maturity model to make this happen. You see this frequently we see this other places as well this is an example from can been of can be impacted center in Brazil. And you can see the slope of the chemo flow diagram before they did the class this is really just the can be class can then system designed this is called can be one. Very, very slow throughput. After the class they went up substantially. I think this is almost 20 times improvement in the slope of the delivery. And by the time they have implemented can be so these are the types of things that can they can do frequently just play by lowering whip limits counter intuitive idea that I work on less, I can get a lot more done, a lot more done faster. It's counter intuitive work from time after time. So just some background for you. There's the official guide to the can band method I highly recommend that that's available free on on campaign university website. The case studies that I mentioned both the positive signs and the Vanguard case study are available also on the resources page. David Anderson's blue book highly recommend that's a good place to start. There's also a central can band condense which is a freely downloadable book that goes through the can band method. And we also have the state of can been surveyed, just some good insights into how, how things are happening in world of campaign. So, with that, I think, right, more or less on time, and I'm happy to think that probably will end up having to take questions in another room or I don't know how we go here. So, so thought that there are, there are four questions here, you can probably take them, and then we will jump to the hangout. Okay. Okay. The first question is from Pradeep. During the daily scrum if somebody puts as there is a problem. The resolution is the top priority for the scrum master. You think this is not as per scrum guide, or if the scrum master has to act on it immediately then it will be termed as the team is using gone on also. Yeah, so I think this is probably the difference between. There is a sites that the scrum master is there's been this long term, the scrum master is the person who's responsible for, for fixing bottlenecks for fixing blockers. And I say I'm not up on the scrum guide to say whether that's currently the how the scrum guide calls it out I certainly know that's how it used to be called out is that the scrum master was that role. I think in the can band world, we view this is really the team is responsible for organizing that there's not there's not this one person who's responsible for, for process that there's this person called a service delivery manager, and the service delivery manager is there to reduce friction. So, and I think really that's what I see the world when I see really good scrum masters, their role is reducing friction, and it doesn't necessarily mean they have to take it on themselves. What I think what they would say is that they're enabling it to happen. They're figuring out what can I do as the scrum master or the facilitator of this team to help these blockers or help these bottlenecks improve. So, there's, there's not one absolute answer to this I think that's what happens is frequently. When people start from scrub they're looking for well who can I put accountable for this and the reality is we really, we're really trying to say it's contextual. It depends on how things happen and what I've seen in high performing teams is the entire team steps up to figure that out. Okay, thanks for the perfect that the next question is from guide three, which metric in Kanban can help the team to inspect and adapt. I think there's several I usually we usually recommend three key metrics as a start point because there's lots of metrics that you can have but the three that are sort of that can tell a lot with them. And they're easy. They're easy to collect so that the three we recommend the lead time distribution lead time histogram. The run chart, which is also an indication of lead time and it's showing how the time is changing over time. And that gives an indication of trending so the lead time histogram just gives us an indication of how variable. We are it helps us with understanding predictability and understanding will sort of service level who should be expecting based on history. So it gives us. Okay, we essentially frequently will place estimation with data collection and the data collection helps us understand what's realistic to expect for these items. And then the third one we look at is cumulative flow diagram the cumulative flow diagram is very helpful and helpful in telling us how is worth flowing and is it is the system stable, which is great. Is it getting worse, which we don't really like, or are we actually getting better and getting better is interesting because getting better is actually not stable, but getting better is what we want. So, there's there's time where we say, well, these things only work in a stable environment but if we're getting better that's actually better than being stable so we don't really care about stability if we're getting better we want to keep getting better. Yeah, those three metrics are the ones we recommend to start with there's other metrics that can be very helpful. Flow efficiency can sometimes be helpful, mostly just indicate you have a problem flow efficiency you have an issue where you're having large, a lot of delays, but often that will come out from the lead time chart as well. If we really get looking at the lead time distribution is how are you having a lot of delays or are there a lot of challenges. So, all of those metrics I think are great to help and then there's more. A lot of the inspecting adapters just be the fully deeply understanding. What does your, what does your process look like, what's your context to your process, and then you can really start making understanding what knobs you have to turn. But this is slightly on the question from Abhay. Generally it is recommended that we choose Kanban methodology only if there is a specific reason to do so, since it requires really high discipline and following Kanban principles. If the teams are not able to follow scrum properly probably they will not reap the benefits even if they switch to Kanban products. I think that's, I would say that's probably not. I mean, I understand where people are thinking well Kanban requires a lot of discipline. I think the reality is it is the key with Kanban is that, and this is I think where the Kanban maturity model really helps is that what you don't want to do is if you're really in a level zero level one type of maturity you're not you're not really getting you're really struggling. What you want to do is you want to take small baby steps. And I think what you don't, what you certainly don't want to do is try to jump to level three. And so the challenge is, as we teach Kanban, we teach Kanban to the level where you could apply level three principles but we also teach how to do it incrementally. So usually the things that we look at, if you're struggling with scrum, there are Kanban elements that you can bring on visualization certainly easy to add on. But I think one of the ones I would, I would bring on early is, is whip limits. And oftentimes that's one that has the most resistance internally, either from the development or from the, from the delivery team that is opposed to it or from the customer side, the business side who says no no I need to keep pushing things through. But if you can shift yourself and get yourself to where you start with whip limits. It opens up the world of possibilities and we just see it repeatedly introducing whip limits will drastically improve your overall flow and predictability. And it gets you out of this overburdening mess that is creating incredible opportunities. So, I think that what you do with my, my advice is, it's not about, and of course the, the, the, the wording of the question itself indicates the, the mindset problems, because it's called at the Kanban methodology. It's not a Kanban methodology, it's a Kanban method that we apply on top of an existing method. So it's not, you're not going to, it's, again, it's not a scrum versus Kanban, it's applying Kanban practice principles at very, very small incremental pieces on top of what you're already doing now already doing scrum great struggling with things because you're not delivering, you're not having predictability. Let's start looking at whip limits. Let's start looking at what else we could do let's look looking at additional policies. Let's start looking at mapping the workflow better so that we can understand where we're having delays, and we have better predictability about where we might have delays in the future. So there's lots of tools that we have in the Kanban method that can be be slowly added on to your scrum. And even if your scrum is not working well now we can we can do things to drastically improve it. Thanks again, Todd. This is a question from Gerard. I think he was one of the speakers. How can we make a physical Kanban board work for remote or hybrid remote ease. Yeah, that's a great question. And there's, there are some tools coming out in the world that are working better at that. Something that I would say is that some of the better Kanban tools like Kanban eyes or Swift from digitech do make a very good comparable virtual board to a physical board, and have built it from the design they've designed it as Kanban tool so one of the things that the Kanban tools that the Kanban is in a continuous change mode, we're continuously improving our boards are continuously improving which makes virtual, you know, tools have full with that because they like to keep things constant. But tools are designed as Kanban tools understand that as a core and build that type of flexibility into it. There are tools coming out. There's a tool from iObea that is creating virtual iObea room. So iObea rooms come from the Kanban method in the lean world, which is a big, big room for big visual room. Everything that you have that will help you understand the running of the operation, all the metrics, all the data, all the collection data, all the flow is in that one room. So it's called iObea that does that virtually and does a quite nice job with that. I think they're an interesting partner that we're working with. Excellent. I mean, it was privilege having you here. Thank you. Really appreciate it.