Kanban Board – Enabling Visual Control To Work (from my book Engineering Excellence DNA in Applied Systems)

12/01/2024

Delivering The Highest Quality Fabrics

Kanban is the Japanese word for sign, so the Kanban system means to use visual cues to prompt the action needed to keep a process flowing. Kanban is a workflow management method for identifying, defining, managing, solving problems, and improving deliverables performance. It aims to help us visualize our work and maximize efficiency. A Kanban Board is one of the tools that can implement and manage work at a personal or organizational level. Kanban boards visually depict work at various process stages using post-it notes to represent work tasks and columns to represent each stage. Post-it notes are moved from left to right to show progress and to help coordinate teams performing the work. We may divide a Kanban board into horizontal swim lanes representing different kinds of work or different teams performing the work. Simple boards have columns for “waiting”, “in progress” and “completed” or “to-do”, “doing”, and “done”. We can create complex Kanban boards to subdivide “in progress” work into multiple columns to visualize workflow across a value stream map. When using Kanban, the scope of application (e.g., single team, multiple teams, departments, divisions) can influence how the method’s principles and practices are applied. Suppose we look at a basic scope within a team, for instance. In that case, we might find a relatively simple Kanban board with maybe five columns indicating the workflow, a few simple metrics and diagrams, a daily coordination meeting, and regular reviews of the team’s work and performance. Now imagine a whole internal services department within an enterprise, which is managed by a set of Kanban boards relating to each other, placed at different levels of detail, covering different workflows. The amount of work in progress is limited at different levels. Both instances are proper usage of the Kanban method. There is no “right or wrong” in Kanban; rather more or less appropriate to adopt practices given the business context and cultural environment. Toyota, HP, Pixar, Zara, and Spotify are using Kanban. Specifically, Toyota has six rules for implementing Kanban: (1) Never pass on defective products. (2) Take what is needed. (3) Produce the exact quantity required. (4) Level the production. (5) Fine-tune production. 6) Stabilize and rationalize the process.

A Kanban board (see top illustration) mainly follows the following three principles or Change Management Principles: These principles are common to all Kanban implementations: (a) Start with what you do now. (b) Agree to pursue improvement through evolutionary change. (c) Encourage acts of leadership at all levels. Kanban is not a significant transformation from a current state to some future state. We know from history that those rarely work. Instead, Kanban uses an evolutionary change approach, building on the way of working already in place and seeking to improve it using many forms of feedback and collaboration. The Kanban method brings about an evolutionary change through the knowledge gained by people who work with the Kanban board and take leadership steps to continually improve their way of working. These acts of leadership may not be what is thought of as traditional leadership. They may be small observations and suggestions for improvement by individuals without organizational leadership roles.

Kanban encourages us to take a service-oriented approach to understanding our organization and its workflows through it. This service-oriented organizational model is based on the idea that our organization is an organic entity consisting of a network of services, each of which lives, breathes, and evolves. Customer requests flow through this service network. To improve service delivery, principles must guide improvements. Organizations may not use these principles early, as they may not have developed or evolved a service-oriented or customer-oriented culture as part of their culture. The service-oriented principles are concentrated on understanding and focusing on the customer needs and expectations, managing the work, letting people self-organize around it, and regularly reviewing the network of services and its policies to improve the outcomes.

There are six general Kanban practices: (1) Visualize. Good visualization is the key to effective collaboration and identifying opportunities for improvement. Many times, work in the organization is hidden. Visualizing this work and the flow of this work significantly improves transparency. The human sense of vision is ancient from an evolutionary point of view. It allows us to absorb and process much information quickly. In addition, visualization supports collaboration, as everyone involved has the same image. (2) Limit Work in Progress (WIP). WIP states the number of work items in progress at a specific time. Through Kanban, it has been discovered that effective systems focus more on the flow of work and less on worker utilization. When resources are fully utilized, there is no slack in the system, and the result is low flow, just as in rush hour on the freeway. In the work of knowledge, there is also the issue of context switching that can drastically reduce the efficiency of employees.

Kanban purposely limited the WIP to balance utilization and continue ensuring workflow. We will later describe the WIP limits and how they are used in a “pull system.” (3) Manage flow. Managing the flow of work is to complete work as smoothly and predictably as possible while maintaining a sustainable pace. As mentioned before, limiting WIP is one of the key ways that help us ensure a smooth and predictable flow. Monitoring or measuring the workflow results in important information that is especially useful for managing customer expectations, forecasting, and improvements. The core Kanban metrics that best measure our team performance are cycle times (how fast work gets done) and throughput (how much work is delivered). These metrics are to watch to ensure we are showing results to our customers. Little’s Law connects cycle time, throughput, and WIP. (4) Make Policies Explicit. Every day, countless decisions are made about work organization, either by individuals or between groups of people. Imagine a new employee starting in our area. Ideally, they will quickly understand how work is organized through explicit policies. These include:

§ Policies include replenishing the board (when, how much, and by whom). Definition of when a work activity is completed, and the work item can move on (“pull criteria”).

§ WIP Limits.

§ We are undertaking policies for handling work items of different classes of service.

§ We are meeting times and content.

§ Other principles and collaboration agreements.

The engineering team should jointly agree upon all these policies between all parties involved, including customers, stakeholders, and employees responsible for work on the Kanban board. The guidelines should be placed in a noticeable area, preferably right next to the board. A team agreement is an excellent way to introduce policies at the team level. Like all other building blocks of the system, it is necessary to check and adapt these regularly. Please note that policies are not like work instructions freeing people from the burden of making meaningful decisions. Instead, policies should enable self-organization within the group of people running a Kanban system. Policies should be sparse, simple, well-defined, visible, always applied, and readily changeable by those providing the service.

Policies should be sparse, simple, well-defined, visible, always applied, and readily changeable by those providing the service. (5) Implement Feedback Loops. Feedback loops are required to coordinate and improve our service delivery. A functioning set of feedback loops appropriate for the given context strengthens the organization’s learning capabilities and evolution through managed experiments. Some commonly used standards for feedback loops in Kanban systems are the board, metrics, and a set of regular meetings and reviews, which are referred to as cadences. (6) Improve Collaboratively, Evolve Experimentally. Back to the Change Management Principles, in the Kanban method, a user “Starts with what he does now” and “Agrees to pursue improvement through evolutionary change.” Kanban is a method for continuous change. We make those changes collaboratively using designed experiments based on models and the scientific method. This platform is where feedback and metrics are essential to guide us on the evolutionary path. We design safe-to-fail experiments to keep the change if our hypothesis is correct and the investigation gives good results. Still, if the results are not positive, we can easily roll back to the previous state.

Practitioners commonly ask, “If every board and Kanban system is unique, how can we design our system?” The systems thinking approach to introducing Kanban or STATIK is a repeatable and humane way to start with Kanban. It has already been applied numerous times in practice. The STATIK approach should be applied to each service. It will result in a complete Kanban system design. Throughout the process, we should use systems thinking. The (future) system is always considered as a whole to improve the flow of value to customers. The illustration below (Figure 2) summarizes the six basic steps in the STATIK approach, which are usually applied iteratively. Subsequent steps can uncover new information, and it might make sense to repeat earlier steps.

Figure 2: STATIK – Systems thinking approach to introducing Kanban

STATIK workshops tend to explore the correct system design iteratively. We do not intend STATIK as a one-pass, sequential process. Still, instead, it is designed to function as a feedback loop that informs the design and redesign activities. In practice, this process usually takes between four hours and four days. It is essential to understand that it must be done with at least a representative group of the people involved. While everyone will have a picture of how the work is done, it rarely maps between people. The STATIK approach will reconcile these views into a shared perspective. As a rule of thumb, the STATIC approach should not be made in isolation by the Project Manager, Team Leader, or Consultant. Hence, it is vital to undertake the following actions:

§ Identify sources of dissatisfaction. Why are the employees involved in the service delivery dissatisfied? Why are the customers dissatisfied? Why is the project not progressing? All these sources of dissatisfaction motivate change, which is crucial for a successful Kanban initiative.

§ Analyze demand: What do customers request, and through which channels? What are the types of work and patterns in need? This information is key to developing the complete picture of the work that arrives at the system. Remember, manage the job, not the workers.

§ Analyze system capabilities: What are the system’s capabilities regarding how much of the customer demand is being delivered, what type, and how fast and predictable? This step typically requires historical data.

§ Model the workflow: Which activities does each identified work item type go through? They might be sequential, parallel, or in no order. Later, these will be the basis for defining the columns on the Kanban board.

§ Identify classes of service: How do items enter and get treated in the system? See the Classes of Services definition.

§ Design the Kanban system. The Kanban system is designed based on all the insights gained in the previous steps.

A Kanban system naturally consists of a board, tickets, and other essential elements such as metrics, cadences, and policies. In a Kanban system, there is at least one clear commitment and delivery point and a representation of the acceptable amount of work (Work in progress or WIP). Work items can be of different types and sizes, from tasks to requirements, types of artifacts, (groups of) product features, and topics to projects or product packages on higher-level boards. Work items are displayed on individual post-it notes, usually cards or tickets. The series of activities that these work items go through is called workflow. Kanban is based on the “Start where you are now” approach, so the actual workflow is modeled on the Kanban board. The individual steps in the workflow and buffers are shown in columns. Lanes are often used for different work types and projects to distribute capacity. The workflow is modeled on the board. Engineers can use additional colored post-it notes to represent other areas of disciplines of the system to be built. The flow of work and its risks should always be depicted in their proper, current state rather than a hoped-for future image. Our Kanban board should reflect our specific workflow, usually more than columns labeled ” To Do, Doing, Done. The possibilities vary greatly. Each Kanban system and Kanban board are unique. The so-called WIP limit, i.e., the maximum number of work items allowed at a time, can be defined per work state(s), person, lane, and type of work for a Kanban system. WIP limits are represented by a number in a circle above the respectively labeled columns. Restricting the work allowed to enter the system is essential to reducing delay and context switching, leading to poor timeliness, quality, and potential waste. The aim is to create a balance between demand and capability over time. Also, limiting the work allowed to enter the system creates a continuous flow of work through the “pull principle,” in which drawing or “pulling” work only happens if there is capacity. A virtual pull signal is generated when the WIP limit is not fully utilized. While work on the board moves to the right, pull signals move to the left, further upstream. The “Pull Principle108” is an essential distinguishing point from traditional project management. Work items are scheduled based on deterministic planning (push). In pull systems, completed work is regarded as more valuable than starting new work. It is often a cultural change. “Stop starting, start finishing” is a good mantra to remember for starters. WIP limits are one specific example of a policy in Kanban. WIP limits serve as an enabling constraint, giving focus and developing behaviors such as collaboration and finishing started items with high quality. WIP limits are crucial to establishing a pull system. There are several basic metrics in Kanban:

§ Lead time is when a single work item passes through the system from the start (commitment point) to completion. Lead time is depicted via a “Lead Times Run Chart.” The lead times of completed work items are plotted sequentially on a timeline. This chart helps observe lead-time trends.

§ The delivery rate is the number of completed work items per unit of time, such as features per week, training classes per month, or new hires per month. It is depicted via a “Distribution Lead Times,” where this chart illustrates the range of observed lead times (min and max) and their frequency of occurrence (how often). Flow management aims to optimize this distribution by narrowing it as much as possible (predictability) and shifting it to the left (timeliness).

§ WIP is the number of work items in the system (or a defined part) at a specific time. It is depicted via a “Cumulative Flow Diagram (CFD),” where the CFD contains valuable information regarding workflow across multiple activities. The colored areas in the diagram represent the number of work items within a particular movement in the workflow and how these work items move across all activities, from top to bottom, over time until done.

These core metrics are used in various graphical representations to understand system behavior and identify opportunities for improvement. While feedback loops might be almost entirely lacking in early Kanban implementations, feedback loops evolve, advancing maturity with growing maturity. We encourage ourselves to build up our rhythms gradually. Please note that, like all elements of Kanban implementation, the cadences can and should be set up to fit within the given organizational context. In practical terms, this means identifying existing meetings and reviews that already serve a similar purpose—continually evolving them, keeping the existing names, using the standard cadence naming, or coming up with something else—the intention matters. Pick the frequency and duration based on our context. In many cases, having more frequent but shorter meetings over time increases agility. As a side effect of many Kanban initiatives, we observe better-focused, structured, and tightly managed regular meetings with fewer attendees (Figure 3).

Figure 3: Kanban cadences

Cadences	Example Frequency	Purpose
Team Kanban Meeting	Daily	Observe and track the status and flow of work (not the workers). How can we deliver the work items in the system quickly? Has capacity become available? What should we pull next?
Team Retrospective	Biweekly or Monthly	Reflect on how the team manages their work and how they can improve.
Internal Team Replenishment Meeting	Weekly or as needed	Select items from the pool of work to do next.

Thus, the Kanban method includes the following nine steps: (1) Start with what you do know. First, understand the current processes as practiced, and second, respect existing roles, responsibilities, and job titles. (2) Gain agreement among the participants to pursue improvement through evolutionary change. (3) Encourage acts of leadership at all levels. (4) Visualize. For example, demonstrate work and its flows, visualize the risks, and build a visual model that reflects how we work. (5) Limit work in progress: (a) Apply the motto “stop starting, start finishing”; (b) Left yields to the right; (c) Limit work in the system to available capacity; (d) Apply a data-driven approach. (6) Manage flow. Flow is the movement of work. Manage flow to be smooth and predictable. Use data. (7) Make policies explicit. Have agreed policies visible to everyone involved: (a) Pull criteria, (b) WIP limits, (c) Classes of service, (d) And others as appropriate. (8) Establish feedback loops. At an appropriate rhythm. Foster collaboration, learning, and improvements. Data-driven. (9) Improve collaboration, and evolve experimentally: (a) Using the scientific method; (b) Hypothesis driven-change; (c) Run safe-to-fail-experiments. Sometimes it is easier to create or improve our board layout. Exploring other board layouts can inspire how we visualize our work and work together within our team. When borrowing board layout ideas, remember to respect our team’s way of working as much as possible.

Suppose our team is entirely new to Kanban. In that case, it can be helpful to start with the basics before diving into the more mature Kanban concepts we have shared in this article. Like any business methodology, it is always important to align around the why before implementing the what or how. First, ensure our team understands Kanban principles: Respect for people and continuous improvement. Then, help them understand the elements of a Kanban board and how they will enable them to improve task management and their work lives. For example, Work in Progress (WIP) limits will keep them from being overcommitted and help prevent them from feeling overwhelmed. Other steps to take in preparing the team to use Kanban boards include the following:

Identify the start and endpoints for our team to mark the beginning and end of its workflow.

§ Review current processes, roles, and responsibilities.

§ Ensure the team understands and is committed to continuous improvement.

§ Encourage leadership qualities at every organizational level.

Some cultural changes may need to occur as the team moves toward Kanban board adoption. For example, team members might feel nervous when they hear that Kanban boards effectively pinpoint weaknesses in the team’s process. Assuring them that continuous improvement is the goal can ease their discomfort. Once a foundation is established with the team, the Kanban board examples provided above will help generate discussion. Over time, the entire team will be instrumental in critiquing and refining the process.

As shown in Figure 4, the Kanban System represents a system where work items flow through several process stages. An entry point defines the Kanban system. An exit point is described by the commitment point and the delivery point in this example. Within these limits, everything is the team’s responsibility.

Suppose our team is entirely new to Kanban. According to Rachaelle Lynn, author of the 10 Kanban Board Examples, it can be helpful to start with the basics before diving into the more mature Kanban concepts. Like any business methodology, it is always important to align around the why before implementing the what or how. First, ensure our team understands Kanban principles: Respect for people and continuous improvement. Then, help them understand the elements of a Kanban board and how they will enable them to improve task management and their work lives. For example, Work in Progress (WIP) limits will keep them from being overcommitted and help prevent them from feeling overwhelmed. Other steps to take in preparing the team to use Kanban boards include the following:

§ Identify the start and endpoints for our team to mark the beginning and end of its workflow.

§ Review current processes, roles, and responsibilities.

§ Ensure the team understands and is committed to continuous improvement.

§ Encourage leadership qualities at every organizational level.

Figure 4: Key Kanban concepts

Key Kanban Concept	Try It with Your Team
Visualizing parallel processes.	Use horizontal swimlanes to visualize parallel processes on one board.
Reinforcing a pull system by visualizing wait states.	Build-in “Ready” queues to accurately represent wait states.
Managing flow by limiting WIP.	Set WIP limits on specific vertical lanes to actively manage capacity.
Managing different types of demand.	Use horizontal swimlanes to visualize different types of demand; use cumulative flow diagrams to analyze cycle times of different types of work.
Visualizing changing priorities.	Use “on hold” sublanes and visual icons to hold/indicate work that has been affected by changing priorities or urgent work that has been prioritized above existing work in progress.
Maintaining consistent use of board elements.	Create a “Legend” lane to use as a way to communicate how board elements are being used and any process policies that have been designed to maintain consistent board usage across the team.

As shown in Figure 5, the Kanban System represents a system where work items flow through several process stages. An entry point defines the Kanban system. An exit point is described by the commitment point and the delivery point in this example. Within these limits, everything is the team’s responsibility.

Figure 5. Kanban Queuing System

In a queuing system, work arrives in a process, and there is work that departs a process. When deciding whether something counts as in Progress or not, the first aspect of the system that needs to be considered is what it means for something to have “arrived”? According to Gerard Chivas, the team needs to define a specific point where a unit of work transforms from just some arbitrary idea (an option) into a legitimate work item to be acted on and completed immediately. Before that arrival point, the item is just some candidate for work. After that arrival point, the item is counted as WIP. This arrival point is what we call Commitment Point in Kanban. Work In Progress is the most critical flow metric to track for two reasons: (1) WIP is the best predictor of overall system performance. (2) The other two metrics of flow, Cycle Time and Throughput are defined in terms of WIP.

To define work in Progress, we must first agree on the boundaries of our process. Therefore, it is essential and one of the first things we do when designing a Kanban System to set the limits of our system. On the other side of the flow, we can define departure as delivery to an actual end-user or delivery to another downstream team or process. Most companies face an excess of WIP, even those practicing Agile for a while. A bunch of WIP decreases the delivery rate, increases time-to-market, reduces quality, increases stress and frustration, and leads to low morale and quality.

Cycle Time/Lead Time is the Kanban metric representing the amount of elapsed time that a work item spends as WIP. In other words, the time from the work item crosses the commitment point until it crosses the delivery point. Cycle Time must be defined in terms of the system’s boundaries because that is where we have influence and can effect change; outside of those boundaries, we have nothing to do. Lead time is the equivalent of time-to-market or time from concept to cash. Some authors refer to time-to-market as Customer Lead time or Flow Time instead of System Lead Time which is the time an item spends inside the Kanban System. Other authors refer to System Lead Time as Cycle Time. Still, others differentiate between Upstream Lead Time and Downstream Lead Time. The user can use whichever he likes best as long as he makes sure it is calculated within the system’s boundaries.

Throughput is the Kanban metric representing the amount of WIP (number of work items) completed per unit. Throughput is a measure of how fast things depart a process. Our team’s time division for our Throughput measurement is entirely up to us. For example, User Stories / Week or Features / Month or Experiments / Day. The Throughput metric answers the critical question of “How many features will you get in the next release?” We will need to answer that question at some point, so track Throughput and be prepared. The three Kanban flow metrics are intrinsically linked by a very straightforward and compelling relationship known as Little’s Law.

If we have ever seen Little’s Law before, we have probably seen it in the form of the above equation (Figure 6). However, Little’s Law was initially stated in a slightly different layout (Figure 7). Little’s Law explains the relationship between queue size, waiting Time, and Processing Time. The great advantage of Little’s Law is the overall simplicity of its calculation. One can easily calculate the third if one has two of the above three statistics. Also, notice that Little’s Law is a relationship of averages. Most people neglect this critical detail. Little’s Law is based on standards that are not necessarily good or bad.

Figure 6. Little’s Law

It is not good when people try to apply the law for never intended uses. To apply Little’s Law, we need a stable system that requires some assumptions to be true:

1) The average input or Arrival Rate (λ) should equal the average output or Departure Rate (Throughput).

2) All work that is started will eventually be completed and exit the system.

3) The amount of WIP should be roughly the same at the beginning and at the end of the time interval chosen for the calculation.

4) The average age of the WIP is neither increasing nor decreasing.

5) Cycle Time, WIP, and Throughput must all be measured using consistent units.Figure 30. Little’s Law Queuing Theory

Figure 7. Little’s Law Queuing Theory

The above first two assumptions (#1 and #2) comprise a notion known as “Conservation of Flow.” The second two assumptions (#3 to #5) speak to the idea of system stability. In order words, if we want to be predictable and forecast delivery, we must have a stable system that must comply with those assumptions (rules). Understanding the assumptions behind the equation is the key to understanding the Law itself. Once we know the assumptions, we can use those assumptions as a guide to some process policies that we can put in place to aid predictability. After studying Little’s Law, we should realize that if Cycle Times are too long, then the first thing we should consider is lowering WIP.

The real power of Little’s Law lies in understanding the required assumptions for the Law to work. Because every time we violate an assumption of Little’s Law, our process becomes less predictable. Specifically, it is essential to use these assumptions as the basis for some simple policies that will govern the operation of our process. These policies will serve to control the things that we can control. These policies will help to make our process more predictable. Based on the assumptions above, some process policies we could put in place:

§ We must only start a new day’s work at about the same rate that we finish old work.

§ We must make every reasonable effort to finish all work started and minimize wasted effort due to discarded work items.

§ If work becomes blocked, we must do everything to unblock that work as quickly as possible.

§ We must agree on service level agreements (SLAs) between different teams to ensure that dependencies are managed appropriately and minimize waiting time for work-in-progress items.

§ We must closely monitor our policies around the order in which we pull items through our system so that some work items do not sit and age unnecessarily.

Little’s Law specifies an exact relationship between average WIP, cycle time, and average Throughput. Still, it only applies when we are analyzing historical data. Engineers cannot use the Law to make forecasts about the future. For example, let us assume a team that historically has had an average WIP of 40 work items, an average Cycle Time of 10 days, and an average Throughput of 8 articles per day. We cannot say we will increase the average WIP to 80% or keep the average Cycle Time constant at ten days. Magically, Throughput will increase to 16 items per day. All Little’s Law says that an increase in average WIP will change one or both cycle time and average Throughput. The relationship among all three metrics will still satisfy the Law. If our system mostly conforms to all of the Law’s assumptions, we can begin to trust the data we are collecting. It is then that our process is probabilistically predictable. Once there, we can use the Monte Carlo simulation on our historical data to make credible forecasts. Another reason we should not use Little’s Law for making predictions is that it represents a relationship of averages, and we should never forecast based on standards.

There are some additional Kanban metrics. These Kanban metrics only make sense once we are using and mastering the three basic Kanban metrics. Here, we will present the Flow Efficiency Metric and the Flow Debt Metric.

Flow Efficiency is the Kanban metric that measures the percentage of total lead time that is spent by adding value (or knowledge) versus waiting. Figure 8 depicts the ratio of the actual elapsed time that an item was actively working to the total elapsed time it took to complete an item (its total Cycle Time or Lead Time). This metric is critical as, in most companies, work spends much time waiting, and people frequently multitask between different tasks.

As an item flows through the system, it can only be in two states. It is either being worked on or not being worked on. Examples of an item not being worked on are: (1) Some external dependency blocks the work process (e.g., team, vendor). (2) It is queuing, waiting to be pulled. It is usual for teams just starting to manage their flow to show Flow Efficiencies in the 5%-10% range. Suppose a user story took 20 days to complete and had a Flow Efficiency of 10%.

Figure 8. Flow Efficiency Formula

In that case, it spent only two days having someone actively working on it and 18 days in some inactive state. Suppose an engineer’s task only took two active work days and 18 days of inactivity. Where do we think we should focus our process improvement activities? It will probably be tough to improve on those two days of busy time, but we guess there are many opportunities to get that 18-day number down. Any reduction of idle time will, by definition, improve overall Cycle Time. Looking at wait time is usually the best, easiest, and cheapest area to investigate first for process improvement. We have had countless arguments throughout our careers, with people arguing that they need to improve software development. For instance, a quick look at the Cumulative Flow Diagram for the process clearly showed that software development was just 5% of the total elapsed time.

Flow Debt occurs when Lead Time is artificially reduced for some work items in progress by “borrowing” Lead Time from other work items. It is a fundamental Kanban metric as it is a leading indicator of unpredictability and an increase in Lead Time. Some examples of scenarios that lead to the creation of Flow Debt are the following:

§ Classes of Service (i.e., Kanban Classes of Service (CoS) are nothing but different services together within the same system). Figure 9.

§ Blockers.

§ Other order of pull policies in place (whether explicit or not), like expediting work, changing priorities, or changing goals.

It also refers to flow debt as aging work, which means that an item has been in progress for longer than the average cycle time. When an item is accumulating flow debt, it is indeed artificially aging. This problem happens when work in progress is left aside to work on other items that entered the system later. When Aging is higher than the lead time, it is clear that our system is unstable and not flowing correctly. There is much work in the system that is waiting or has been deprioritized but still in the design, consuming resources, people’s time, and complicated delivery.

Meanwhile, other work in the system goes through much quicker. Ask ourselves: Why did any of that work get into the system first? What are the criteria for committing to deliver on something? Why aren’t we working on the old tasks anymore? What is preventing us from finishing old studies? Why are we keeping things in progress and delaying them? Could we cancel those? Could we deliver them? Why are we adding more stuff if we still have many things that have been there for weeks?

If we are using any electronic tool, we can easily calculate Aging. If our Aging is much higher than our Lead Time, we have a problem! In a stable system percentile, 85% of lead time and percentile 85% of Aging should be similar. Suppose we are not limiting WIP in Kanban appropriately, or our scheduling policies are not explicit. In that case, we will have aging work items accumulating flow debt.

Here are some essential things we need to remember about flow debt and aging work in Kanban:

§ When the Average Work in Progress Time is more significant than our Average Cycle Time, our process accumulates Flow Debt.

§ When the Average WIP Time is less than our Average Cycle Time, our process is paying off Flow Debt.

§ When the Average WIP Time is similar to our Average Cycle Time, our process is stable from a Flow Debt perspective.

§ Flow Debt leads to process unpredictability because the work items allowed to artificially age will eventually leave the system.

This artificial aging leads to longer overall Cycle Times and more variability in our Cycle Time data, reflecting a longer tail in our Lead Time Histogram.

We can measure flow debt for the whole system, but using the proper electronic tool can also measure flow debt for every stage in our process. This approach is a clear leading indicator that will provide us with real-time information on the stability of our system.

Figure 9. Kanban CoS

Georgios Ardavanis – 12/01/2024

Tags :

Leave a Reply Cancel reply

Have Any Question?

Lorem ipsum dolor sit amet, consecte adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore