In this lesson, we are going to learn about a technique called Kanban which is a practice that was borrowed from Toyota's production system. And basically helps teams optimize their software development process. So, let's take a look at what Kanban is. To understand Kanban, let's put it next to a Scrum process, so we know how different it is. So in Scrum, we work in one to four week iterations. So, for in the first situation, let's say it's one to four weeks, we will take part of the product, we'll define, design it, build it and test it, and then there'll be some product that will come out of it. And then we will just continue that cycle until we are done, right. As you can notice, the product changes over time. The style and the color is changing. That is to reflect the adaptive nature of Scrum. Which means that as we complete each of these cycles, we may get feedback from the client, and we may change what we want to build. Now Kanban doesn't prescribe any of these fixed iterations or any new practices. It's just a set of properties and principles that help optimize the software development process as long as that process is a continuous flow. What do I mean by continuous flow? So by continuous flow I mean like things from the backlogs are moving through this software development pipeline and the finished product is coming out at the other end of the pipeline. So, for example, the first item got done, then another item, then a couple items. And as you can see this is also an adaptive process where as things are getting completed we can get feedback from the customer and feed it into the backlog. But, in the end, we get the whole product. And so Kanban basically then optimizes the software development pipeline by a set of principles and properties. So let's see how these properties and principles play. So let's say a team has a process where the work items go from Backlog, to the Analysis, or Analyze, then Develop, then Test, and then to Release. And we have asked this team to build a job website. And which has these features. So let's apply Kanban to this situation. So first thing that Kanban suggests, or the first property of Kanban is to visualize your workflow. So let's see how we're going to visualize the workflow. To visualize the workflow, we basically create a visual board. It can be electronic, or it could be a physical board. And, you move all your columns, or all your states, or all your steps of your process into one column. And then, in some columns you will see Doing and Done. That means if the item is being processed or being analyzed, then it will be in the Doing. If it is done, then you will move it to the Done subcolumn. And so once you create this board, then as you move, as you work on each of these items, so for example, let's say the team is working on "Post a new job". So then they will move the item to the aAnalyze, because they are doing the analysis. And then let's say they started analyzing the create profile, also, so they'll move it to the analyze. And so on, so as the work is being done, the work item is moved on the board to represent where each item is. So let's see what he board is going to look like after a few days. So a board after a few days may look like this. So, do you see any problem with this board? Well, if you see in the Test column there are a lot of items pending, right? So there is, if you don't do anything right now. The items in the Test column will pile up and will become a bottleneck, and it'll slow down the delivery. So how do you solve this? So Kanban supports another property called Limit Work in Progress. So what you do is, for each of your states. You define, what's the maximum number of items that can stay in that state? So for example, in this case in the Analyze state we can have only one item. In the Develop state we can have only three items. So, so far in the Analyze state and in the Develop state we are good. Because we have only one in the Analyze and we have two in the Develop. So, so far so good. But then when we look at the Test, the limit let's say we set as two. So we have four items, so that is a no-no. Like it should not happen. So if the team has the WIP limits and they were following it, this situation wouldn't have happened. Let's go back in time and see how this will flow if it was following Kanban properly. So let's say on the 10th day, the board looks like this and the developer just got done with "Make payment" and they want to pick another item from the Analyze. So can they move "Update job" into the Develop column? No, because the number of items in Develop are already three and the WIP limit is three. So the WIP limit calculates both doing and the done. So we cannot move update job. Well, maybe we can move the "Make payment" and "Login" into the Test because they are done. No we can't because the test column also has a WIP limit of two and we already have two cards over there. So in this case, what developers are going to do or the team is going to talk about is, what is happening? Why are the things are not moving from Test? Well, there could be many reasons. One reason could be that the code is very buggy, or there are a lot of defects, and so that's why it is taking a lot of time. Or they may not have enough people in the testing. So here, the developer can go, okay, if there are too many bugs, like maybe I can do a better job and fix it. Or, if it is a resource issue, then I can help test one of those things so that you can move it. So let's say the developer helps them. So in that case, let's say "Signup" was done, and then we'll move it to Release. Now, the Test column has only one, so now we can move the login into the test column. Now, the developer can move the "Update job" into the Doing column and they can work on it. So look, we sorted out the flow issue by collaboration and working with each other. Now, if this is a temporary situation, this is perfectly fine, you don't need to do anything. But if it is a permanent problem that will happen again, then you want to manage the flow. You want to fix it permanently, and that's where comes the property number three, which is Manage the flow. So we want to find out if it is a permanent resource issue, then add more people to the Test. Or if it is buggy code, then what can we do in the development so that we don't have that many defects, and then it moves faster. So whatever you do, but you try to manage your flow. Now this board will work good only if team members are moving the cards from one state to another state consistently but everyone may have different understanding of the policies of when to move and not. So Kanban suggests another property called make process policies explicit, which means we define exactly the word of the policies that the team will follow. So one example could be the definition of Done for each of the states. So the definition of Done would be when can I move ... when is something done? So for the Analyze phase, when the "Update resume" is done, well when we have requirements defined or whatever we need to be done for that story to move from Doing into Done. Similarly in the level of the state. So that gives a very clear understanding to the team members as to when they can move items for one state to another state. So here, we just went through some of the core properties of Kanban. But there are a couple more principles and properties that are defined in Kanban. Let's look at those. So Kanban defines three principles and five properties. We already talked about the four properties, so let's talk about the principles and one of the properties. The first principle is Start with what you do know. So as you saw, we didn't really create a whole new process, we just said whatever is a current process, let's start from here. And then we agreed that as we are going to manage the flow, we are going to Pursue incremental, interval, evolutionary change. So slowly finding out where the roadblock or where the bottleneck is, we are going to fix that. And then Respect the current process, roles, responsibilities, and titles. So if somebody, whatever role people had or whatever titles they have, they can continue to have that. We change it only when we find an issue with the current flow. And then one of the properties is Improve Collaboratively. So as you can see, when people find problems, they have to work collectively or collaboratively. Like everybody has to know what are the constraints, how each of the process works. So if they have a shared understanding of what the process is and how it works, then they will be able to have meaningful conversation and fix the issues in the flow. So that's Kanban.
