WIP limits work-in-process limits are fixed constraints, typically implemented on Kanban boards, that help teams actively eliminate waste from their processes. WIP limits enable teams to optimize their workflows for value delivery. Learn how enterprise Kanban software can promote the visibility and connectedness of teams and their work while increasing productivity, reducing waste, and improving agility across your organization.
The main idea behind WIP limits can be explained by this simple phrase: Stop starting, start finishing. The more work teams try to juggle at once, the harder it is for them to take work to the finish line. WIP limits are constraints on how many work items cards are actively being worked on at any given time. There is no one correct way to implement WIP limits, although a general rule is that they should be slightly constraining.
They should force us to make decisions regarding the priority, time sensitivity, and cost of delay of various projects. If WIP limits are being applied across the team, a good starting place is the number of team members plus one, so if you have 10 members working on a board, implement a WIP limit of 11 as a starting point. WIP limits are difficult to implement because they seem counter-intuitive: Do less to get more done?
But the truth is, if we can have the discipline to actively manage how much we are working on at any given time, at both the individual and team levels, we can gain the focus to get work done quickly, with high quality.
This means that by doing less at a time, we can actually get more done. There are many types of waste that WIP limits can help us proactively reduce and eliminate. Here are some of the most compelling reasons why we need WIP limits. Context switching is what happens when we stretch our focus, time, attention, and brain power across too many objects in motion. When we juggle too many projects at once, we waste these precious resources transitioning between contexts, instead of adding value to work.
Over the course of a week, that adds up to over 10 hours — more than a full workday. Imagine the impact this has across an entire organization over the course of a year! Context switching can also significantly impact our stress levels. In the same study, researchers gave two groups of workers a simple office task to complete: answering emails.
One group was not interrupted during the task, while the other group received phone calls and IM messages. The interrupted group scored significantly higher on the NASA workload scale in terms of stress, frustration, mental effort, and mental workload. WIP limits help teams reduce context switching by keeping individuals and teams focused on delivering just a few projects as few as possible at a time. Focus is what enables us to create high-quality work from start to finish.
While we still have to discipline ourselves to limit other workplace distractions email, Slack, conversations with coworkers , limiting the amount of work on our plate at any given time gives us the clarity and focus to deliver higher quality work faster — while also reducing our stress.
Another unfortunate side effect of too much WIP is excessive meetings. For most of us, the need for variety and the urge to make progress on all fronts makes us start way too many things at the same time. That same need leads to a high discomfort level that is often left unnamed. The Zeigarnick effect is exactly this discomfort, created by every ongoing task in our minds that takes energy to mantain and update.
The WiP limit helps us stay disciplined and keep focus by decreasing this discomfort. You can try this not only on your boards but also on your personal projects and goals. Instead of working on five features simultaneously and delivering them all at almost the same time, you deliver them one after the other by focusing check Littles Law. This way, your product is reaching your users earlier.
Reaching your user earlier means giving and receiving value earlier. Gentle Mentor: What happens when you cannot pull any more tickets in progress because you would break the WiP limit? Often one feels blocked and helpless. However, that does not mean there are no options. One can always ask around if anyone needs help, get out of the comfort zone and peak into a new discipline, or use the time to finish those small tasks that were left aside.
If none of that applies, there is always slack time, reflecting, and marinating on the way we get things done.
Conversation Starter: WiP limits can be very graceful conversation starters. The point is not to never break WiP limits, but for when you do break them to pick that up as a conversation starter.
Asking why and digging deeper into your flow will often take the conversation away from the board to the real challenge. For example, instead of ignoring the piling up of tickets in QA, you get to talk about how to increase cross-function cooperation and finish tickets faster.
And what to do when this is not convincing enough? Well, you could keep repeating these reasons — but sometimes the harder you push, the more defensive the team gets. Do you give up and stop doing Kanban and remove WiP limits? Do you turn to Scrum? Do you try something completely different? That is up to you. What helped me was to experiment, manage expectations, and talk:. Remove WiP limits for a limited time and see what impact it has on your metrics.
So in some cases, you actually need to have some parallel work in progress… So is it good or is it bad? Well, it definitely depends! This is a classic throughput vs. It is the same question IT guys have to handle when tuning a system. Is it more important whether the response time is good or is the throughput more important. For example, if you have a system where the user can search for some data in a huge database and wants to get all matching results. Response time might be more important, because the user can already have a look at the first few results if they come fast even if it means that the rest of the results will take longer, because all other users also get a fast response time.
On the other hand throughput might be more important, if the user actually needs to know how many entries where found or if the user needs all entries in order to be able to start with her work. But I doubt anybody will give you medal for saving these 15 minutes at the price of having a colleague not able to work for 2 days because he was waiting for your output.
In this case, you do not sacrifice 15 minutes of your time to improve response time but you sacrifice two and a half hours every day just switching tasks. Also the task which was supposed to take 2 days of work effectively took a whole week, because of the interruptions and task switching. Another reason for the WIP is that it is sometimes difficult to prioritize things. Or it is difficult to figure out what the consequences of a delay could be.
Who would be mad at you for needing a few more hours to complete something? The standard definitive answer for such question is: Well… it depends. Task switching is an issue because you need to get back to the previous context. There are people who are better at this than others.
0コメント