How I Cut Development Time to 1/3rd

A familiar reprieve from many consultants, agilists, and others is, “There are no silver bullets.” I’m going to describe the closest thing I know of as one, and it is also the most controversial thing I bring to my clients.

A Word Of Warning

Just like the metaphor about silver bullets, this technique is hazardous to use without guidance. How bad can this get? Your people will quit, and you’ll look like someone trying to destroy the company.

Constant Work-In-Progress Limit

Alright, so let’s get down to what the technique is. I use what is called a constant WIP limit. Now, this is a little different than how many tools and groups understand a WIP limit to behave, so let me get into how this works.

What is the process?

When we apply a WIP limit, we apply a restriction on how much work can move through a process. So the first thing you have to think about is what the process is you want to improve. I almost always work with development teams and program folk, so I apply my technique to each level and their respective processes.

The next part about this is that the process has to be visible, and the work similarly visible. You can’t limit or improve what you can’t see. So if you’re relying on email or meetings or word of mouth, this will not work.

Lock it down

After the process and work are visible, I place a restriction on how many things can be in that process. So let us take your very typical development team. They’ll have their work on a wall or in something like Jira with their process outlined like, todo, doing, and done. Pretend I say the limit is 5. That means that the process where things happen, “Doing” can only have 5 items in it. There are no exceptions to that.

Let’s imagine a slightly more involved example where the process has something like, todo, design, code, test, review, done. The todo and done aren’t the things where work happens, but the rest are. If I put a limit of 5, then only five things can exist across design, code, test, and review. That is five total, not five per section, or five per person.

The starting point

What number do you choose if you are going to try? I take the number of people involved and cut it in half. So if I work with a development team that has eight people, the limit is 4.

Okay, so I can imagine people thinking about why not 6 or 5 or 7, or 8? Well, I haven’t explained how this works yet, but most simply, lower is better. So you might feel like what I’m suggesting is extreme, but it isn’t. This is also only where we start. You can lower it more over time.

What to watch

Now that you’ve got things visualized, and cut the limit to half the number of people, it is time to get serious about health and results. In terms of results, you’ll be able to notice an almost immediate drop in the time it takes for work to finish. We call this cycle time, and many tools will calculate it for you. For many groups within the first month, they’ll drop to 1/3rd of the time it took for any item.

If work took 15 days as it so often happens for teams doing 2-week sprints, work would suddenly drop to 5.

Next, you’ll want to keep an eye on how many things get done. This number will likely improve as well, but not as much. Last, you’ll want to keep an eye on quality. Quality will go up as well, but you’ll often have to ask around as many groups do not measure quality in any significant way.

Team health

I gave a warning first because living with this technique is, for many, one of the hardest things they will experience. That is not an exaggeration.

Applying this technique recklessly will cause burnout, breakdowns, and people will quit.

Spend time with everyone involved as often as it takes to help them as they go through this process. If you can’t make time for them daily, you should not attempt this at all.

I’ll also mention that I never do this unless the team has been forewarned of the difficultly, agrees, and can end it.

Why is this so hard? Well, because working this way is the opposite of what people are taught to believe is right for starters. Half the team will suddenly have nothing to do, and that is very distressing since many companies reward how busy and overworked people are. Next, when people do work, they’ll find things are a lot harder because they have to stick with things until they are done instead of bouncing to something else if something goes wrong.

This limit acts like a polished mirror showing people all their blemishes.

Many developers wind up unlearning many habits they’ve picked up as they have to bring work to a complete state. They also have to learn to help one another more than before and see problems as things to solve instead of avoiding them.

None of that is easy and needs a lot of patience and support.

Results

So final thought, the way I do constant WIP limits are outlined here, but its only the beginning. After I assess them, many groups will often see an improvement from 4x to 10x in the speed of delivery with better quality, and after the stress ends, a far more relaxed environment.

But the question is if your teams could deliver 10x as fast, what would you do with it?