Every development team has a heartbeat, a metronome that governs the rhythms of development.
Defying the invisible meter that governs development causes consternation and increases your chance of slippage. For example, we develop in two-week iterations - that's our basic time frame.
An Example of Conforming to the Meter
We count releases in number of iterations. Since we tag every iteration, a release is just a special tag (it gets a name!).
An Example of Defying the Meter
We have XP customer team meetings weekly. This is, among other things, a chance to rejigger the priorities. Usually priorities don't change much, but occasionally they do. Sometimes, this means we're changing priorities mid-iteration.
You mean that we're halfway through doing some of these and you want to change it? Enter inefficient processes. Now we have to:
- Figure out how far through the current (now older) top priorities we are.
- Put the new priority in place
- Make everyone context switch.
Sometimes you have to do this, but be aware of the cost. It costs time, it costs code overhead, it costs code instability (a half implemented feature is incredibly unstable).
So when you set your development metronome, try to set everything else - your product management input to development, your test cycles, your releases etc. Make exceptions just that.... exceptions.