In this lesson, we're going to learn about a technical Kanban, which is a practice that was borrowed from [inaudible] production system. And basically, helps team 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 screen process. So we know how different it is. So in Scrum, we work in one to four weeks iterations. So In the first iteration, let's say one to four weeks, we will take part of the product, we'll define it, design it build it, and test it and then there will be some product that will come out of it. And then we will just continue that cycle until we are done, all right? As you can notice that the product changes over time. The style and the color is changing. That has 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 software development process as long as that process is a continuous flow. What do we mean by continuous flow? So by continuous flow, I mean like things from the backlogs are moving through this software development pipeline and its finished product is coming out at the other end of the pipeline. So, for example, the first item got done, then the another item, then a couple items. And as you can see, this is also an adapter process, where as things are getting completed, we can get feedback from the customer and feed it into the backlog but at 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 principle play. So let's say a team has a process where the work items goes 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 the situation. So first thing that Kanban suggest or the first property of Kanban is to visualize your workflow. So let's see how we are going to visualize the workflow. To visualize the workflow, you basically create a visual board. It can be an 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 will be in the doing, if it is done, then you will move it to the done sub-column. So once you create this board, then as you move each, as you work on each of these items, for example, let's say the team is working on post a new job, so then they will move the item to the analyzed because they're 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 that each item is. So let's see what the board is going to look like after a few days. So our board after a few days look like this. So, do you see any problem with this board? Well, if you see in the test column, there is lot of item pending, all right? So that is if we don't do anything right now, the items in the test column will pile up and will become a bottleneck, and it will slow down the delivery. So, how do you solve this? So, Kanban support another property called limit work in progress. So what you do is for each of your state, 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 and in the develop state, we can have only three items. 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 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 this WIP limits and they were following it, this situation won't have happened. So let's go back in time and see how this will flow if it was falling Kanban property. So let's say this end on tenth day, the board looks like this. And 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 only 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 like, what is happening? Why the things are not moving from test? Well, there could be many reasons. One reason could be that the code is very buggy or lay 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 test tip. So here developer can go okay, if there is too many bugs like, maybe I can do a better job and maybe fix it or if it is a resource issue, then I can help test one of those things and so that you can move it. So let's say the developer help them. So in that case, let's say sign up 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 card from one state to another state consistently. But everyone may have different understanding of the policies of when to move or not. So Kanban suggest another property called "Make Process Policies Explicit" which means, we define exactly, what are 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 to done. Similarly, in the develop state. So that gives a very clear understanding to the team members as to when they can move items from 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 the properties. The first principle is, start with what you do know. So as you saw, that we didn't really created a whole new process. We just said whatever is the current process, let's start from here. And then, we agree that as we are going to manage the flow, we are going to pursue incremental and evolutionary change. So slowly finding out where the roadblock is? Or where the bottleneck is? We're going to fix that. And then, respect the current process, roles, responsibility and it's titles. So, if somebody whatever roles 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 property is improve collaboratively. So, as you can see that 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 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.
