How WIP Limits Prevent Loss of Productivity Among Programmers
Let’s say that you have just finished a difficult coding task. Your head is already on fire; however, there is another tough assignment waiting down the line.
You commit yourself to it, but after a while, you say “Well, this one is actually not so urgent; I’ll get back to it later.” Then you start doing something easier because you are mentally drained.
After a few hours, you go back to the committed task, but you feel absolutely puzzled because you don’t remember what you were supposed to do. This means you now need to take some extra time to get back on track.
This is an example of context switching and is something that can generate a serious loss of productivity among programmers.
In fact, a study conducted by the American Psychology Association reveals that shifting between tasks creates mental blocks that can cost about 40% of someone’s productivity.
That’s why in order to preserve programmers’ productivity, you need to apply work in progress (WIP) limits to the software development process. This is a central practice of the Lean management method Kanban and has the potential to seriously boost the productivity levels of developers.
Defining WIP Limits on a Kanban Board
To fully understand WIP limits, we need to take a brief look at the method behind them.
Kanban is a system for Lean project management, originating from Toyota. One of its main benefits is that it contributes to process and workflow improvement through the principles of visualization and continuous improvement.
A defining part of this method is WIP limits. They represent the maximum amount of tasks a specific phase or entire workflow can hold and ensure your team keeps an optimal pace of work without exceeding its capacity. With these limits, you will be able to create a smooth workflow and prevent overload. Their application happens on a Kanban board, where the work process is visualized and divided into three stages: “Requested,” “In Progress,” and “Done.”
The main benefit of WIP limits is that they restrict your team members from starting new tasks unless the ones they’ve already committed to are done. This way, your team members will be focused on completing small batches of work before moving forward, which will increase their throughput.
In other words, limiting work in progress has the potential to speed up your team by slowing it down.
That’s why, if you are a software development manager, you should have a way to focus your team’s attention on the most important work that needs to be done now. To do this, Kanban provides four different types of WIP limits:
- Per person WIP limits.
- Team WIP limits.
- Activity-based WIP limits.
- Constant WIP limits (CONWIP).
Keep reading to find out more about each one of them and their unique contribution to the prevention of productivity loss among programmers.
Setting Up Per Person WIP Limits
Imagine that one of your key programmer’s throughputs suddenly starts decreasing due to an increase in their responsibilities. They begin losing productivity because they’re constantly switching between tasks and thus taking longer to finish what they start.
To deal with this situation, you need to observe the individual workload of your team members for a certain time frame and then limit the works in progress based on your findings. This could be done by setting up per person WIP limits on a Kanban board.
If Rachel, for example, is able to process four tasks in the span of three days, then her WIP limit would be four for that specific time period. From here, you can use the information as a rule of thumb and thus prevent each individual from overburdening.
This way, you will be able to deal with the issue of task switching when somebody from your team starts getting more work items than they can handle. As a result, you will create a workflow that yields high levels of throughput and eventually an increased rate of successfully delivered projects to the end customers.
Establishing Team WIP Limits
Let’s suppose your team of developers is working hard toward the release of an important new feature of your product. In that case, there is certainly a lot of work that needs to be finished, as the main goal is to deliver as much value as possible to the end user.
To achieve that, apart from making sure your team members do not get overburdened with tasks, you need to foster collaboration among them as well. This is where team WIP limits step in.
Limit the work in progress that happens at the team level. By doing this, you are set for achieving two things at once.
First, you will prevent loss of productivity among your group of programmers because they will be less overburdened with the big flow of tasks that they have to deal with.
Second, you will be able to build a culture of “delivering customer value together” because your team will be sharing knowledge and working as one toward the completion of the most important work in a specific moment.
Setting Up WIP Limits Based on Activity
Apart from per person and team WIP limits, works in progress can be restricted based on a specific activity as well.
Let’s take the “Review” activity in software development, for example.
This is one of the most common steps of the development process, where time can be wasted. While waiting on a review, programmers have to either start new work or stay idle. This creates unevenness that damages the rhythm of the way tasks are flowing through the work process, which results in a decrease in the productivity levels of your entire team.
In order to prevent this from happening, you can apply WIP limits to the work items that are waiting to be reviewed. These are “activity-based WIP limits.” They can be applied to any other activities in the software development process that generate excessive waiting time for a specific team, like testing, debugging, or deployment.
This way, if there’s an accumulation of three tasks (Kanban cards), the people responsible for them will know that they need to act immediately; otherwise, the work process will be damaged.
When this is done, you will be able to make sure there is less accumulation of waiting time, which can be a huge reason behind the loss of productivity among programmers. In addition, your process will become more predictable so you can always deliver value to the end customers at a steady pace.
Using Constant WIP Limits
In general, one of the main ideas behind Kanban as a management method is to create a pull approach. Regarding manufacturing, for example, that would mean producing goods only when there is a demand for them.
This approach can be implemented inside your workflow by using constant WIP limits (CONWIP).
With these, you can define the number of tasks in the “Ready to Start” and “In-Progress” work stages all together regardless of their type or size. This is how you will get on the right track to creating a pull approach where a new work item enters your workflow only when another one has already left it.
In order to determine the CONWIP, you need to take into account the capacity of your programmers working on a single Kanban board. In the case that CONWIP is higher than their capacity, then they will be multitasking. However, if it’s lower, then your team will be staying idle, which is something that you want to avoid as well.
With the help of this method, you will be able to produce two workflow optimization achievements at once.
First of all, you will have a clear way to make sure your programmers do not lose their productivity due to multitasking. Secondly, you will also be able to tell if your team remains idle so you can go ahead and optimize your work process accordingly.
Achieve Higher Productivity by Limiting Work
Loss of productivity among programmers is something that can happen quite often in modern-day software development. That is because of the constant flow of new tasks that are pending to be completed.
In order to prevent productivity snags from happening, you should limit the number of work items your team handles at once. That’s why the Kanban method and its WIP limits are so valuable when trying to achieve workflow improvement.
Implement them into your work processes so you can reap the rewards of having a team of fully dedicated programmers who maintain high levels of productivity.