Team Powerhouse had problems. The developers didn’t know how much work they could get done in a sprint. The testers received the code about a day before the sprint demo. About half the stories got pushed to the next sprint. All in all, it seemed normal to me. They had just formed, and some chaos seemed reasonable.

Say What?

When organizations change, the old way of working doesn’t work any more. Work flows change. People get put in new groups. Agreement hasn’t formed on what we’re going to do, much less on how we’re going to do it.

Chaos reigns. In a picture it looks like:

How Does This Apply to Software Development?

You can put almost any two inter-related labels on the axes. Common ones I use in software development include “Requirements/Technology” and “What/How“. The closer to agreement you can get, the less chaos exists.

While Chaos may seem bad, it can provide energy and freedom to innovate if the organization has created safety around the change.

It is important for people to understand and not be surprised by this neutral zone, for several reasons. First, if you don’t understand and expect it, you’re more likely to try to rush through or even bypass the neutral zone-and to be discouraged when you find that doesn’t work.

Second, you may be frightened in this no-man’s-land and try to escape. … To abandon the situation, however, is to abort a transition, both personally and organizationally-and to jeopardize the change.

Third, if you escape prematurely from the neutral zone, you’ll not only compromise the change but also lose a great opportunity. … so here let me simply say that the gap between the old and the new is the time when innovation is most possible and when the organization can most easily be revitalized

The neutral zone is thus both a dangerous and an opportune place, and it is the very core of the transition process.1

So What to Do?

Understand your employees will experience some chaos during the neutral zone.