I would like to reiterate my position on crunch mode.
Crunch mode can work under the correct circumstances.
I was reminded of this topic while searching the web. I came across a
site by Eugene Wallingford.
He points out that the "Agilistas" are so focused on the issue of
sustainable pace that it is rarely mentioned that "crunch mode" can
I suppose the Agilistas do this because they are fighting what they
consider a bigger battle and can't open the discussion until
management understands that sustainable pace is important.
Here is a snippet from Eugene's site:
At least one person, though, argued that crunch mode can work. The
gist of SirGilligan's claim is that a software team can go faster and
still do quality work -- but only for a well-defined short term. He
even used a running metaphor in defining such a crunch time: 'We are
not 1/3 along the way, we are in the straight-a-way and heading for
the finish line'. How can developers win the expectations game in
such a scenario? The end is clearly in sight:
'Pending features are well defined. Order of feature implementation
is defined. Team is excited for the chance to deliver. It is the
team's choice and idea to crunch, not some manager's idea. We enter
crunch mode! After we deliver everyone gets the following Friday and
Monday off for a four-day weekend!'
That sounds an awful lot like what a runner does when she races a
marathon or half-marathon faster than she thinks otherwise possible.
The pending goal is well-defined. The runner is excited to deliver.
She chooses to push faster. And, after the race, you take a few days
off for rest. A party, of course, is always in order!
I think the great ones are able to manage their expectations in a way
that allows them to do more than usual for a short while. The good
news for the rest of us is that we can learn to do the same, which
gives us the ability to succeed in a wider variety of circumstances.
Just always keep in mind: You can't keep going faster indefinitely.