Transcripts
1. Welcome to the Class: Hello and welcome to the course on agile kanban. In this course, you will understand one of the most popular, a giant School of parts called Kanban. This course will teach you about Kanban principles and how Kanban can help you and your team to create a culture of continuous improvement. We will start with learning what Kanban is and how you can use it in your projects and teams. We will start visualizing a process flow through a simple Kanban board and then explored various forms of Kanban boards. We will identify various process flow related issues, including too much work in progress and the utilization of resources, unequal sized task, etc. Using simple and easy to understand demonstrations on Kanban board. We will not only identify these inefficiencies, but also soil for the same by continuously improving the process flow using Kanban board. We will also talk about the best practices to be followed by using Kanban to make the most out of it. So join this course today and incorporate the Kanban method of agile project management into your work style and deliver a great software. Now coming to who this course is for. This course is for anyone who has a passing familiarity with project management. On anyone who has a project manager, a member of a project team, honesty colder on a project team that's trying to be more adjourning or someone who doesn't have experience with formal project management approaches. But as looking for one noun, ought anyone who has just heard that dumb Kanban and want to know more about it. And you know what the best part is. No brian expedience is necessary to take this course. So even if you don't know what Kanban is and the various principles and concepts under Kanban and agile project management. Not to worry. We will cover each of the concepts from scratch. So why should you take this course from me? By way of introduction, I'm Monica Robert. I'm a software engineer, MBA marketing strategy. But more importantly, I have work experience in the real world from American Express, where I closely worked with software teams to manage multiple projects as a product manager. Now I am passionate about sharing my knowledge and experience. That's what has led me right here to you. I want you to thoroughly understand and enjoy this course so that you can be inspired to achieve all your career goals. I have the tools needed to get the job done. So let's do it. I'll see you in the class. Thank you.
2. Introduction to Kanban: Now let's begin our discussion on Kanban. Kanban is a very flexible and easy to implement method to do process improvement. In fact, I think that it is so easy that it should be the starting point for all the teams that are thinking of adopting the agile approach. And unlike Scrum, which has strict rules to be followed on Extreme Programming, which has strict practices. Kanban is very flexible and teams have a lot of scope of being creative. By implementing kanban. Simply said, Kanban is amazing and very easy to implement. Now let's understand what Kanban is. So kanban is a Japanese word, which literally means assign board or signaling using cards. It comes from the manufacturing industry. When Toyota, which is a Japanese car manufacturer, implemented Kanban to monitor the car making process and identified the steps which are the border links. From there, it has been adapted for software development and it has been similarly successful. So the idea of Kanban is this, visualizing the workflow to achieve process improvement. Let's understand this line in detail. The first part is visualizing the workflow. This means that there should be a clear picture of what steps and actions that are being taken by the team. By visualizing this, we tried to identify at which step we have inefficiencies or waste, and what are the steps at which flow is getting interrupted? Then comes the second part, which is achieving process improvement. There are several steps on practices that can men suggests to improve the process and achieve higher flow of walkthrough it. Some practices are like limiting the work in progress, on managing the flow, on implementing feedback loops, etcetera, which we will discuss in the subsequent lectures. But please note that these are just suggestions and not rules. The team can come up with any type of creative solution to the issues they identified vile visualizing the workflow. Now before I tell you more about Kanban and its practices, I think I should first show you how we visualize the process using a Kanban board. Once you understand this, all of the other things will make much more sense to you. So in the next lecture, we will look at Kanban board. See you in the next one. Thank you.
3. Introduction to Kanban Board: Hi and welcome back. In this lecture, we are going to discuss about the Kanban board. So basically, Kanban board is a tool that teams use to visualize the evoke flow. Now this can be a physical board on the wall with sticky notes being used to represent tau sonnet. Audit can be software based bore also. Like these days, a lot of teams creates such a board on GIS software. On this board, we create different columns for different steps involved in the development process. So as you can see on the screen, on the left-hand side, we have a physical board with sticky notes on it. And on the right-hand side, we have a Kanban board created on GIS software with various steps of the process defined in each of the column. And so in the first column we have the to-do list. Then we have in-progress, followed by quarter view and done. And within each step we have set of tasks to be performed. Now let's take an example to understand this further. Hence, this implicit form of Kanban board. Here we have segregated the task workflow into three parts. The first column is nor started, followed by in-progress. And then every task starts on the left in this column. When team starts working on it, the sticky note is removed from the first column and put it into the second column. And when the task is complete, it is moved to the last column, which is done. So this was a simple Kanban board which can work not just for projects, but for visualizing the personal tasks as well. Anyways, this is pretty basic. And if you really want to benefit from the Kanban board, you need to look at your process and meet columns showing exactly the process for your team. For example, here's a sample board with few extra columns, which you will relate to if you have ever worked in a development team. This board is from David Anderson's book called Kanban. In this board also, bulk items flow from left to right. There is an input queue which just calls out all the things on which the teams has to work. Once an item is picked up, each item undergoes this process of analysis, followed by development, then build ready, then testing, then release their DIE. Within analysis and development, we have fathers aggregation of in-progress and done. So there may be some tasks for which analysis is done by the development has still not started. So such task will reside in the Dunn section of the analysis column. Same goes for the development TAB. Please do remember that this is also an example Board. As mentioned earlier, each team is different and the process followed as a friend. And therefore steps in Kanban board for each team will be different. For example, here, suppose you have an extra step after testing and before releasing the teens to production, where your team presents the developed task for the business team or the business managers. And based on their feedback, some paths are sent back to the input queue, and some move forward with the release early-stage. If this is the scenario, then we need to add another column here for business review. And maybe bifurcate the input queue into new and send from review. In this way, it is important to create the right columns in the Kanban table exactly represent the process that is followed in your case. Once you do this, your Kanban board will start showing you the inefficiencies in your process. So that's all in this lecture. In the next few lectures, I will show you some of the inefficiencies highlighted by the Kanban board and some remedial practices employed in Kanban. See you in the next one. Thank you.
4. Finding Inefficiencies in the Process: Hi and welcome back. In this lecture, we will start looking at some of the issues that we may find in a process when we implement Kanban board. For the purpose of these cases, I'm going to use this Kanban board, which is quite similar to the board we saw in the last lecture. So the normal path for a task on this Kanban board, a new business request comes in. It it should yield as body priority. And it is picked and development takes place. There, developed product is tested. That tested product is then presented to the business managers. And if they pass, it becomes ready for studies. Then we also have a feedback. But if at the business review, some changes are suggested by the business manager. The task moves back to the first step and undergoes the whole process again. I hope you understand the flow of tasks here. Now let's see the first issue. Suppose you see a board like this for a lot of the days in a month. So I request you to pause the video here for a few seconds and let me know what does this board suggest? Ok, well, this board suggests that due to some reason, the flow or the testing step is not as much as it should be. The inflow is higher and the outflow is low. Now when you're working in such team, you would probably already have this feeling that a lot of the items are pending testing or the testing is slow, et cetera. But the Board calls it out clearly that the flow could be improved greatly. We do more testing. So this situation is called having too much WIP work in progress. In this situation, there is no point in doing more development or building as it is going to get stuck at the testing stage. So a clear suggestion is that more team members need to work on the testing stage instead of any of the previous stages. And when the team adjust to accommodate this task will start to clear up from the column. So in a way, the board is helping the team to identify which tasks should be picked up. You can also think about it and compare the situation for a non-adult team. A team member who works as a developer will keep on picking the development tasks. But a lot of these tasks may take a very long time to reach the final release stage. However, in an Agile team using Kanban, The team knows where to employ more resources to achieve better flow. Now there is a Kanban practice which insures that action is being taken before any steps gets cluttered. It is known as limiting the WIP. Let's understand this in detail. So in this limiting WIP practice, we said a limit on the maximum number of tasks that can be present in that column. Or that step at a time. If that limit is reached, that demon ensure that there is no further inflow into the step until the pending task in the step are cleared. For example, if I put a limit of six tasks on the step of testing. Now suppose 6 thousand ending here. We will stop all the development, build a time. Some of the tasks are cleared from the step. This ensures that the slope is not cluttered and the testing team is not overburdened. In this way, WIP limits can be set on all the steps. While it is not necessary to set it on all steps. But in my view, are deemed shoot said these limits on all the steps. Now the question arises, how do we decide what limit to set? Well, there is no magic formula that gives us this number. Teams have to set together, discuss, and come up with a number. Then slowly you can evolve it and improve it based on the experience and measurement of workflow. So that's all about WIP. Just to summarize, to prevent too much WIP, we said limits. And when that limit is reached, team adjust to clear and therefore improve the flow. So that solid is lecture. See you in the next one. Thank you.
5. Underutilization of Resources: Hi and welcome back. In the last lecture, we saw the problem of one-step being too slow and hampering the flow. In this lecture, we are going to see another type of inefficiency, which is under utilization of resources. Let's understand this through a Kanban board. Suppose you see a board like this. A lot of the tass R&D building step. And as you can see, that Testing step is empty. Now as these Testing step is empty, it is very to get Mohawk. Tasks are still pending in the previous step, and therefore they're not moving to the next step, which is a testing step. In such a situation, the workforce for testing will be underutilized. So basically the resources which are managing the tasks and the testing step and not getting the input flow as much as they can handle. Generally, this type of problem is not intuitively found. And that is where Kanban board helps. So if you see a particular column being empty most of the time, it is a sign that you have some underutilized resources which you can focus on minerals. So in both the issues, one which we discussed in the previous lecture and the other one which we discussed just now, there is a flow issue. At some steps work is flowing faster and some steps it is slower. And the way we handle such situations is actually called managing the flow. And just to clarify, managing the flow is not something that some manager will need to do. So this is something which is recognized by the team. When the team sees the flow issue on the board, the members themselves know what to work on next. And this is why Kanban is also known as a pull-based system. You must be wondering what is a pull-based system. So let me take an example to explain the differences between push and pull system and how Kanban is a pull-based system. So suppose there are several tasks to be done, such as developing a feature, some bug fixes, some documentation, et cetera. So in a push system, there will be someone. It can be a manager, audit team leader who will assign these tax to the team members. All you can see that the task will be pushed to the team members. But when you visualize the flow using Kanban or team member will look at the Kanban board, will immediately know where he or she is most needed and can pick up the most relevant book straight away. The person will be pulling the most relevant task out of the list of tasks to be done. Now since we are talking about pull-based system, let's also discuss the benefits related to it. The benefit of a pull-based system is added, optimizes a workflow. It reduces the lead time and most importantly, reduces the overload on the workers. And I also feel that people are more happy when they choose the work that they do. And sort of a manager locating the work to them. Just to summarize this lecture, the Kanban board highlights the flow related issues for the team. And an agile team can therefore adjust or do flow management to optimize a flow throughout the system. That's all in this lecture. See you in the next one. Thank you.
6. Unequal Sized Tasks: Hi and welcome back. In this lecture, we will discuss another type of issue. Suppose one day you see a bowl like this. Apart from the other task, there is this task number three, which is there in the building column. Few days later, you see that only other tasks have moved. But task number three is still sitting in the building column. And after few days later as well. You again notice the same thing. Now can you guess what this is suggesting? Well, this is suggesting that a task is taking longer time then it should a longer time than water usual task takes. There can be many reasons for this. Let's discuss a few of them along with their corresponding remedies. Firstly, since each task is the friend, there is a chance that this particular task requires more amount of work. But for your understanding, for Kanban to work properly, that is, if we want to get useful information from our board, we need to ensure that all tasks take about nearly the same amount of time and flow at a similar rate. This means that if there is a big task that has to be broken down into smaller size tasks. To do this, a common practice adopted is to add a new column in the beginning with the step 10m as scoping or analyzing or specifying where the main agenda is to create task of equal size for the rest of the flow. So the point I want to highlight here is that you should always remember that in Kanban, we need to ensure their tasks are of equal size. So this is one. Apart from this, there are other possibilities also. There is a chance that the person assigned to this task is blogged or needs help. Maybe there are some bugs or issues due to base the Vulcan stock. Maybe the person assigned got carried away and is inappropriately expanding the scope of the task. So reasons could be any, and there is no set practice to address such issues. However, a regular Look at the Kanban board highlight such issues. And then a giant team can then act accordingly to resolve it. So just to summarize what we discussed, if a task is taking longer time, then it should be. Then keeping regular track. On the Kanban board always helps. And if required, break down the task into smaller sized tasks. That's all in this lecture. See you in the next one. Thank you.
7. Marking the Task: Hi and welcome back. In this lecture, let's look at another type of issue that may arise in the development process. So this is the Kanban board of our example process where we have this business review step, where managers review the feature developed. If it is okay. It goes to the next step. And if it needs some changes, it goes back to the first step. So this back and forth creates a feedback loop. So there can be more feedback loops in the process you follow in your organization's. Feedback loops are important. They ensure the relevant business information is fed into the process and the right steps so that the fetus being developed are up-to-date and accommodate changes in market and competitive strategy. However, we must also realize that if a lot of items are sent back for revoke after review, the overall flow of the process will reduce. Whenever an item is sent back for revoke. The work done on it previously goes to waste. Plus 13 members need to work on it again. So this is clearly inefficiency which needs to be addressed. We need to ensure that items are not sent back for review multiple times. But how do we know that any item has been reviewed multiple times? When we visualize this on the Kanban board is to make a mark on that sticky note for the number of round. That sticky note is going back and forth through the process. Let's understand this through an example. So for example, when the node moves back for the first time from the review step, we are the single dot on mark on it to denote that this task has already been reviewed ones. Now this task will move forward through the process and again reached our business review step. Here. If the dusk again needs more changes, task will be again sent back from this review step. This time, we will add another mock to denote that this has been reviewed twice. If the data is sent back the third pane, you will add a third dot and so on. In this way, when you look at your Kanban board, you will know how many items are new items and how many items are there, which was sent back for review. So having these small MAC can help us highlight this issue. While we are at the topic of feedback and review, I want to discuss one more thing. As you would have experienced. Often the process of review in offices is not a daily thing. Managers do not sit and review the tasks every day. So what happens is that it asks keep on getting pilot for review. And when there are about 78 tasks to be viewed, a meeting as planned. To that time, these tasks are held up in the queue. So this also creates inefficiency and waste. The point I want to highlight here is that that the piling of tasks for review also creates inefficiency and waste. We need to ensure that such meetings happens frequently and regularly to minimize this waste. And violin on the other hand, having to frequent meetings also leads to inefficiency. So people often feel that they get less time to work when they have to attend many meetings. So the point I'm trying to make here is that you need to find the optimum WIP limit for your review step, which maximizes your throughput, thereby increasing your efficiency. So that's all in this lecture. I hope you found this useful. See you in the next one. Thank you.
8. Other Issues: Hi and welcome back. In this video, we will look at some other common issues that we faced during the development process. And how can kanban helps us identify them? The issues about which I will be talking about in this lecture are very case-specific issues. And you may not be facing them. Which is why I will not spend too much time on each of them. The agenda of the lecture is to show that Kanban board can be customized for different types of processes and monitor different types of probable issue. The first scenario we are going to discuss in this video is of having a lot of external dependencies. As you would have realized while working on a project. All projects have some level of external dependencies. For example, if you have a customer facing up all the text which the customer will see will probably need approval from the marketing team. And if there are n terms and condition mentioned, you will definitely need approval from the legal team. And many such approvals and reviews are required. So these are external dependencies. As the productive has very little control over these teams. However, the problem is not that these are external dependencies. Problem is that the team meets to do regular follow-ups with the corresponding teams. And if that is missed, the approval gets delayed, and eventually the project gets delayed. A simple solution to this problem is adding a separate column for dragging the dependencies, but this column at an appropriate position in the process. Please note there is no need of a WIP limit on this column. The team just needs to develop a practice of regular follow-ups on the task listed in this column. And if any task is sitting there for too long, the team member can escalate it to the appropriate levels. Now coming to the next scenario, which is also a common one, where our team is not only working on the product features, but sometimes the team has to make some important presentation. All demo for customers or some conferences comes up for which the team needs to spend time for preparation. While this is not directly product related work, but it is important work and a lot of time maybe spent on it. So how do we account for this time on the sign board? For that simply created a task for it, just like any other task. And it will also flow through the sign board. The point is that Kanban board should reflect where the team is spending time so that we can increase efficiency wherever possible. So in nutshell, Kanban board is deemed sport and therefore it should reflect all things done by the team. Similarly, there are some other tasks which are not directly related to product, but are to be done to improve the team's efficiency. For example, we may want to automate some operational task, or we may want to upgrade some tools that we use. Since the focus is on the product, these things never get picked up. So what we can do is we can add improvement task also on the board. This way, they will also get sufficient visibility and will get done just as other task. Another use of Kanban board can be in the recruitment process where we hired a new person and we are assigning work to this new joining. We can simply assign this person to the slowest step of the process. That is where the person will be off most use. And the person will be helping to increase the output of the process. So these were some of the cases I wanted to discuss in this video to show that Kanban is flexible to incorporate not just product related work, but other relevant tasks as well. That's all in this lecture. See you in the next one. Thank you.
9. Defining Done: Hi and welcome back. In this video, we will discuss about defining done. That is when to say that a particular task is completed. And here we are just not going to define done for the feature. We need to define completion of each step. Let's understand this through an example. See that we have a task a, which is in the building step. In order to see that step is complete, the developer first must know exactly what is expected from the developed feature and what is exactly to be delivered. Similarly, if we talk about the final feature, the final feature that is going into production that should match the customers are managers expectation. So as per Kanban, it is suggested that each column, or let's say most columns should have this bifurcation of in-progress and done. And it should be clearly defined that after doing What can we move our task from being in progress in that step to being completed or done in that step. When it clearly define what is done, the quality is maintained at each step. And therefore, the final outcome is of high-quality. 1 to be noted here is that when we say that a step is complete on a task, it does not mean necessarily that the dance moves to the next step. The password simplicity in the bank column of the previous step. Remember we talked about Kanban being a pull based system. This is what it is. Even if the developer has written the cord, does not mean that the task is now pending with testing team. Task comes to testing team when the testing team pulls it from the development step. So basically nobody pushes it on to them. It is their discretion and went to pick up the task. Another thing I want to highlight here, which you might be wondering as well, that do these two sub columns in progress and done have separate WIP limits. Well, as Kanban is flexible, it is your twice. But the general practice, which also makes more sense, is to have a single limit for the entire step. As long as the task is in that step, it should be countered against that steps work in progress. So in my view, do not have separate WIP limits for the sub column. Lastly, there are two practices that I want to highlight here so that the done rules are implemented properly. Firstly, it is a good practice to actually write these rules on some notes and have these nodes on the Kanban board. Secondly, whenever someone is moving a node from one column to another, another team member should check if the rules for done while met in the previous step or not. In an Agile team, the entire team is accountable for the quality of the delivery. Therefore, the team should check each other's work to prevent misjudgment or carelessness by one person to avoid any negative impact on the task of eater. So that's all in this lecture. I hope that you will be appreciating the importance of clearly specifying the done rules. I'll see you in the next lecture. Thank you.
10. Daily Standup: Hi and welcome back. Now that we have a board to visualize the process. That is wonderfully regular meeting prescribed by Kanban to make the most of this this daily meeting, It's called the daily standup. Islam also has a similar practice which is known as daily scrum. However, there are many differences between these two. And the reason for the differences is the same thing we have been seeing from the bending of Kanban, which is Kanban is flexible, whereas Scrum has strict rules. So when we say strict rules, it means that Scrum has rules on how long this meeting will be, who will be handling the meeting, and what will be discussed in this meeting. What Kanban has no such rules. So if the question in your mind is, who'd unsteady stand up, then any member can do that. Maybe everybody, a new team member gets the chance to random eating and bringing a new flavor to the meeting. Or maybe this job is assigned to the senior most person of the team. However, usually the project managers are seen doing this because this keeps them up to date on the status of all the task. And if there is some task which is blocked or some team members who needs help, they can do so. But as I said, it is team's choice. Who runs the meeting? The next question is, how long is this activity? Well, there is no fixed duration of this meeting. If the team is experienced, they can finish it up within five minutes. But a lot of times p members start discussing each other's work or even celebrate each other's successes. There is no harm. Even if the meeting takes 30 minutes. It only ends up in higher collaboration between the team members. Now lastly, what is to be discussed during the stand-up? Well, the team must move the sticky notes forward if they have not done it earlier. I mean, although these stickies should be moved whenever the task is done, but if something is missed, daily standup is a time to get the board up-to-date. Apart from this, team should try to identify issues. The kinds of issues were discussed earlier. The members can highlight if they are facing any problem in the Task. Two, these are the things which must be done. Apart from that, it is a product team on what they want to discuss. Just keep the focus on the board and try to add or get as much value out of it as possible. Now just before we close this lecture, let me point what daily standup is not. So daily standup is not a review meeting or demo of features built or discussion about the product, etcetera. You can have these meetings separately. Stand-up meeting as just a get together to see how the work is flowing through the process. So that fall in this lecture. I hope you found this useful. Thank you.
11. Specifying Rules: Hi and welcome back. In this video, we are going to talk about a very important thing that we must do when we are using Kanban. This is something that we do not have to do with Scrum. This is because of the great benefit of flexibility that comes with Kanban. The one drawback it has is that it does not have standard rules. So if you understand Scrum, you would know that it has very strict rules to be followed and the entire team knows about the rules. In fact, there is a special role call scrum master who ensures that everyone knows about the rules. But with Kanban, we do not have these rules. There is no set rule for when we should have daily stand up. Who moves the sticky note or when there is no kanban master. There may or may not be splints, sprint planning meetings, or sprint review meetings. So the point is, rules are not fixed and each team has to come up with its own rules for implementing kanban. And when you create rules, you must make sure that these rules are explicitly mentioned and everyone understands them clearly. Now this does not mean that the Kanban team has to write long documents specifying the entire process. Making policy explicit can be as simple as writing WIP limits on top of the column. And as discussed earlier, the team should define done. When a team diets that definition of done honest Ag and puts it on the Kanban board. That team makes this definition explicit. So any rule or practice you adopt as part of implementing kanban should be explicitly mentioned so that everybody is onboard. Now, since the entire team collaboratively creates these rules, you may think that this may not be really useful. But let me tell you one thing. It does help it. Suppose a manager or the boss is trying to push some work. If the WIP limits are explicitly mentioned and the manager has agreed with the policy of WIP limits. The team has solid ground that only if an existing job is taken off the list, then only the new job will find its place. So explicit policies not just helps within that Kanban team, but also helps in the interaction of the Kanban team with other stakeholders in the organization. So that's all in this lecture. Thank you.
Monika Rawat, Product Manager. Entrepreneur
