When You Are At The Bottom Of A Hole

When a team is behind its targets, the natural instinct is to work even harder to catch up. Sometimes though, the best thing you can do is… nothing.

Let’s look at a team. For various reasons, they have done several sprints' worth of work with no test environment available. How can this be? Let’s just imagine that they work for a hypothetical large company with a ludicrously complex process around setting up test environments. I’m sure such things never happen in real life, but just go with me on this one.

Anyway, the team, despite having worked hard for the last few sprints, haven’t been able to close any stories because they couldn’t be tested. So their velocity has been pretty much zero. They are now under a lot of pressure to show some progress. The test environment is finally available, the testers are ready to go.. but still nothing. Why?

Let's look closer – the developers have built up a big pile of work which is sitting in a “ready to test” state. In Lean terms, this is Inventory and students of Lean know that inventory is waste. Not only is inventory a source of waste just on its own, as I described in an earlier post, inventory also causes other types of waste. It causes defects because it represents untested work, it causes process waste because all that work in progress has to be tracked and managed.

We can visualise the development process as a pipeline with stories flowing in one end and completed features flowing out the other. The diameter of the pipeline reflects the amount of work that can flow down the pipe at that stage. Ideally, you want the pipeline to be the same width all the way along so things can flow smoothly. In our case, we have 5 devs and 3 testers so the pipelines are fairly well balanced. The testers can generally keep up with the team except when things are really flowing fast.

When you push liquid from a thick pipe into a thin pipe, you get an increase in pressure and turbulence. If the flow rate is low enough, the turbulence will dissipate and things will flow smoothly.

If the flow rate increases above a critical point though, the turbulence will expand along the pipe and the flow rate will drop to zero. Even though the pipeline is full of water. This is what has happened here. The team’s velocity can be pictured in our pipeline example as being stored in a big holding tank connected to the development pipeline. As work is completed but not tested it is diverted into the holding tank. When the test environment became available, the team opened up the valve on the holding tank and let out all that work. All in one go.

This massive influx of work into testing caused turbulence. To make matters worse, in the name of catching up, the developers were busy trying to develop new features at full speed. In essence, they were taking a pipe that was already experiencing turbulence and madly dumping water into it as fast as they could carry it.  As all pipelines do under these conditions, it backed up.

In this case it was a flood of defects which caused frequent updates and instability in the test environment which slowed down testing and caused additional false defects to be raised when the testers didn’t know whether to blame the feature or the environment for an issue. This in turn slowed down fixing real defects and so on. The defect management system became complex and there were so many defects floating round the system that people spent more time working out what the priorities were, than actually working on them. Meetings were held to refine the defect management process and further meetings on why progress was slow.

The pipeline became completely blocked and no one could make any progress.

So what to do? The answer is nothing. The best solution in this case is for the developers to do nothing. Stop working on new features and let the pipeline clear. Fix defects and spend time reducing turbulence in the pipeline. Once the backlog is clear and things start flowing again, then go back to new feature development. Even better, limit the flow of work from the “to be tested” backlog into the pipeline. Keep the flow rate manageable and the turbulence will never form in the first place. Focus the team on getting the top priority story or maybe a couple of stories out of the storage tank and through the rest of the pipeline. Then release the next batch. Keep the flow small and manageable.

When you are at the bottom of a hole, the first thing to do is stop digging. If you find your pipeline backing up, the first thing to do is shut off the tap and let the pipeline clear.

Sometimes the best thing to do… is nothing.

Cheers

Dave