Kanban core practices - Yash-777/kanboard GitHub Wiki

Core practices

An organization, in the process of embracing Kanban, must put into practice the following core practices. This would help them in successful Kanban implementation.

  1. Visualize the workflow
  2. Limit workin progress
  3. Manage flow of work
  4. Make the process and policies explicit
  5. Implement feedback loops
  6. Improve collaboratively

Let us now understand the core practices in detail.

1.Visualize the workflow

The product support and maintenance team (PSM team) of eGarb is trying to broadly classify the type of tasks they need to execute.

Issue Fix (IF): Issues in the eGarb live application needs an instant fix before they disrupt service at larger scales

Feature Fix (FF): These are changes to be done in an already existing feature of the eGarb live application to cater better to business needs. Once ready, the older version is replaced with the latest version of the feature.

New Feature Idea (NFI): Ideas from customer for minor enhancements are to be developed and incorporated in eGarb. New feature development would be incorporated by the development teams and that would follow the Scrum route.

Ben, the Lean Agile expert, sits with the PSM team and arrive at the following as the initial step in performing the above tasks.

  • The workflow and the workstages involved
  • Work items involved
  • Suitable Kanban board / boards with its columns and lanes

He explains the structure and use of the Kanban board. Let us look at the components.

A Kanban board is used for visualizing the workflow. The components of a Kanban board are as given below.

Workflow– It represents the activities-sequence across different stages, needed for the work completion. Different types of tasks can go through the same workflow even if it takes skipping some intermediate stages.
Workstages – Each stage in the workflow where a certain amount of progress in the overall work to be done is achieved.
Work items – The task to be done flows across each stage referred to as work items under each stage.

A sample Kanban board is seen as below.

[]Diagram

Workflow: Backlog -> Workstage 1 -> Workstage 2 -> Workstage 3 -> Done
Workstages: Workstage 1 (In Progress), Workstage 1 (Ready), Workstage 2 (In Progress), Workstage 2 (Ready), Workstage 3, Backlog (Arrival Queue), Done (Finished Stage)
Work Items: Work items belonging to two types of tasks (Type 1 and Type 2)
Columns: Each workstage is depicted as a column in the board

In eGarb context, Ben holds discussion with his PSM team and ask them to visualize their workflows. They come up with the following workflow stages for the various issues.

Workflow for

Issue Fix (IF):backlog -> code -> test -> quality check -> release
Feature Fix (FF):backlog -> design -> code -> test -> quality check -> release
Minor enhacements(new feature idea) (NFI):Backlog -> design -> code -> test -> quality check -> release

It may be observed that all the types of tasks (IF, FF, NFI) use the same workflow. The workstages involved are also common viz. Backlog, Design, Code, Test, Quality Check, Release However, IF is seen skipping the ‘Design’ workstage in its workflow.

A snapshot of eGarb’s Kanban board looks like given below.

[]Diagram

The following observations are made from the above Kanban board. 3 types of tasks being dealt with in the board – Issue Fix(IF), New Feature Idea(NFI), Feature Fix(FF)
Columns in the board – Backlog, Design, Code, Test, Quality Check, Release
Work Items – IF-X, NFI-X, FF-X (X is the number denoting a particular task)

The team have thus visualized their work by identifying the workflow stages for executing the different types of tasks possible in eGarb application. This is represented using a Kanban board.

Practical tips Kanban board is a visual representation of the work stream, hence represent tasks and workflow clearly

Since it is a highly visual and transparent approach, it boosts motivation and engagement in the team

You may use different colors to depict different types of tasks

It could also be based on name of team member, type of activity, task sizing or priority

2.Limit workin progress

Once the workflow has been identified, the next step is to provide limits on the work items that can be accepted at each workstage present in the workflow. Let us understand the need and the impact of doing this.

On observation and in discussion with the PSM team, Ben understands that the team frequently fails to deliver as they are expected to. On analyzing the situation further Ben learns the following:

  • team members are technically competent enough
  • teams over commit beyond their capacity
  • lot of work items flow across the board but not as many reach the release state

WIP Limits

A workstage in the work flow can be given a number as the ‘WIP Limit’ that indicates the maximum number of work items that can be present in that workstage at any given point of time.
The following points are to be noted regarding WIP limits.

  • It can be different for different workstages in a workflow
  • The value provided for WIP limit can be revisited as it continuously gets refined
  • The initial stage (ex: arrival queue, product backlog) and the final stage (ex: release, done) usually does not have WIP limits
  • The initial workstage may need a WIP limit if there is planning involved on how many items to be picked up for execution
  • The final workstage may need a WIP limit if the release is manual and the team’s capacity to handle release

To help the situation, Ben decides to introduce WIP limits to workstages as appropriate.

Arriving at WIP limit

WIP limit of a workstage can be relative to the team size and competency involved in executing that workstage. There is no ‘Perfect WIP limit’ that is possible but only an ‘Optimal WIP limit’. Why can’t WIP limit just be a high-value or low-value number? Let us understand the merits and demerits involved in having a high and low WIP limit.

Higher WIP Limit: Table

Lower WIP Limit: Table

Having understood the merits and demerits in choosing a high or low value number as WIP limit, it becomes essential to choose a reasonable number as WIP limit.

Example: The sample Kanban board with WIP limits introduced is given below.

[]Daigaram

Observations from the board:

The backlog and done workstages doesn’t have a WIP limit

WS1 has WIP limit of 5 – this is inclusive of WS1 In Progress and Ready
WS2 has a WIP limit of 3 and since there are already 3 work items present under WS3, it can’t take any more until a work item moves on to the next workstage
WS3 has a WIP limit of 2 and can take one more item at this point of time

3.Manage flow of work

A workflow is said to be ‘good’ when it moves steadily and is also predictable. A consistent flow of work is essential to ensure transparent, faster and more reliable delivery thereby bringing greater value to customers, team, and the organization.

The following are the key metrics that can help in measuring the Kanban system so as to improve it.

  • Work In Progress
  • Throughput
  • Queues
  • Blockers
  • Lead Time
  • Cycle Time
  • Cumulative Flow Diagrams

Work In Progress

What? – Work In Progress is the total amount of work that has been committed but not been completed at a given point of time. How? – Work In Progress can be calculated by arriving at the total number of work items under each workstage between initial and final workstages. A work item under initial workstage has not started yet and the one under final workstage has been done. Hence these two are excluded in the count. Note: WIP can be evaluated once a week to keep track of the performance and accordingly make corrections.

Throughput

What? – The average number of work items processed per unit of time How? – The average count of work items processed per hour / day / week / customized period is measured as throughput. Note: Throughput being an average value that is computed, predictions can’t be made based on throughput alone. It can be see more of a trend than prediction.

Queues

What? - Queue length is the number of work items present under a workstage at a given point of time. How? – Work items add up in each workstage so that it can be processed and move on to the next workstage Note: Queue length is directly proportional to the time it takes for a task to be accomplished. Hence queue length should be kept as minimal as possible.

Blockers

What? – Blocker is a work item that could not proceed further in the workflow as it has some external dependency or a failure condition. How? – Blocked work items are visually distinguished and represented in a Kanban board. The number of blocker work items in a board can be counted along with arrival time of each blocker item in order to know the time the blocker item has spent in the workflow Note: Measuring blockers can help significantly in improving the reliability and stability of the work items through the workflow.

Lead Time

What? – The total time taken by a work item to move through the entire workflow. How? – The time difference between the point of time at which request was made by the customer for a task and the task outcome was delivered to the customer, sums up the lead time. It includes the process time and the wait time spent by the work items in the queues of different workstages. Also the time it had to wait before it was pulled by a work stage for processing, is also included. Note: Knowledge of lead time is critical to come up with more accurate predictions of time the tasks brought by the customer. The average waiting time involved in executing a task is a very critical factor to be considered.

Cycle Time

What? – The time taken by a work item to travel between any two points as part of the workflow. How? – The time difference involved in a work item traveling from one workstage to another workstage in the workflow is referred to as the cycle time. Different cycle times are possible in the same workflow depending on the workstage that we consider for arriving at it. Little’s law formula for Cycle Time = Work In Progress / Throughput Note: Cycle time is an indicator of the delivering capabilities of the teams involved in workstages.

Cycle Time = Work In Progress / Throughput 1000/60

Work In Progress: The total number of work items present under each stage = Design(2) + Code(2) + Test(3) + Quality Check(2) = 9

Throughput = Work In Progress/ No.of tickets Answer: (10+7+11+15)/4 = 10.7

4.Make the process and policies explicit

The next core practice necessitates making the processes and policies explicit so that the stakeholders can abide by it.

The eGarb support team in its course of work, come across the following situations that were not as expected by them.

  • The WIP limit of ‘Code’ workstage was breached very frequently – every other day
  • Few work items continued to remain in the ‘Test’ workstage for a prolonged period of more than 2 days
  • There was a visible restlessness developing with the customer whenever such breaches and delays happened

Ben, understanding the gravity of the happenings, decided to meet the customers and discuss with them so that what to expect can be made more clear. He str

Process policies

Kanban being a continuous flow methodology, it is a good practice to allow the team to decide on the most suitable yet effective way to keep the work progressing towards completion. The team makes the decisions together to further publish them as process and policies. Making these explicit, helps the stakeholders understand what is expected thereby reducing confusion and also leading to greater process consistency. As the team evolves and grows, process policies can be revised and improved to make it synergetic components of effective teams.

Answers to the following sample scenarios, can help in forming the process policies.

  • A feature has been coded. How can it be made QA ready with minimum rework?
  • When a team member is stuck with a blocker, who needs to be informed? How will the team member attempt to resolve the blocker? Should they wait idle or start working on another thing?
  • Customer sends an ‘Urgent’ feature to be addressed through the sales team. How does the team handle it?
  • How does the team share priority among different types of work that they need to focus on?
  • Items are piling up in the backlog. Can they pile up and who would be able to control it?

To answer these questions and more of this kind, the whole team can be allowed to give inputs and become part of policy process framing. With explicit and visible process policies, it becomes easy for any team member to sync up with the rest of the team. Stakeholders would also understand not just the objectives but also the means and ways of achieving it.

Critical components - Bottlenecks Following are the critical components in framing process policies.

  • Bottlenecks
  • Expedite Lane
  • Personal Kanban

Bottlenecks: Work items are expected to move across the Kanban board seamlessly. But, when work items get clogged up anywhere in the board, it is imperative that there could very well be a bottleneck that is causing the clog.

![]Image

As seen in this board, the workstage WS-2 is a bottleneck as work items are not flowing past WS2. Work items from WS2 cannot move further as the subsequent workstage WS3 has already reached its limit. At the same time, WS2 cannot pull more items from WS1 as WS2 has also reached its WIP limit.

Handling Bottlenecks

Possibility #1

The bottleneck is only in WS-2. Hence two more items can be pulled from backlog to WS-1 so that there could be some progress in work to be put forth.

Not recommended: This possibility is not recommended as it would only start too many things rather than taking things to completion.

Possibility #2

Increase the WIP limit of the blocked state to a higher number for a brief period of time, so that it can take more work items under it and keep things progressing.

Not recommended: Increasing the WIP limit can only be a temporary solution and the problem can reoccur soon after the WIP limit is set to its original value.

Bottleneck mitigation strategies

The long term solution to avoid bottlenecks would be

To refine the workflow by adding/removing workstages thereby making the workflow more stable, if required.

To re-define the WIP limits of the workstages in such a way that it reduces the chances of bottleneck occurring.

As seen in this board, the WIP limit of WS1 has been revised to 4 from its old value 8. Likewise, WIP limit of WS2 has gone back to its original value 2 from the temporary value 6 considered in possibility #2.

With the revised WIP limit values, the workstages are expected to be more stable than ever before and not run into bottlenecks.

Critical components - Expedite Lane

When there are different typed work items flowing across a Kanban board, the significance and hence the urgency of work items would also vary. Hence it is mandatory for the team to be able to segregate inflowing work items, prioritize it and handle it accordingly inside the Kanban board.

To facilitate this, the concept of swim lanes are present in Kanban board. Though swim lanes can be customized according to every project’s need, it is generally recommended to have an ‘expedite lane’ or ‘fast track lane’ and a ‘regular’ or ‘normal’ lane. Any high priority items or escalations can be handled in the expedite lane.

When items are taken up in the expedite lane, the work in progress in the regular lane are put on hold, WIP limit is breached if needed and the critical work items are attended to.

![]Critical components - Expedite Lane Diagram

In the above board, there are two lanes in use – Normal lane and Expedite lane. The expedite lane can be used to handle high priority work items.

It may also be noted that the WIP limit of WS1 has been breached since expedite lane items had to be accommodated.

Critical components - Personal Kanban

Kanban at an individual level is referred to as Personal Kanban. Every team member, in his individual capacity, can define WIP limit that conveys the maximum number of threads that the team member can parallel work upon individually. When it gets beyond this limit, it becomes difficult for the individual to pay attention on any of the work threads.

As an individual, if one is matured in setting his individual Kanban, then more meaningful contribution can be made by the team member to the team

Bottleneck - Example

eGarb – process policies

Ben, the lean Kanban coach, observes the workflow and the movement of work items across the Kanban board. It is understood that the bottleneck occurs in the ‘Test’ workstage. On analysis, the WIP limit of ‘Test’ workstage is redefined to 2.

Also to handle, escalations and urgent features, an expedite lane was introduced by Ben and any work item that landed in expedite lane was given the highest priority with all other ongoing work being put on hold.

A policy process was introduced including the following clauses.

  • The WIP limit of any workstage can be breached once in a week for the initial one month duration. Post this period, there would be a discussion to set future directions on this.
  • Whenever a work arrives in the expedite lane, it has to be instantly acted upon even if it warrants a WIP limit breach
  • No work item can remain ‘blocked’ for more than 8 hours. Failing which, it would be an escalation.
  • Ben has been identified as the SPOC for the customers to reach out to for any clarification and data points although the customer can interact with the entire team to provide inputs and give guidance.

This policy process were made explicit and helped all the stakeholders to smoothly navigate through the support project of eGarb.

Core practice 4 - Make the process policies explicit : Tips, Recap and Additional References

Practical tips

  • Identifying and resolving bottlenecks is very important to ensure smooth workflow.
  • The process and workflow need to be visually represented to spot congestions/bottlenecks
  • Measurement of cycle time will let know the time spent by items in every workstage and hence will help identify bottlenecks
  • More team members can be added to resolve the bottleneck
  • Organizing similar work items in batches can help
  • Do continuous bottleneck analysis to ensure that they dont occur often
  • Adjust WIP limits before and after the bottleneck workstage for better management
  • A buffer of some items (small number) can be kept before the bottleneck stage to ensure that the previous workstage is not idle

Quick recap

  • A good workflow is predictable and moves steadily and smoothly
  • A good workflow is essential for fast delivery
  • Metrics and bottleneck analysis helps ensure smooth workflow

5.Implement feedback loops

The focus now moves on to how to gather systematic feedbacks and also collaborate with stakeholders based on the feedback and improve continuously.

Ben, the lean Kanban coach, has been continuously interacting with his team to understand how the team feels and the challenges faced by the team. Ben is keen in formulating a systematic approach towards capturing the feedback so as to act on it.

Meetings and their frequencies

The following cadences highlight the importance of collecting feedback in a systematic and disciplined approach so that it can be subsequently incorporated into the system for better results.

  • Standup Meeting
  • Operations Review
  • Service Delivery Review

Standup meeting

Stand up meeting is one of the activities followed in Scrum. The idea of standup meeting is for all the team members to participate and share on an individual basis – what work was done on the previous day, what is being planned to work on the current day and what issues are faced. The helps the entire team to understand the progress across each member present in the team.

Operations Review

The operations review is to take stock of how the various teams are collaborating as an organization. Local optimization of improving only a part of the system without considering the other parts would not yield expected results. In this meeting, managers of different components look for means and ways to improve the system as a whole.

Service Delivery Review

A service delivery review looks at a Kanban system from the point of view of the key stakeholders, the intended beneficiaries of the system. It involves end users, explores customer satisfaction with all aspects of the process, including operation efficiency, effective communication, SLA compliance, and effective resource utilization. The goal is to improve customer satisfaction and to build trust through transparency.

6.Improve collaboratively

It is important for agile teams to work in a collaborative mode with stakeholders, so that people from different domains can work together effectively and build off each other's strengths to ensure continuous improvement.

Ben uses planning and review meetings to provide the time and space for his team to collaborate and build relationships with each other in a structured way.

Meetings and their frequencies

Refinement is possible only when the teams and other stakeholders collaborate in the needed manner. Following agile processes give opportunities for collaboration and follow up.

  • Replenishment Meeting
  • Delivery Planning Meeting
  • Risk Review
  • Strategy Review

Replenishment Meeting

The replenishment planning meeting is the meeting in which we decide what tasks the team would work on similar to the planning meeting in Scrum methodology. This meeting captures the latest information from downstream feedback and decides what is important to be developed. The frequency of this meeting can be in sync with the feedback loops.

Delivery Planning Meeting

This meeting is to smoothen the hand-offs between teams or departments involved. Inputs from stakeholders who would take delivery, decide what to deliver, when and whether any training or handoff activities are required to ensure a smooth transfer of Work In Progress. As a result of this meeting, some tasks in progress may change priority or class of service.

Risk Review

Risk review can happen at all levels in the organization to assess the chances of failing to deliver to expectations to other teams or end users. Identifying risks in advance and mitigating those risks improved system predictability which increases trust and profitability. The most basic level of risk review is by examining past failures, blocked tasks, re-work, and missed SLAs. The root causes are identified and prevent them from happening again.

Strategy Review

Strategy review is to examine changes in the market and understand if it can cater to the emerging needs. This can be done by comparing the recent delivery timelines to market trends. If there is a need, we should find means of how to optimize the process. Inputs in these lines are obtained from marketing and client-facing business units like sales and customer service. This could result in forming new guidelines for evaluating product ideas.

Meetings - Example

Ben interacts with the eGarb team and brings in discipline with which the feedback can be collected. By doing this, Ben was able to do all the meetings in the cadences and hence enhance the effectiveness of the whole work done.

The frequency of the meetings were decided as follows and implemented with a concurred understanding among the stakeholders that the frequency can be altered going forward as and when required.

Practical tips

  • Teams need to review Kanban board workflow, metrics and reports and a range of visual cues that provides continuous feedback on the work
  • Feedback loops are critical to implement the “Fail fast! Fail often!” mantra
  • Different ceremonies can be used for getting feedback and improving collaboratively as a team

Quick recap

  • In order to collect feedback systematically and in a disciplined way, different meetings can be arranged and followed by the teams
Condence Meeting Frequency Remarks
Standup Meeting Every day All the team members participate. Ben oversees.
Operations Review once in two weeks Ben and his entire team participate with key stakeholders
form other interfacing teams
Service Delivery Review once in two weeks Ben and other key stakeholders participate
Replenishment Meeting Twice a week Ben and his entire team participate
Delivery Planning Meeting once in two weeks Ben and his entire team participate with key stakeholders
form other interfacing teams
Risk Review once in two weeks Ben and other key stakeholders participate
Strategy Review once in a month Ben and other key stakeholders participate

⚠️ **GitHub.com Fallback** ⚠️