Your Company's Problem is Hiding in Plain Sight - High Work-In-Progress (WIP)

You Need Lazy People to Have Restless Features

My birth was a highly unlikely event that hinged on my grandfather’s ability to conceal a cookie tin.

Yes, you read that right: a metal box for storing cookies like this one:

You might be wondering, what makes the cookie tin so special that there is a relationship with me being born?

Let’s connect the dots by telling you the story behind the cookie tin.

Meet my grandfather, Wijnand Johan Leo Dalmijn.

He was a daredevil involved in triple risky business:

1. He was part of the Dutch resistance in Arnhem.

1. He was part of the Dutch resistance in Arnhem, and the Germans shot off his right arm. Talk about sticking out like a sore thumb. The nazis were on the lookout for a one-armed resistance member in the region of Arnhem.

2. Despite losing his right arm, he kept communicating with the Allies and the Resistance over the radio from the attic in his house.

Illegally communicating over the radio was a perilous endeavor. If you were caught, you could be interrogated and tortured. It frequently ended with you being fusillated.

Wijnand was an amateur radio communications expert with the callsign ‘PA0DD’. He had built his own radio to communicate with the Allied forces and the Dutch resistance. The Germans didn’t like this and actively searched the area to find out where the radio communication was happening.

My grandfather had built a radio inside the cookie tin, which he had hidden in the kitchen. The cookie tin was the first thing you saw when entering the kitchen. My grandfather saw the radio in plain sight every morning, at lunch, and at dinner.

If anybody had lifted or moved the cookie tin, they would have immediately realized it was no cookie container. And because it was the first thing you saw after entering the kitchen, you would think the Germans would find it easily, too, right?

Wrong!

The Germans performed multiple house searches, yet they never found the radio. They incorrectly assumed nobody would have the audacity to hide the radio in plain sight. The hiding place was so obvious they never took it seriously.

Had my father, a little kid back then, accidentally slightly moved the cookie tin so the radio knob that was sticking outside of the cookie tin would have been exposed, likely, I wouldn’t have been born.

Wait, what does this have to do with software development again?

What Does This Have To Do With Software Development?

I work with companies and customers all over the world, and they often complain delivery isn’t going as fast as they’d like. This is a pretty normal problem because almost nobody is happy with how fast new features get delivered. The rate of ideas is always greater than the rate of delivery, and hence it’s always going slower than people want.

Almost every single time, upon closer examination, one of the main culprits of slow delivery is a high Work In Progress (WIP), also known as working on too many things at once.

And when you express, this is the problem, what you will frequently hear:

“But we have so many things to do and that we want to do, there is nothing we can do about it.”

Like the radio cookie tin the Germans were searching for, the problem is painfully obvious and immediately visible: we’re overextending ourselves with work. But since it’s one of the first things we notice, and it’s too obvious, we walk past it to find another less obvious problem. Then, we direct our attention to these less obvious issues.

If you have high WIP, that’s the problem you should be solving. High WIP is killing your business, innovation, and morale. It means everybody is stressed and busy, without significant results they can be proud of. All their work isn’t even worth it if you look at the progress. Trying to push features to production feels like a Sisyphean ordeal of trying to push a rock up the hill that keeps falling back.

There is such a thing as picking up too much work. If we work on too many things at once, we will create a traffic jam of work. We will be busy squeezing the steering wheel and fully busy with driving, but we’re not moving. It’s like the cashier at the supermarket who is 100% busy: a line will form. In software development, that line of customers are the features you’re working on. All those features are waiting to be completed.

To make matters worse: software development is a collaborative effort. When you’re too busy, the work is not only waiting on you, but the work of others is waiting on others, too. Being dependent on others makes being busy exponentially worse, as you will be suffering from a traffic jam of work that cannibalizes everyone’s progress.

How do you know you’re suffering from a traffic jam of work?

12 Signs Your Work-In-Progress Is Too High

Here are 12 signs you might be suffering from high WIP:

1. If you need help from someone on the same day, you won’t get the help you need because they are already fully booked.

2. If something unexpected happens that isn’t planned, everybody gets annoyed as they are already overextended, and you immediately get delays.

3. When you try to plan a meeting with someone in the same week, you struggle to find an open spot on their calendar.

4. You feel exhausted at the end of the day because you’ve constantly been switching contexts and tasks.

5. There are frequent production issues and emergencies because, due to all the context switching, nobody has the headspace ti properly focus on quality and scalable solutions.

6. You suffer from frequent delays upon delays, and the delays create new delays.

7. When you’re in a meeting, you notice that people aren’t really paying attention and trying to rush things through because they have so much work to do, and the meeting distracts them from doing more work.

8. People turn their webcams off in meetings so they can work on other things during the meeting and get all the work on their plate done.

9. People frequently complain about having so many meetings that they’re unable to do deep work.

10. Teams are unable to set a clear goal for their Sprint because they are always busy working on a gazillion things at once.

11. If you ask managers or team members to write down all the objectives we’re working on from memory within a minute, they cannot do so.

12. When you create a roadmap, you struggle to visualize what’s on it because there is simply too much going on.

Now that we know some of the symptoms of high Work-In-Progress, what should we do about it?

To Complete More Features, Allow For More Laziness

The answer is simple yet counterintuitive: you must work on fewer things simultaneously and allow for people to be more lazy. It might feel like you’re lowering the bar, and settling for mediocrity, but that’s exactly what you need - people being more idle. Too many busy people mean idle and lazy features.

A good example of this is how most hospitals function. Doctors and machines are scarce expensive, and they want to keep them busy. What happens to the patient? They’re always waiting and it always takes longer than expected.

If developers are fully busy and stressed, then progress on features stalls and becomes sluggish. If all the cashiers in the supermarket are 100% busy, a queue of customers will form. That queue of customers is costly, because some of them will leave if waiting takes too long and not buy anything.

In software development, those delays are even more costly than the delay at a supermarket. You’re delaying the value of the feature, which comes at a cost: the cost of delay. Every week you’re delaying a feature, it’s costing you money equal to the cost of delay.

We become so obsessed with planning tetris and making sure that every developer is busy, that we forget about the most expensive thing of all of them: features that move at glacial pace due to high WIP.

It’s fine if developers have slack built in or have time to do other things like working on their personal development. It’s a healthy sign of a system that isn’t optimized to keep everyone as busy as possible. We want to optimize for delivering value quickly. Counterintuitively, this means that people shouldn’t be fully busy, as then features will begin moving at a glacial pace.

If everyone is fully occupied, you can be sure your features are chilling and vibing at the pool. Everybody is sweating and scrambling to bring all those features strawberry daiquiris while they remain stationary and soak in the sun.

Being too busy isn't a badge of honor. It's a symptom of dysfunction. It's a sign your system optimizes for keeping people busy over keeping the work busy moving.

Don’t let your developers sweat, make your features sweat from moving so fast. If your developers are always sweating, you can be sure your features are not moving and relaxing at the pool.

A quarter of the work in triple the time is a terrible deal, yet it’s what most organizations sign up for when they push in too much work to their teams.

Allow your organization to be more lazy: you need lazy people to have restless features.