Understanding Kanban for Software Development.
Kanban is a method for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
This framework is highly productive and effective to run.
- Ad-hoc Requests,
- Unplanned works,
- Production Support
It’s a Method of Visualizing the flow of work. in order to balance demand with available capacity and spot bottlenecks
Quick History
In the late 1940s, Toyota found a better engineering process from an unlikely source: the supermarket. They noticed that store clerks restocked a grocery item by their store’s inventory, not their vendor’s supply. Only when an item was near sellout did the clerks order more. The grocers’ “just-in-time” delivery process sparked Toyota engineers to rethink their methods and pioneer a new approach—a Kanban system—that would match the inventory with demand and achieve higher levels of quality and throughput.
Kanban also spelled kanban, is a Japanese term for “signboard” or “Billboard” that indicates “available capacity (to work)”. Kanban is a concept related to lean and just-in-time (JIT) production, where it is used as a scheduling system that tells you what to produce when to produce it, and how much to produce. Kanban became an effective tool to support running a production system as a whole, and an excellent way to promote improvement. Problem areas are highlighted by reducing the number of kanban in circulation.
We will learn details about all these and how we can implement this principles, and its benefit later in this course. You can also watch the video tutorials to get a deep dive.
Principles Implementing software increment on Kanban Method is a pull-based system, that helps the team to continue the delivery in a sustainable pace, with in capacity. Its reduce waste of efforts and time. To Maintain this, It needs to follow the basic principles of Kanban as below.
1. Visualize Work Visual model of Kanban Board of work and its workflow to make the scope and capacity transparent, it helps to observe and Inspect the flow of work moving from backlog to do. This makes the work visible—along with blockers, bottlenecks and queues, and upcoming work, Which helps the team to make the strategy of working on exiting work or bringing new work in progress. 2. Limit Work in ProgressThe Team mutually defines a Limit for all “work in progress” Columns in Kanban Board, such as Analysis, Development, Testing, etc. This WIP limit implements the Pull based system, as work can be pulled to the current column from the previous column only if the total number of workers under the column is less than its limit. This helps balance the flow-based approach so teams don’t start and commit to too much work at once. It reduces waste and helps the team to focus on finishing first and starting later. 3. Focus on the flow of Work To Complete a work, and add a value it has to pass through multiple stages of its development phase. Like Analysis, Development, Testing, Review, etc. To get the effective benefit of Kanban the Team needs to focus on the flow of work from its initiation to completion. Following the above 2 principles helps achieve focus on flow. Focus on the workflow leads the team to visualize upcoming bottlenecks to act on. so that the flow remains. The team frequently makes a strategy of working on in-progress work items to optimize the flow
Relate Kanban with Real life
We already learn the basics of Kanban and its principle, lets try to relate the Kanban flow with Real life. Assuming you already know and practicing scrum, where we do Iterations of defined timebox. we commit bundle of stories, work on them for 2 to 3 weeks and complete the Iteration and again plan for new bunch of stories for next iteration. In Kanban, we don’t commit stories for iteration or time box, or sprint. we do it little differently. In the below example we will relate Scum and Kanban with real life. Lets assume the people are the stories a movie Theater is a Iteration, Show time is iteration
This Scenario explains the flow of people in a movie Theater a bunch of people at once. If we assume the peoples are user stories and Showtime as Iteration or time box. Then you may be able to notice that the group of people peoples is going to a Movie theater together and coming out together. We have a defined seat capacity and showtime. The people planned for each show is pre-planned before the show starts.
This Scenario explains the flow of people in a Public Park one by one permitted by the gatekeeper. If we assume the peoples are user stories, The Park is the Kanban Board. Then you may be able to notice there is no defined showtime of the park, as it is open 24 hours. The people going in or Roaming inside the park and coming out are not in a group. We don’t have the capacity and showtime. However, the management of the park decided not to allow more than 6 people at a time inside the Park, to improve the comfort of the people inside.
In this picture, let’s try to relate the scenario in Scrum terminology. If we assume the peoples are User stories, Then the people waiting outside the Hall for the future shows are lists of User stories in Backlog. The Active Move Theater show is the Active Sprint or Iteration. The People watching the Show are the Stories of the active sprint. The Showtime is the Sprint Duration. The Seat capacity is the Teams capacity for the sprint. The People who already watched the movie are the “done” stories from the previous sprints, those may have been identified as released or already deployed.
And here let’s try to map Kanban terminology with the above picture. Assuming People are the User stories or Tasks, The Park is the Visual Kanban Board. People Waiting outside in a queue are active Kanban backlog. Showtime is not defined, Max Capacity is unlimited, however, Management has decided not to allow more than 6 stories on the board. People already moved out from the park are ate completed user stories ready to deploy. The management is taking a count of stories coming out, to allow that many stories move in. No defined start or end date for the stories/people inside the Kanban board/park.
Summarizing the above two pictures and explanation in one picture, that explains the Scrum Flow.
Summarizing the above two pictures and explanation in one picture, that explains the Kanban Flow.
Kanban Board
Now Lets jump into the play. we got an fare idea of Kanban and its rules, principle. Lets start talking about how do we really implement that principle of Visualization of flow , Implement the WIP limits etc. You can definitely watch the video to get an understanding. I will try to explain it here also. Well, So to have the work visible and transparent to all, we need to have a board of works , it can be physical (better for co-located team). How ever now a days most teams are situated distributed location, So we can have a digital board. You can use you ALM tool to configure a board like that. Later this section you can browse through videos on different ALM tools like Jira, Rally, TFS etc to find out how Kanban can be configured and implement with in those ALM.
A Kanban Board typically has three main Sections
- Todo (or the Backlog)
- In Progress (The Work in Progress Area)
- Done (The Stories are completed.
Implementing Multiple WIP Columns
However to make the distribution of work, we normally distribute the In Progress work into multiple columns For Example, We can have Analysis, Development, Testing, etc. In the picture on the right, we have distributed the In Progress work into two sections Development and Testing. You can make the distribution as per your need and team’s comfort to have better control. This Distribution to more than one column always helps implement the WIP Limit for a different skill set.
Implementing WIP Limits
Limiting the count of Stories for Work in Progress Column is one of the core principle of Kanban. By implementing the WIP Limit, you will enforce the team to focus on the flow of stories from Left to right. In this example we have limited the number of max stories in Development as 4 and max stories for testing is 3. That means the team can work on max of 4 stories under development column and max of three stories under testing column. This Limitation will help the team to focus on finishing the stories first and then think about new stories to in progress.
For the image on right, we can see there are already 4 stories in development with a limit of 4 and 3 stories under testing with a limit of 3. So in this case even if the developer completes the development of 1 or more stories, They can not pick new stories from Backlog, as there is no room for new stories or tasks under development. To make room in the development column testers need to pull one or more stories or tasks from Dev to testing. and the Tester can only do that if they complete the testing of some existing story/task and move it to a done state. In this scenario, the Developer will not seat Ideal. They will contribute their efforts to tester and expedite the testing so the team can pull stories from development, and the developer can bring in new stories from Backlog. The Team members can mutually decide the WIP limit at the beginning based on the team size and available skill set. And this Limit is subject to revision after a certain period of time.
Split the WIP Columns.
It’s always a good practice of splitting the WIP Limit into two areas 1. Doing
2. Done This split will make the status of WIP more visible and prominent. And help the team to make their strategy.
Done state of the Left column is the backlog for the right column. For Example, The stories underdone state of Development are the backlog for testing.
Understanding the Pull Based System
As we discussed earlier, Kanban is a pull-based system. Implementing the WIP Limit, active the Pull based system. That means Thew team pulls a new task to its WIP column based on its current tasks and limits. Even if there are rooms in the current column, the team decides to pull a new story/task or finish the existing stories or tasks in the column. The below three-picture demonstrate three scenarios, where the developer or tester has the opportunity can pull a new story or task. To understand it better, please watch the video on Understanding Kanban System. later in his section.
Working with Beyond Control WIP
So far we have talked about Work in Progress like Analysis, Development, testing, etc. The execution under this column is always controlled by the Kanban Team. However, Sometimes the team wanted to have a column for other purposes, before moving it to do, for example, UAT. The work under this UAT column may not be controlled by the team, as the task or stories has to be executed by the end customer or client. If we implement a WIP limit for this UAT column, it will become a bottleneck for the team, as the stories from UAT to the next column may take time, depending upon the customer’s other priority of work and available time. To overcome this situation of bottleneck, we set the limit of columns like UAT to infinite. to allow the task’s free flow to this
Policies or Exit Criteria
If you have earlier worked on Scrum, you must be familiar with the definition of ready. which is a checklist we use to review our story before marking it as “Done”. For Kanban, we use a similar concept, that we call policies or exit criteria. and instead of having it at only before done. We prepare the exit criteria for all the done sate within each work in progress. As each WIP columns have two sections “Doing” and “Done”. we implement the gate for each story from done to do. So we will have a policy of Analysis done, another policy for Dev done, and another for Testing Done.
The example for a Dev Done could be
- All code has to be reviewed, and Review Comments should have been uploaded to some repository
- All code has to be checked in and Merged with the QA branch
- the Latest code should have been deployed to the QA environment.
- x person should have been notified by email.
- Unit test results should have been updated somewhere.
- etc.
The Team member mutually decides the policies for optimizing the work and performance and are subject to revision after a certain period of time.
Expedite Lane
During our Regular work and priority, we are often responsible and accountable for resolving production support issues with different severity. and much other high-priority activity comes on our plate from management with an immediate resolution. To work on those high-priority work by overriding the WIP limit, we keep a reserved Swim lane for all those kinds of work. and we call it Expedite Lane or Priority Lane. And reserve a number of tasks for that lane on top of each column.
In this example here, our Expedite lane can add 2 more tasks on top of the WIP limit of each column. So even if the Dev limit is 4 and the developers are already working on 4 stories, They can still pick additional two stories if any stories can classify as High priority or eligible to work on expediting base. Depending upon the frequency of those high-priority tickets, Issues, Tasks, and Stories the team member can define the additional limit of Expedite Lane. and that Limit is again subject to revision in the future. The Team can prepare a definition of eligibility to treat a work item as priority work. and classify the work as a priority item accordingly.
Making the Strategy (Class of Service)
So far you learned how to work on kanban to maintain a sustainable and optimized flow of stories and work items.
The Team always makes the strategy to finish first and start later, which means teams focus on working and finishing the already started work and then plan to start afresh work. with exception of any expedited work. To start a new work, you look into the backlog and found there is a number of work items available on the backlog or to-do list. so you need to make a strategy every day during stand-up, which item to start, and also which item you need to focus on completing faster, keeping the WIP limit in time. To simplify the strategy we categorize our work items into 4 different areas or classes of service, as below.
Normal The Regular as usual stories or work items.
Expedited The High priority work items like the Severity of one Production issue. This goes on Priority or expedites lane.
Time-Bound Stories have a fixed completion date. Sometimes Penalty clause is associated with this kind of story. In case the business needs something on or before some specific date and is available on backlog way in advance. the team can make the strategy, to bring the work item in Progress accordingly.
Intangible
These are the work items, which do not add immediate value to the business but have long-term benefits. most maintenance work falls under this category. Examples could be, Database migration from Server A to Server B, Re-indexing the database. Getting backup of production date to test environment.
By categorizing the source of work in the above four areas, you will be able to optimize the flow and pull work items into work in-Progress as it best fits your business need. If your ALM tool supports making separate swim lanes, you can create it accordingly, however even if it does not support or you are using a Physical Kanban board, you can color code the story or tasks for different categories of work. I will try to explain this in my video tutorial on ALM tools. All the video tutorials are at the bottom of this page.
Benefits of Kanban
Kanban is useful and beneficial if you use it to cater the work items that best fit for Kanban. like Production support, Adhoc Requests , unplanned work, portfolio or program level works etc. Few of its important benefits are mention below.
Planning flexibility
A kanban team is only focused on the work that’s currently in progress. Once the team completes a work item, they pull the next work item off the top of the backlog. The owner/stakeholders are free to re-prioritize work in the backlog without interfering with the team, Any changes outside the current work items don’t impact the team. As long as we keep the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business.
Shortened cycle times
Cycle time is one of the key metrics for kanban teams. Cycle time is the duration of time a story/work unit takes to travel through the team’s workflow–from the moment work starts to the moment it is finished. By optimizing cycle time, the team can confidently forecast the delivery of future work
Reduce Roadblocks
Multitasking kills efficiency, That’s why a key principle of Kanban is to limit the amount of work in progress (WIP). Work-in-progress limits help visualize bottlenecks. And the team unitedly jump into resolving the roadblocks to get the flow enabled.
Continuous delivery
CD is the practice of producing work results to customers frequently–even daily or hourly. Kanban and Continuous Delivery complement each other because both techniques focus on the just-in-time delivery of value.
Visual Metrics
Kanban System is known for its visual workflow, so the metrics like Cycle time, Throughput, etc, give en-reach transparency of the current flow, performance, and improvement opportunities to act on. We will talk about its different metrics in our later on this page.
Scrum Vs Kanban
Assuming you are already familiar with Scrum, here are a few differences between Scrum and Kanban
SCRUM
KANBAN
Cadence / Delivery
Regular Time box in Sprints
Continuous Flow
Release Frequency
At the end of each time box or later
No defined Roles except for the development team, Some teams consult with Agile Coach
Roles
Scrum Master, Product Owner, Development Team
At the end of each time box or later
Key Metrics
Velocity
Cycle Time, Throughput, Cumulative Flow
Scope
Scope planned at Sprint Planning, in a batch with a bundle of works
Works pull into the system, one by one
Change Mechanism
Scope planned at Sprint Planning, No Changes allowed mid-sprint
Changes can be made at any time.
Applicability
More appropriate in situations where work can be prioritized in batches that can be left alone
More appropriate in operational environments with a high degree of variability in priority
Kanban Metrics
Cycle Time
When your stories or work items travels on kanban flow, from first stage to last stage, its flows through multiple stage. Its stays within one stage for a longer time or shorter time.
We calculate the cycle time of a story by calculating the time between
It entered the first WIP column. and leave the last WIP column in control (UAT is treated as Out of control WIP). It should be calculated based on the team spent actually working on this item, not how much time it was on the board. In this example on right, the total time a story or work item spent in Development and Testing is the cycle time of the story. We don’t calculate cycle time for those stories which are still in progress or not started. We usually take an average of all the eligible stories’ cycle times to calculate the team’s cycle time for a given period.
Lead Time
This is similar to cycle time, but the only difference is, that it gets calculated from when the work item/story was created, or requested by the client and the time when it was delivered to the client. This time is also called Customer lead time. From the example on right, the lead time is getting calculated as the time between a story entering into the board and leaving the UAT column (Done means delivered to Customer). We usually take an average of all the eligible stories’ lead time to calculate the team’s cycle time for a given period.
Response Time
This is again calculated as the time a story/work item waited on a to-do list. The time between it was created and got the first Response by moving it to In Progress.
Throughput
Throughput is not a known measurement metric. This metric is the number of stories completed in a given time frame, Week, Month, etc.
Completed means the stories/work item completed or delivered to the client. It’s real data, not on assumption or prediction. Throughput is the number (count) of stories or work items that the team is capable to deliver in a given time period, e.g. week, or month, provided that they keep a bearable workload. It’s not a Velocity (velocity calculates on Story Point per sprint, usually measured on Scrum or XP framework) Throughput calculates on Count. The Kanban system doesn’t refer to estimates or plan. However its use for measuring the performance of the team and utilization of Kanban to improve. There are many interesting formulas we must learn on throughput, I will talk about some formulas and little’s Law, in some other article. Remember: The higher the Throughput, the shorter the Lead time
Cumulative Flow Diagram
A cumulative flow diagram is one of the valuable metrics to visualize the health of Kanban flow. It gives the view of cycle time, Lead time, and Response time, in addition to the benefits of WIP limit results. A cumulative flow diagram is a multi-layer Area chart, that represents different colors of stages on the Kanban board. The X-axis denotes the time (plot on the latest week, month, etc). And the Y-axis denotes the number of stories on each stage. The CFD (Cumulative flow diagram) for Kanban shows the one or two stages (Left most stages on the board) at the very beginning of the project, and after a couple of days, its shows the story count from stages on the relatively right side. That’s natural because we start our work from analysis then development then review then testing order. The CFD diagram always goes up from left to right. As it always adds the current day’s work-item count under any stage with the previous day’s count of that stage. That is why the name is “Cumulative’. You will notice the color of Stages that don’t have a WIP limit keeps on increasing on their width, while the color of the stages that have WIP limits is relatively consistent on their width. From the below-mentioned picture, you can notice how the Cycle time, Lead time is calculated, and WIP areas are calculated. To understand better on CFD diagram, please watch the video Understanding Kanban. I have explained the Kanban Metrics in detail in the later section of the Video.
Videos on Kanban
Understanding the Basic Concept of Kanban
.
Configure Kanban Board in TFS
Configure Kanban board in Rally.
Configure Kanban Board in Jira
For more posts like this follow Agile Digest social Pages or subscribe our newsletter:
Wesbite: https://agiledigest.com/
Facebook: https://www.facebook.com/agiledigest/
LinkedIn : https://www.linkedin.com/company/agiledigest/
Youtube: https://www.youtube.com/@AgileDigest
