In theory, agile is an approach and mindset that helps teams respond more effectively to change, and exploit (rather than avoid) continuous feedback loops to deliver products faster, better, cheaper, and with greater customer satisfaction. What’s not to love about this?
Yet in practice, many agile teams are struggling rather than thriving — and more than a few have hoisted the white flag of surrender (or are seriously thinking about it). However, the roots of what seems like an anti-agile backlash isn’t rooted in the concept of agile itself. Rather, it’s triggered by a common problem: agile team overload.
Indeed, one of the first things that agile teams must do to succeed — or even more pragmatically, to survive — is grow comfortable saying “no” to an endless stream of requests (which are often orders disguised as requests). Naturally, this is easier said than done. But it’s not optional. Agile teams that can’t hit the brakes on requests and expectations end up starting far too many tasks projects, and finishing far too few of them.
As a result, an excessive amount of work is being done, but there isn’t enough productivity and results. Tragically, this usually leads to even more requests, which clogs the bandwidth even further. Sooner or later, the work experience is characterized by burnout, chaos and chronic under-performance.
But as noted, the problem isn’t with agile itself. Instead, it’s because there’s too much starting work, and not enough finishing work. That’s where work in progress (WIP) limits ride to the rescue, and transform agile teams from troubled to triumphant.
About WIP Limits
WIP limits are customized constraints that establish how many items can be actively worked on at any given time. WIP limits can be implemented for an entire process, or for specific phases (a.k.a. lanes or boards). For example, an agile team may impose a WIP limit of seven for the testing phase. This means that if seven items (or cards) are currently in the testing phase, no additional items can be added until new capacity becomes available.
Benefits of WIP Limits
There are several benefits of establishing WIP limits. These include:
- Agile teams have an objective, standardized way to decline new requests and explain why tasks are not being fast-tracked through the process. While this still won’t make internal or external customers happy, it is far more agreeable than just saying “no” and being unfairly criticized as inflexible or lazy.
- Agile teams do not have to act like goldfish and dart frenetically from one item to another — which is not just inefficient, but it’s also exhaustive. Instead, they can focus on completing high quality work in the fastest possible manner, while minimizing distractions and interruptions.
- Agile teams can build slack into processes, which allows for collaboration, collective problem solving, necessary meetings, and other activities that are essential to high-quality work, yet are not captured as formal work items.
- Agile teams can more effectively identify actual and potential bottlenecks, and take targeted, practical action to alleviate or avoid them.
- Agile teams can make better use of available resources, and deliver persuasive, data-driven business cases to managers and executives if additional resources are required.
- Agile teams can cultivate a culture of support and teamwork — instead of “every woman and man for themselves” — which boosts engagement, performance, productivity, and accountability. This is particularly important and valuable given that agile teams must be inherently self-organizing and self-managed. With agile, either everyone reaches the finish line on time and intact, or nobody does.
- Agile teams can use the visual language of WIP limits+Kanban boards to significantly reduce the need for status meetings (please keep your cheering and celebrating as quiet as possible, there are likely people in your work environment who are on the phone).
A Final Word
Before joining the WIP limits party, keep in mind that there are helpful WIP limits, and then there are harmful WIP limits.
Helpful WIP limits are realistic, based on the available resources, firm and enforceable, and supported by a task management tool like Planview AdaptiveWork Go that was designed from the ground-up to support agile teams using Kanban, Scrum, and other methodologies (including hybrid).
Harmful WIP limits are blatantly unrealistic in either direction: either too much slack or too much work. They’re also circumstantial and therefore largely ignored, and try — but fail — to use spreadsheets, emails, and other ad hoc tools to keep everyone in the loop and on the same page.
