First Big Decision: Setting Work-In-Process, Queue, and Buffer Limits
In IT value streams as WIP goes up throughput and quality go down. The amount of work the team does at one time likely impacts the organizational partners before and after the team in the value stream. Achieving consensus helps the limits stick when the team comes under pressure. So setting WIP limits is one of the most important decisions you'll make when introducing kanban.
Depending on the local norms people may work on an item independently, in pairs, in groups of three etc. Define WIP limits within that context i.e. item per person or item per group.
WIP Heuristics For Tasks
- 1 item per person or group - this minimum value is often the preferred target. Maintenance teams frequently follow one item at a time rule
- 1.5 items per person or group - this value provides a buffer allowing work to continue when an item is blocked. We observe new, larger projects requiring more team collaboration here e.g. a team of ten pair may set an 8 item limit 1.6 items per person
- 2 items per person or group - each person or group has a backup. All else being equal quality and throughput may begin to suffer
However, there is no magic number as circumstance vary dramatically. Adjust WIP limits to each situation e.g. consider the coordination and transaction costs of your process. Remain mindful of the minimization goal. If your situation requires significantly higher WIP than the heuristics then continuous improvement should lead to process changes.
Buffers And Queues
Buffers and queues add WIP to your system and their effect is to lengthen lead time. However, buffers and queues smooth flow and improve the predictability of that lead time. By smoothing flow, they increase throughput, so more work is delivered through the kanban system. Buffers also ensure that people are kept working and provide for greater utilization. There needs to be balance, and buffers help maintain it.
When work is completed and waiting to be pulled by the next stage in your workflow, it is said to be “queuing.”
- Set the input queue size based on the average throughput of the system and prioritization cadence
- Generally, use the smallest practical queue sizes
- Use a non-instant availability queue to maintain flow when a previous step's workers are not always available when the subsequent step's works are ready for more work
- Place buffers in front of bottlenecks to ensure the bottlenecked task always has work
- Some tasks may not require limits. Throughput for figure 10.1's team along with a bi-weekly release cadence, low complexity and transaction costs of releases allowed this task to be unlimited
- If you see "stop and go behavior" where flow is frequently blocked by a lack of work then increase the queue size
- If you are using two items per worker or group then some queue's may not be needed as ample work is available. However, this approach often results in lower quality and throughput
- Not picking limits is a mistake, not a strategy
Allocating capacity
Once we establish WIP limits for the flow through the system, we can consider capacity allocation by work item type or class of service.
Figure 10.3 shows the card wall design from chapter 6 with WIP limits across the columns totaling 20 cards. The capacity is allocated across work item types, namely, 60 percent for change requests, 10 percent for maintenance items, and 30 percent for production text changes. This equates to a swim-lane WIP limit of 12 for change requests, 2 for maintenance items, and 6 for production text changes.
Capacity allocation allows us to guarantee service for each type of work received by the kanban system. The allocation should generally be made in response to the comparative demand observed for each type of work. Hence, it is important to complete some demand analysis to facilitate reasonable allocation of WIP limits on swim lanes for each type of work.
Establishing Service Level Agreements via Classes of Service
This result (of classes of service) was significant because Kanban with classes of service had clearly changed the customer psychology and significantly changed the nature of the relationship and the expectations. The customers were now oriented around the long-term relationship and the performance of the system, and not on the delivery of any specific item or items. This gave the development team the freedom to focus on the right things and not waste time addressing issues that stemmed from a low level of trust between them and their customers.
The service-level agreement allows us... ...to spread risk by aggregating a large collection of requests and promising only aggregate performance in the form of a percentage due-date performance. By avoiding making promises we are unlikely to be able to keep, we avoid the danger of losing the trust of our customers. Therefore, it’s important to communicate that the target lead time in the Standard class of service is just that, a target! Also, they allow us to avoid costly activities, such as estimation; low-trust activities, such as making commitments.
To achieve these benefits all kanban systems should implement classes of service. Use empirical analysis to establish and maintain them.
Typical Class of Service Definitions
Classes of service are typically defined based on business impact. Different-colored sticky notes, index cards, or tickets are assigned to each class and clearly signify the class of service of any given request, as in Figure 11.1; otherwise, separate swim lanes are drawn on the card wall to signify membership in a class of service.
Generalization of common classes of service:
- Expedite - interrupts other work as needed to deliver. Policies should severely restrict usage
- Fixed Delivery Date - use to address the significant cost of delay e.g. regulatory compliance, opportunity costs of seasonal business...
- Standard - should cover most items in the system
- Intangible - use to address important but not urgent items
Rules of thumb:
- Avoid confusion and apply no more than 6 classes of service. Four classes is common
- These are typical examples and not "the classes you must use." Study your circumstance to determine your needs
- The goal is to ensure that any staff member, on any given day, can use the simple prioritization policies associated with a class of service to make good quality prioritization decisions in the field without management intervention or supervision.
- You should be able to look at the big visible board and quickly determine any items class of service, current status, as well as intuitively see how if policies are being followed (see figure 11.3 below)
Two Policy Examples
Fixed Delivery Date Policies:
- Items use purple cards
- Delivery date is displayed on the bottom right-hand corner of the card
- Items receive some analysis and an estimate of size and effort may be made to assess the flow time.
- If the item is large it may be broken up into smaller items; each smaller item will be assessed independently to see whether it qualifies as a fixed delivery date item.
- Items are held in the backlog until they are selected for the input queue, close to the ideal point in time at which they can be delivered on time given the flow-time estimate.
- Items are pulled in preference over other, less risky items. In this example, they are pulled before standard or intangible class items.
- Items must adhere to the WIP limit.
- Items queue for release when they are complete and ready for release. They are released in a regularly scheduled release just prior to their required delivery date.
- If a fixed delivery date item gets behind, and release on the desired date is at risk, its class of service may be promoted to an expedite request.
Standard Class Policies:
- Items use yellow cards.
- Items are prioritized into the input queue based on an agreed-upon mechanism, such as democratic voting, and are typically selected based on their cost of delay or business value.
- Items use first in, first out (FIFO) queuing as they are pulled through the system. Typically, when given an option, a team member pulls the oldest standard class item if there is no expedite or fixed date item to choose in preference.
- Items queue for release when they are complete and ready for release. They are released in the next scheduled release.
- No estimation is performed to determine a level of effort or flow time.
- Items may be analyzed for order of magnitude in size, typically, small (a few days), medium (a week or two), and large (perhaps months).
- Large items may be broken down into smaller items. Each item may be queued and flowed separately.
- Items are generally delivered within x days of selection with a due date performance of m percent.
Determining Service Delivery Targets
- Offer a target lead time measured via due-date performance rather than committing to every item
- Leverage historical data to determine lead time targets. Process the lead times (from first selection until delivery) through a statistical process-control package or kanban tracking tool that supports statistical process control (such as Silver Catalyst) and use the upper control limit (the plus-3 sigma limit) for your lead time. This ensures a time that you can hit under most normal circumstances and miss only when there is a genuine assignable-cause problem
- If you don't have historical data then make and educated guess
- The ability to frequently avoid estimating is based on the inputs typically having a standard size or that the team is experienced enough to reliably break things into consistently sized pieces.
Meet Service Levels by Allocating Capacity to Classes
Figure 11.3 shows a kanban system with a total WIP limit of 20. Classes of service are designated by four colors of tickets. The white expedite tickets do not count against the WIP limit, but are limited to only one item at a time. Hence, they have a five percent impact on total capacity when present, and increase the effective work-in-progress to 21 items. In this example, fixed delivery date purple tickets represent 20 percent of the total. This means that there can only be four purple tickets on the board at any given time, but they can be present in any column. Yellow standard class items represent 50 percent of the total allocation, for a total of ten tickets. The remaining 30 percent are allocated to green intangible class items.
- Set the class of service during input-queue prioritization
- Align capacity percentages to customer demand
- You'll need to decide how to handle this complexity e.g. What if we do not have current demand for a fixed date item? What should we do? Should we fill the slot with a standard class item?
- There are no right or wrong answers to these questions. The answers need to be derived in context and are specific to each situation. Sometimes on a daily basis though you can define policies for common situations
Thanks,
ReplyDeleteBut, figure 10.3(10.1) put wrongly