How to optimise team efficiency by reducing "Work in Progress"

Summary / TL;DR

Working on multiple tasks in parallel is slower than doing work sequentially, due to the fact that the completion time for each of the tasks is set back in the future.

As you can see from comparing the graphics above, the completion time of Task 1 and 2 are set back to time unit 3 when working parallel.

This gets even worse if tasks have multiple stakeholders contributing to the completion.

In this article we will dig deeper into the well-known concept of Work in Progress (WIP), and illustrate how the impact on time increases, when multiple stakeholders are involved.

We will show how it can be applied to software development processes with a team of around 100 colleagues.

What is Work in Progress (WIP)?

The term Work in Progress (WIP) has its origins in manufacturing and production environments. It refers to items that are in various stages of completion within a production process but are not yet finished products.

The term is commonly used in project management and various business processes to denote the state of products or tasks that are currently being worked on.

It can brilliantly be applied to software development and all related processes, and we have been successfully using it at 1xINTERNET. In this context, WIP refers to conception, design, development, or similar tasks that have been started but are not yet finished.

Monitoring Work in Progress works well with agile methodologies to optimise throughput of sprints and to optimise workflows. Also, keeping track of WIP helps us identify bottlenecks and ensure that resources are efficiently allocated to move projects forward.

Applying the concept in software development

For a service provider like 1xINTERNET it is important to finish tasks as early as possible because only when we complete them can deliver the results to our clients and get paid.

To achieve this, we prioritise finishing ongoing work items before initiating new ones.

As shown in the sequential graphic above, Task 1 will be completed and delivered at time unit 1, while Tasks 2 and 3 will be delivered at time units 2 and 3, respectively.

However, if we work on all three tasks in parallel with the same resources, all tasks will be completed by time unit 3. This approach delays the delivery of Tasks 1 and 2 by 2 and 1 time units, respectively.

Now, let’s apply this framework to software delivery. At 1xINTERNET, all development work undergoes an internal peer review by other developers. Additionally, new functionalities are reviewed by our clients before rollout. This establishes at least two layers of review in our process.

Applying the logic of Work in Progress reveals that involving more stakeholders intensifies delivery delays if parallel work is not avoided.

If all tasks are worked on sequentially, Work in Progress is minimised: Task 1 is completed after 2 time units, while Tasks 2 and 3 are completed after 3 and 4 time units, respectively. 

If the tasks are worked on in parallel, the earliest completion times are 4, 5, and 6 time units.

If all tasks and reviews are parallelized, Work in Progress is maximised, with the earliest completion of all tasks and reviews being 6 time units.

Insights, final thoughts, and recommendations

Planning all work sequentially is, of course, challenging. At the time of writing this article, we have nearly 100 colleagues at 1xINTERNET, making efficient resource scheduling across multiple projects complex.

It's tempting to start something new while waiting for the completion of another task. However, you must be aware that excessive Work in Progress inherently delays all tasks.

Finding the right balance between finishing what you started and fully utilising available resources is difficult. At 1xINTERNET, we prioritise finishing work over resource utilisation. We have strict policies ensuring that colleagues cannot start new tasks if they can complete existing ones instead.

This approach works well for us, enabling our colleagues to collaborate more effectively. By reducing multitasking and its associated inefficiencies, our staff works more happily, leading to higher-quality work and faster task completion.

Additionally, controlling the amount of Work in Progress allows our teams to better manage the flow of tasks through different stages of the development process, helping them to identify and eliminate bottlenecks.

Reducing parallel work provides us with better visibility into the current status of our projects, improving the overall project management efficiency. 

As a result, reducing WIP not only leads to better throughput but also increases the satisfaction of all stakeholders. We recommend paying attention to Work in Progress for most, if not all, workflows.