Slack and WIP limits

Some weeks ago, I spotted in my threads an article with an unusual title, "Efficiency is the Enemy". I was intrigued: with such a title, surely it must be either a good one challenging the idea of Efficiency or an ironic one.

I didn't take time until this week to read it. But before I read it, I dug a few hours into another set of content I had postponed for a few days: DevOps Research and Assessment papers from Google.

Among the latter, I found a lot of things I would consider as "business as usual": practices I have either found at organizations I have worked at and with or practices I have worked to introduce in them. But one practice had me thinking: Work in process limits.

The reason why I refer to both the article and the DORA papers is that I can draw similarities between the two.

WIP limits

The introduction of the "Work in process limits" article sums up the concept nicely:

When faced with too much work and too few people to do it, rookie managers assign people to work on multiple tasks in the hope of increasing throughput. Unfortunately, the result is that tasks take longer to get done, and the team burns out in the process.
Instead, you should do the following: Prioritize work, Limit how much people work on, Focus on completing a small number of high priority tasks. – DevOps measurement: Work in process limits

It echoes the book by Will Larson (An elegant Puzzle) and James Stanier's course (Engineering and Product Collaboration) nicely: if you want to be productive, you better first prioritize the work, ensure people focus on the right priority and complete fewer tasks.

In the same post, we spot another nugget:

Don't relax your WIP limits when people are idle. Instead, those people should be helping in other parts of the value stream, addressing the problems that are leading to constraints elsewhere. – DevOps measurement: Work in process limits

This is very interesting to read: if your team members suddenly find themselves without work and idling, they should help elsewhere rather than stress themselves by picking another task.

To many teams I have worked with, that would be quite a surprise. Yet, that concept reminds me of another: having some slack.

Slack

And that's where "Efficiency is the Enemy" comes in. In the article, the author focuses on the concept of 'slack'.

Slack, adjective: not taut or held tightly in position; loose.

But by quoting T. Demarco's book "Slack: Getting Past Burnout, busywork and the Myth of Total efficiency" the author gives us a much nicer pair of definitions:

“the degree of freedom required to effect change. Slack is the natural enemy of efficiency and efficiency is the natural enemy of slack.”

and

“Slack represents operational capacity sacrificed in the interests of long-term health."

This nicely evokes the WIP limits we just discussed: if we don't have WIP limits, then we will never have slack, and we endanger our long-term health and growth.

More slack to be more efficient

The conclusion is relatively simple: if one wants their team more efficient one needs to ensure they are not continuously running after every second to fulfill a hyperactive agenda. Focus on the right few priorities is important. To echo the first part of this article: contrary to what inexperienced managers might think the way to do more is by cramming less on the team's to-do list.

We will soon talk about this topic in this journal so don't hesitate to sign up to receive the next update directly.