WIP Limits
Once processes have been visualized, the next step is to think about how to control the process. Some teams think about this at a very early stage and try to control their processes as true to the original as possible, some come from a context where there was no process control at all up to now and everyone was simply set to full capacity in their work step (push principle). Whether right at the beginning or as a first step towards better process control, the optimization of the value chain and the most effective measure to limit WIP (the number of work packages in progress) is a central measure and prerequisite to implement a pull principle in the context of knowledge-based approaches.
WIP thresholds harness the full potential of Kanban, enabling teams to deliver higher quality work faster than ever before in a healthier and more sustainable environment.
Advantages of WIP limits
Implementing WIP limits is often not easy, but the benefits of a focused, clear and disciplined approach far outweigh the effort. Below are some key benefits of using WIP limits.
The optimal management of capacities
Each team has a limited amount of time and energy each day that they can devote to maximize customer value. Often teams lack an understanding of how to organize themselves to maximize benefits and assume that the optimal state is one in which each team member is working at maximum capacity.
Based on our discussion of the Theory of Constraints, you may already have realized that accumulating work done cannot be equated with a positive outcome for the client or employer. Rather, in extreme cases, it leads to the fact that a large number of semi-finished products, partial solutions that cannot be used, do indeed lead to costs, but that only those products that can be delivered to the customer and offer concrete benefits there, will actually be successful. Work is only valuable when it reaches the hands of the customer. In most teams, very little work is really "solo work". Most work requires the effort and expertise of several team members.
When each team member is 100% utilized for the tasks assigned to them, it means that they are not able to work with their team, answer questions, or support each other in getting work across the finish line. In reality, a 100% workload means that everyone is incredibly busy - but the benefit realized for the customer is extremely small. I am always surprised that even for many seasoned managers this is a completely new way of thinking, and that it results in targets and desired key figures that could actually be described as damaging to the business.
WIP thresholds help us to use the combined efforts of our team members more effectively. Instead of a system where each person tries to move their tasks to the next step, we create a system where the team works together to move work from start to finish quickly. If we want to use Kanban successfully, our focus must not be on maximizing the work done, but on maximizing the benefits to the customer.
This means that even though less work is being done simultaneously and some team members may be underutilized at various points in the process, more value actually gets into the hands of the customer.
Systems thinking - the whole is more than its parts
While in classic project procedures the people involved in a process can concentrate centrally on their work, an essential success factor of agile procedures and especially of Kanban is the developing ability of the team to focus on the performance of the team as a whole and to understand that the customer benefit is not the achievement of a single team member but the team as a whole. WIP limits force us to work as a team, to jointly set priorities, plan, complete and deliver. This is a practice known as systems thinking, where decisions are made that benefit the entire team so that our efforts contribute to the achievement of the team's goals. Systems thinking enables teams to make better use of their collective resources.
WIP limits ensure that teams work in relation to the overall capacity of the system, which in turn ensures a fluid, consistent flow of values. Implicitly, this also leads to informal WIP limits for individual team members. If there is a limit of "7" in a work step and three people are involved in the implementation of the process steps, then one person cannot reserve six of the seven work packages for himself.
Many teams that use Kanban hold daily stand-up meetings, in front of their boards. This is an opportunity to evaluate the current workload of the team and discuss as a team how work packages can be implemented to be as efficient as possible. You could ask questions like:
- Which work package should be worked on next
- If someone has problems with a work package and needs support
- Are there any blockages
- Can someone help X to reduce his "jam" of work packages
- ...
The meeting helps to support an awareness of the workflow and the realization of customer benefits in the entire team. Together we look for ways to optimize this.
Process improvement as a constant task
If everyone involved in the process is only focused on delivering maximum performance, we easily lose the ability to keep an eye on the process as a whole and its goal. It is still all about maximizing benefits. Therefore it is necessary to look for ways to optimize the process together and to achieve higher benefits more efficiently.
By implementing WIP limits, we can gain clarity about our processes and see what works and what doesn't. In addition to setting up WIP limits, it is also advisable to make the process rules transparent. This includes a description of the scope of the individual process steps as well as the question of what must be fulfilled for a process step to be considered successfully completed. In addition, there may be other important topics that need to be defined. These include, for example, the question under which criteria rules may be overridden and what effect this has. This can be a topic in the context of different service classes, for example. If this information is transparently accessible to all participants, the team can make informed decisions.
Rest periods - the basis for real improvement and sustainability
There is a fundamental difference between maximum utilization of resources and maximum benefit generation. This is largely due to the fact that today we develop and produce in complex environments with a division of labor. In Kanban, unused time is called rest time and is seen as a sign of a healthy system.
Breaks create space for improving our working methods. Team members can use the time to make continuous improvement efforts, watch webinars or brainstorm ideas to optimize recurring programs. They can organize their kanban boards, update outdated documents or do anything else that is important and valuable. This is the basis to make work more effective and efficient.
The rest period is an opportunity for professional development during working hours and can contribute significantly to job satisfaction. Without WIP limits there is no rest period. WIP limits allow us to organize work in such a way that the customer benefit is achieved, but there is also time to work on a sustainable further development of the system.
Control with WIP limits
WIP limits can refer to a wide variety of process elements. Whereby WIP limits always refer to "In progress" and "Done" and not only to those which are still in progress. This is necessary to ensure the pull character of the process:
- WIP limits at the level of individual work steps
- WIP limits at the level of groups of process steps
- WIP limits on the level of individual swimlanes
- WIP limits in relation to individual employees
- WIP limits in relation to certain service classes
- WIP limits in relation to the overall process
- …
... as well as sensible combinations of these. The whole thing should remain clear and it is always a good idea to set WIP limits based on actual use and demand.
Determine the appropriate WIP limits
Teams that are new to Kanban often find it very difficult to set WIP limits. In fact there are very different approaches in the literature. The fact that WIP limits can be adjusted at any time and the fact that there are no "right" or "wrong" WIP limits, but only helpful ones and those that hinder them, can bring some relief.
In this context, some authors simply recommend starting without WIP limits and then setting them according to the actual numbers found. Immediately setting excessively aggressive WIP limits, especially if this represents a major change for the team and the organization, can lead to resistance and stress. In general, it is a good idea to start out a little looser at first and then gradually tighten the WIP limits over time as the impact of changes is observed.
To increase buy-in and the likelihood that people will meet the limits, try to define them as a team and also include the people or areas that hand over work to the team. A non-optimal approach, supported by the team and adapted according to experience, is always superior in the long run to an approach imposed from outside. Approaches to setting WIP limits:
- Single article flow
- 2 elements per person (or pair if peer programming is used)
- The n-1 approach
- Open WIP
Single article flow
An extreme case for setting WIP limits is to set a WIP limit in such a way that only one work package is being processed by one person at a time. Depending on the project and the product created, this can make more or less sense. We can state, however, that this would probably optimize the lead time for the item in question. This approach is an extreme focusing measure, which might be extremely difficult especially for teams without further experience with Kanban.
2 elements per person
This is a commonly used approach that aims to keep WIP low while allowing some flexibility when blocking elements.
The n-1 approach
Setting a WIP limit of o...