 My name is Todd Little, I'm the CEO of Lean CanVan. I've been around the Agile community for a long time. I got started in 2003. I helped Alistair Coburn start the Agile Development Conference, which is now the Agile 2019 conference. Went through big changes. When we started, we had 230 people attending. I think now it regularly gets around 2,500. I've been to Agile India the fifth time. I feel very welcome here. I'm glad to see a lot of familiar faces. Today, we're going to really talk about Agile mindset. It's Agile Mindset Day, and we're going to talk about what that means from a CanVan perspective. What is the CanVan Mindset? First, I'd like to talk about the Agile Mindset. When you talk about the Agile Mindset, we have a whole day dedicated to Agile Mindset. What does that mean to you? What does Agile Mindset mean? Thinking differently. So a psychopath is an Agile Mindset? Could be. Why not? Anything else Agile Mindset means? Open for learning? That's coming from the... adapting to what you see and building from that. How do you get on the Agile Mindset? You buy a t-shirt? You live it? Experiment? This is just to start with. I've been around in the industry for a while. One thing that I saw is that before you even knew about Agile, Agile Development, I'd been in a company in the 1990s. It was the most impressive organization. It was really focused on meeting customer needs and the environment was just energetic. It was a great place to work. If I think back in my career, what I've been, one of the ways I like to characterize businesses and what it takes to run a business is this model of people process technology and then to that I add business. Because this people process and technology are there to enable the business to do something. And if I look at this from how this is interconnected between these, the challenge I see, I think this is probably the biggest thing we see that I've seen is the distinction between sort of doing Agile versus being Agile, is that a lot of Agile transformations start down at the process and technology perspective. And where I have seen the biggest impact is when you have a really clear focus of what your customers are doing, when you know your business and you create an environment where people can be effective at delivering against the business, to me that is where it enables Agile mindset. You've got people who are directly responsible to what's happening and delivering against what customers need. That is just an amazing energetic place. And when we were doing that, we really didn't care that much about what our processor technologies were. It was like water to fish. They just emerged. If we had focused on instead processes and technologies and lost track of a business and lost track of the environment where people could do things, I think that would have been a big setback. And I've seen organizations that have claimed to be Agile that don't get the top two things and they really aren't being that effective. So why Canban? Now with Canban, what is it about Canban that's sort of interesting in these days and ages? This is an interesting tidbit from the 2019 Scrum Master Trends Report done by Scrum.org. And what you see there is organizations that are doing Scrum are now finding Canban to also be a very effective tool to augment their Scrum implementations. 81% of people claim that we're also using Canban. And this has been growing. The Scrum Alliance does a similar survey and it's been growing continually over the years. So Canban's out there. There's a lot of... Whether you're doing Scrum or you're just applying Canban directly the nice thing about Canban is that it's an apply it to where you're at now and Canban can be very easily applied to Scrum and it provides another tool in your toolkit that enables you to be Agile and more Agile or to bring business agility. So what is the Canban mindset? What do we think of when we talk about the Canban mindset? Before we get there, let's start with what we call Canban. So we distinguish between what people think Canban is. And a lot of people just think Canban is a bunch of stickies on the wall or it's a to do doing done column or it's throwing things into Trello or it's that one thing that Jira flaps at the end of and says, oh, this is your Canban board. Canban does have a lot of visual implications and a Canban board is a great tool, but Canban is far more than a visual tool. Canban is a tool for teaching organizations how to understand, visualize and measure systems of work to continually approve and consistently deliver results. It provides a set of proven practices and approaches that scale from individuals and teams to the enterprise. It's more than just a bunch of stickies on a wall. Many people see Canban is this thing under the Agile umbrella and now that's not entirely incorrect. I think the way we see Canban is it goes well beyond. It goes well beyond software. We have applied Canban in many places, financial industries. I've been applying it recently in geosciences and oil companies, geosciences and engineers. We're applying it in HR, marketing. It's a full business cycle. It applies to anything where knowledge work is going on ongoing. So it turns out a lot of the implementation of Canban are in the active business and in software. We can't even expand it well beyond that. It's the great unifier. It's a start with where you're at now. If you're in chaos, you can still start applying Canban and continually improving. Scrum, you can be from the CMI world, safe, waterfall, wherever you're at Canban can start and it can provide you incremental improvements and start an evolutionary change process. Some of the foundations of Canban, we start with change principles. We have service delivery principles and then we have general practices and all of this around some Canban values. Let's start with the change management principles. First, start with what you do now. We don't care where you're at. We're not judgmental. Wherever you're at that's great. Let's learn that. Let's understand it. Let's understand that current process, not as you say you do it, but as you actually do it. Because then once we understand what you're actually doing, then we can start looking at how to improve it. We respect existing roles, responsibilities, and job titles. We don't go change things. This is an evolutionary approach. If in that process we want to experiment with changing something, we do that. We design experiments. We then gain agreement to pursue incremental improvement through evolutionary change. And then we encourage acts of leadership at all levels. Oftentimes traditional change is this A to B type process. We start with a current process. We say what we really want to be this future state. What does that look like? And then we introduce this thing called a transformation. Very common process. I was an organization last week. I think they had four transformation initiatives underway at the same time. Organizations seem to love transformations. Can Ben approach this differently? Why? Well, the problem with this approach is, one, it's effectively a waterfall approach to change. It's designing the future based on what you know today. It's not a discovery process. So it's all designed in advance and the transformation is Big Bang. The other problem with the Big Bang is we go through pain. We go through the secure change model. We introduce the change and the first thing, we have a big hit. Productivity actually goes down for a while. So there's safety. There's how much productivity can we afford to lose. And then there's patience. How long does it take for us to recover? And then eventually we improve and get back beyond that. But this is a big challenge. Can Ben take an approach of evolutionary change? We start with the initial process. We evaluate the fitness of that process to understand it. Is it delivering what we want? We experiment. And if that experiment proves to be valuable, we start a new place and then we evaluate that against new fitness criteria. And we continue this process. And potentially we roll back when we realize the experiment didn't quite work what it wanted. We can roll forward and continue this process of evaluating and eventually we emerge to a new state. And this is all an evolving process. Very different than a transformational approach. It's an evolutionary approach. We're like water. Can Ben says to approach the world like water. You're going to hit resistance. Water goes around rocks. We approach going around the rocks. What's the around the rock strategy? It's our gain that we want. Not the big, big transformation that tries to blow through the rock. The result of this is that we have incremental changes. We have smaller safety bars. So it's a safer to fail experiment. And we repeat these continuously. We continue to evolve our changes. It's an ongoing process. The can Ben method is a method for improving service delivery. It's catalyzing improvements and evolving a business to be fit for purpose. It is not a project management method. It is not a software development life cycle process. And this idea that can Ben is for ops, scrum is for projects is just not the case. This is fake news. Can Ben can be applied to anything that's knowledge work. I've applied it. A lot of people have applied it to software projects. And of course we applied it even outside of software. Some of the service delivery principles. The way we see the world is an organization and network of independent services, of interdependent services and policies that determine the behavior. It's understood that the focus is on the customer's needs. We always are thinking in terms of what is the customer's real need here and then we manage the work and let workers self-organize it. Manage the work not the workers. Regularly reviewed the network and its policies to improve the outcomes. Always looking to outcomes, right? So what's a service? You think in terms of customer has some need. They request a product or a service. That's then a service delivery. How is that need going to be fulfilled? So that is the process that we explore. How can we look at that as a flow of what it is to that service and then the need gets fulfilled. In the Can Ben lens, we look at all work as flow. How does work flow through the system? We see the work flow as a series of knowledge discovery steps. Each time in the process of flow, we see knowledge discovery and that helps us evolve it. We see knowledge work as a service and then we see organizations as networks of service. So all throughout the organization. Then we look at the practices, the six core practices of Can Ben. Number one is visualize. That could be the stickies on the wall. Visualization is a very key element of what we provide in the Can Ben method. We also limit work in progress to make sure that we don't have too much ongoing at once. We stop starting and start finishing. That's because we want to manage flow. We want to keep things flowing through the system. If we keep pushing things into the system, we create bottlenecks. Instead we want to keep a constant flow that greatly improves our predictability. We make our policies explicit. Make sure people know how work is flowing through the system. We establish feedback loops. Cadences, perhaps, or means by which to provide this whole element of feedback loops is the essence of the learning. Through the learning we can evolve and improve. We improve collaboratively and evolve experimentally. Together we look at where we're at and we continue to look at how could we get better? What did we learn from the system? What did we learn from yesterday? What did we learn from the day before? How can we improve and continuously look to evolve our systems? Let's put that in a picture here. Since we like visualizing, this is a visual map. We've got ideas coming in. Ideas are coming in. We're filtering these through. Some things we're going to say are not economic. We don't want to overload the system. We're flowing ideas all the way from the beginning, from the customer possibility game of what's the present? What's the value to the customer at the end? The demand comes in. It's fed through to outcome. So we want to visualize that. We do that. The next step is to understand the system. What are we doing today? We go through a detailed process to try to understand what are we doing today and lay it out. That process is called static, systems thinking approach to introducing handband. So we identify services and for each service, we try to understand what makes this service fit for purpose. How is it working to deliver on the customer's needs? Then we want to look at what are the sources of dissatisfaction regarding our current delivery. Where is the upset? How is the customer? And then we're looking both externally and internally. How is the customer dissatisfied today? And how is the team and the delivery model dissatisfied? Where are all the stakeholders that are dissatisfied? Let's understand all of that because that source of dissatisfaction is very telling. We then want to understand and analyze the sources and nature of demand. The demand for this service, how frequently is it? Where is it coming from? Who is it coming from? We want to compare that to our current capacity, our current ability to deliver. We then want to model the service in every workflow. How is the knowledge discovery steps? How does that look like? What is the flow of the work? Are there classes of service? Do we have some work which we treat differently than other work? And through this process, we define the handband system. And that could, that will be our existing system. We define that and then what we do is continually iterate that and design experiments to get better. What we believe in the handband world is that in order to continuously improve our system, we need to understand it. So we put a lot of effort into understanding the system, designing it, so that we then can do the effort to actually start looking to how to improve it. So once we've understood the system, what are we looking? We're really focused on flow. Flow is a key element to handband. It's all about making work flow through the system. We always ask ourselves, what's blocking this? How can we improve flow? How can we get more things out of the door rather than pushing things in the door? We want to balance capacity and demand. We have tools that allow us to do that. Because if we balance capacity and demand, then flow will continue. We limit whip as another means to control flow. And we look at bottlenecks to see what can we do to de-bottleneck the system so that flow is even better. Then we're looking at scaling up. So as we're scaling up this is handband flight levels from Klaus Leopold. We've got operational team level. We've got coordination flight levels and then we have strategic flight levels. This is to say handband is scaling up and we can connect these through interdependent network of services. So then what we're looking at is how do we improve? Handband heavily relies on metrics. What are the metrics of the system telling us? We use this to help us incrementally improve our process. The other thing we do is to feedback loops from what we're delivering as we feedback that back through. So every time we're creating double loop learning here. Learning how to improve our process. Learning how to improve our products and services. So if we look at sort of where, what does it mean from the handband mindset? What are some of the things we're really emphasizing? Is it to me? I take away from it. I think we brought it up, someone brought it up earlier. A huge part of it is learning and evolutionary change. We want to learn and we want to continuously improve. It's a framework for continuously improving and evolutionary change. We focus on flow, we focus on visualization. These are tools that all enable us to really drive a continuous improvement mindset. What's available in the handband world, I know that South India skiing is not all that big of a thing. We try to get people to higher levels of proficiency in handband. So this is the different levels from a team handband level just to be able to get started down through a handband management professional and an advanced handband management professional. And then the highest level of handband coach where you're really able to go in and we're teaching the core principles of handband in order to start from first principles to get the most complex coaching situations addressed. We've recently come out with the handband maturity model. And the handband maturity model, the idea of the handband maturity model has some basis in things like the capability maturity model. But there's a couple of key elements that are very different. And I think I'll put it down in that spot that's in red. We're really focused on observable business outcomes. We're focused on the outcomes, not practices. We don't use the handband maturity model as a checklist. We're looking for what observable outcomes are you looking to improve. And we see this as a bit of a playbook of things that we've observed over many years of practices that and challenges that organizations have. There's two particular challenges organizations that we've seen. One is where they try to jump too far. They jump too far ahead. They overreach. So they're really in a very low maturity and they try to take on solving a problem which is way too hard for them. So that's overreaching. The other one is where they make a few changes and they feel oh we're doing great because we made a few changes but they've really plateaued. And the other thing with handband is we can take them even further. We can evolutionary change continuously and we can take them on to higher levels to the points where they'd be fitter for purpose with their business. Just a little bit. We have a conference coming up in Alexandria, Virginia. A number of different reports from these are the types of organizations that are using handband. There's also the leading handband India coming up in August 2nd through 3rd here. And then it's not too late. I do have a workshop coming up on this weekend on handband maturity or handband management professional. We've got plenty of time for questions. This is really just an introduction. Trying to hit sort of the highlights of handband and some of the things that the handband mindset means. And I'd love any sort of questions. Are there any questions? Hi Todd. Thanks for the session. So basically very basic question right now. A lot of people actually face this issue when they're able to go for Kanban or go for Scrum. A lot of people when they try to go for project implementation they will have a challenge of selecting Kanban approach or probably Scrum. So basic in terms of what are the differentiation, should we go with this or should we go with that? Can you just give your overview on that? I don't see it as a Kanban or Scrum approach. There are great things in Scrum and Scrum is an excellent tool in a lot of environments and that's perfectly fine. I think also Scrum is a place, we have this model of start where you're at. If you've already made a Scrum transformation and you want to continue to experiment with things there's a number of Kanban approaches that you can apply in a Scrum world and get continuous improvement from that point on. I think the nature is that we approach things from Kanban is wherever you're at you can start with Kanban. That's the nice thing about it. And so you don't have to make any big change. You don't have to make big transformational changes. You just have to put the effort in to understand your system as it is. So I guess I have to look at it as it's a different type of question. But I don't want to say there's anything, if you're finding Scrum is working for you you Scrum and work with it. And I've worked with all the coaches to understand enough about Kanban so that when you want to use some of the tools that are available in it and some of the different things, the different mindset elements of Kanban, they're available to you. Don't limit yourself. Thanks. One more if I may. If there is a team basically working specifically on a project and they have some opportunities and they have a team which is supporting for some sustaining kind of model where they are supporting an existing application and as well as they are working with new enhancement, new phases and all that. So they have few folks working on development areas, few folks who is supporting an existing application. So there has to be two models separately or one model will work for that team. So the Kanban approach to it, the straight Kanban approach to it would be to allocate that as two separate types of services. One service is delivery of enhancements and one service is maintenance activity, perhaps bug fixing or various minor things. That would be two types of services potentially with two classes of service and we would potentially allocate capacity to those streams differently. So that's the actual implementation whether you partition that out as two teams or whether you have one team and people go across different models. Kanban doesn't say a lot about how you do that. It says here's the tool. That's one of the things I think that's a bit of a difference in the Kanban approach. We are not very prescriptive in anything we say. We say learn your system and then use common sense to figure out how to apply it. So I've been in situations where my teams have had to do that situation where they had both. It's very common. You've got ongoing enhancements you're trying to do as well as maintain existing production. And I've used both models and both models in a matter of figuring out what works for the team. Sometimes you want to separate it in order to protect the enhancement activity to keep a difference between them. Sometimes that's not the most efficient way. Sometimes it's much better to allow the experienced people to know how to do it. The people that you want to be able to do some of the complex enhancements are also the people who are really necessary for certain types of maintenance activity. And so it's a matter of figuring out what the business need is, what the service need of the business is, and then what's the best way to apply that. Thanks. I thought there was one slide which was mentioning about the circles with the scrum, Kanban and... And I want to understand where exactly does lean fit into that. Not this. One of the starting slides. Yeah, it's early on here. Clicking back through it. We'll get there. This one. This is the one. So where does lean exactly fit into this? Because here it says okay, this is how actually people see. Yeah, so I think lean and I think for the purpose of what we're visualizing, lean is very similar. You could more or less say the lean is this similar circle here. The lean principles are much along the lines of what we're applying in Kanban. Lean goes outside of software. I think it's compatible. I think the important thing is it's compatible with the agile values and the agile mindset but it extends certain pieces of it in a different direction. So can you be more specific? So one of the things is the agile manifesto is a manifesto for software, fragile software. Both lean and Kanban go well beyond software. Now some people have taken scrum and other approaches outside of software but certainly we have had quite a bit of success in Kanban taking... Many people find Kanban far more... far easier to adapt in systems outside of software development. Because iterations, well, they work reasonably well in many types of software development. May or may not apply in other places. Now there's... so I think it's also some of the values that we're pulling in are coming from slightly different places as well. That's why we look at it as being beyond. You talked about the flow of work but we often have experienced that during development projects work is always not flowing. So different packets get blocked at different stages of the project while they are work in progress. So because of several reasons maybe dependencies among the team, technical blockages, et cetera, et cetera. So in such scenarios how Kanban will be effective? Yes, so the first thing we want to do... we have work and we're flowing it. So the first thing we want to look at is why is it blocked? What is it that's causing it blocked? What is it that's causing us to be delayed in our flow of work? So the Kanban approach is one is we ask that question all the time. We're continuously asking what's blocking flow? What's keeping this from flowing? If we find that the flow, the dependency or the delay is within our control then we act accordingly. If we find that the dependency or delay is outside our control then we have different set of things we want to do. But the approach is always to say we're going to focus on flow and we're going to keep asking that question until we understand it and we're not going to give up until we understand it and then we're going to go chase it. We're going to keep chasing it. So it's about asking the question and surfacing it first, asking the question and then figuring out as a team how do we organize ourselves and make sure this happens and gets dealt with. And then there's some of the tools we also have for visualizing how visualizing dependencies and oftentimes people set up swim lanes to show that something has dependencies and that means we manage it in a certain way. So it's all about identifying it and then being able to, from the identification, manage for it appropriately. And then recognize by it. The change principles, yes. Yeah, so we have some idea of where we may be wanting to head, but we're not trying to be very precise about that. But mostly what we're looking for is as we are today, what's the biggest change we could make that gets us somewhere? And what is it that takes us around the resistance? So we take small steps in order to both experiment, avoid as much resistance as possible, and get continuous improvement and continuous learning. So it really is not necessary to have a big picture of where you're trying to get to. It's more just having a commitment to wanting to continuously improve. That's a great question. In fact, that's going to be what the keynote at our North America conference is going to be about, is when is avoiding resistance the right answer and when is actually moving the resistance the right answer? And I think the quick answer to that is most of the time the avoiding resistance is the expedient and best approach. There are some times where you just have to do something and move the resistance eventually in order to get to the right place. There are some of each. You want to have it in your toolkit. The tool that helps you go around the rock and the one that helps you at least move the rock around and potentially adjust it. So there are different tools that take you to each approach. Actually I have two questions. The first question is more around the unit of work. So when we are in a new team as adopting let's say Kanban or Scrum or any other framework. So typically it takes a time for a team to understand and spread their stories or unit of work in a way that more or less all of them are of similar sizes. So how important is the similarity in sizes important when it comes to Kanban versus if we have a lot of stories or unit sizes which are like very IT, like a huge range. So that's a great question. How important is that the unit of work has the same size? The most important thing in order for the metrics to work out is not so much that the units are coming in at the same size as much as that the distribution at time one or time A is more or less the same as the distribution at time B. So if our range of stories that we're coming in with are from one to ten and they stay one to ten and more or less the same then the metrics will work themselves out as long as it's a fairly in that type of range is going to be fine. Now if it's a huge range then you have a little bit more concern about that. The degree of predictability will always be a little bit better the more similar they are. We can do a lot with a reasonable range of distribution. It doesn't have to be spending a lot of time to try to make them equally sized or anything like that. One more question. So this is around the scaled model where we have let's say multiple operational services getting overlapped into let's say one service in a scale model so how important are what are your thoughts on managing the flow like what are the best practices around the flow measurement and management in a scale model like this particularly around the measurement of flow how do you measure flow when there are multiple different type of services getting aggregated into one. Okay so multiple services being aggregated into one place how do you measure flow. So yeah so the there's multiple approaches to that one is we have the tool efficiency to indicate how efficient is work moving through the system and so that's an indication of active work versus work that's working in delay states. So that's at one service level. When you've got multiple of these things rolling up into one service you also you have that same behavior right it's just at one service can be delaying another service and so you have to look at how much active work is happening to that and how is that made the big service that you're trying to flow being impacted by those different delays. So it's more or less the same model right you're looking at active work versus delay work and what does that mean from flow efficiency and really as long as if you're getting flow efficiencies of about 40% or so that's usually considered not to be your problem but we also we often see flow efficiencies where there's lots of handoffs down in the well below 10% and then that's a real opportunity for improvement. I don't think it would need to. I think it's going to be okay you're looking at a high level and you don't want to get too carried away with precision and flow efficiency numbers you're just looking mostly what you're looking for in flow efficiency is whether you have a flow efficiency problem or not because if you don't have a flow efficiency problem doesn't say you're doing great work. You could have a totally different problem just means you don't have a flow efficiency problem. I rarely go beyond five and if there's a team and they has I mean there could be some items which are worth eight points. I'm talking about team which is using Kanban for development project but they are still using you know Kan, scrum related story sizing. I would like to avoid and have the team have a rule that point stories must be split as you know you have to have a serious template splitting that thing. It has a slight impact on the metrics also most of the metrics like humidity flow diagram, run chart and lead time distribution they will still work at item level but I usually do throughput chart based on story points so just to have a more meaningful you know data in terms of how many points are getting done per week or per month. Yeah and I think that's good. Like I said I think up to one to ten it's still stable but I think if you can get it down to one to five it's going to be more predictable. A bit more predictable at each agree. But sometimes you fool yourself if you think I'm going to make everything the same because at that point you're still guessing. Alright we can take one last question. So in projects like we do PI planning so we have like better forecast when we do the scrum and how about in Kanban like can we do like predict forecast when we do the Kanban model maybe three months or so or it's like only the BIP limit we have to get it. Yeah so the Kanban approach the main thing we want to try to do is collect data as quickly as possible so that we continually update the more data we have the more accurate our forecasts are going to be in the early stages we have no data it means our forecasts are going to be quite inaccurate it means we're basically using whatever we're using humans as the means of estimating and it's going to be very inaccurate we just don't have that data. Once we've got what we collected data and we have lead time data we have the ability to do much better forecasting a lot of the tools I was talking to they just introduced some forecasting tools within within Swift Kanban and it gives you very good indications as to you have an 85% chance that this item will be delivered within this time that's the type of approach we take we collect the data based on the data then we know what our probability of the forecast being accurate would be. And so that's what we try to as we increment through then we'll have a much better understanding and better position to have predictability. But early stages you're not going to be I mean you have no reason to expect high degrees of accuracy in early stages and we just fool ourselves in the past with other approaches. Thank you. Thanks everyone. We are running out of time. Thank you very much.