Crunch Mode And Making Superstars Average

A recent set of posts by James Golick and Reg Braithwaite discuss the often overlooked realities of how putting teams into "Crunch Mode" can have undesirable results.  The discussion looks at various ways applying pressure to a team often results in putting your project into not better but worse shape and how teams and managers might benefit by taking a different approach.

The initial postulate posed by James Golick is that "Crunch Mode" initiatives have the ultimate, and ironic, effect of decreasing overall productivity by turning your all-star programmers into average programmers.  Golick's primary assertion is that the habits making your best programmers highly productive in the first place are likely to be the first habits to be shed when the crunch mode kicks in:

That is probably the biggest difference between your great developer and the average developer you went through so much trouble to avoid hiring;  your superstar's priority is the code, whereas the average programmer's priority is going home at the end of the day. When you flip that crunch mode switch, though, priorities change.

When everybody is racing to accomplish a set of tasks for a certain date, coming in to work every day is about trying to get as many of those features out the door as possible in as short a time. The pressure is on.  People start cutting corners.  Processes break down.  People write fewer tests, refactor less frequently.  You have effectively turned your superstar team in to a group of average programmers.

Golick continues by outlining additional reasons why pressuring a team may be likely to have a negative outcome:

Sending your team on a death march quickly leads to programmer fatigue, which nearly always leads to bad code. Moreover, developers are likely to become demoralized, burnt out, lose interest in the product, and perhaps worst of all for you, they'll become resentful of management. Moreover, in many cases, due to nasty bugs, and later hits in maintainability and consequent necessary rewrites, the crunch mode developer is outputting less in total.

The post goes on to offer two suggestions for programmers to heed in order to avoid "Crunch Mode" defeat:

1. Forget about the pressure.  Avoid the trap of trying to save time via neglecting to follow the practices that make you productive in the first place.
2. Just Say No.  The most responsible thing you can do is to ensure your stakeholders fully understand the consequences of demanding more work be completed than you can do without sacrificing quality. 
   

You're the one who is going to have to maintain this nightmare when crunch mode is over (and we know that there's never really time for a cleanup). Your company is going to have to deal with low quality software, and likely a botched release. Everybody loses.

An earlier post by Reg Braithwaite touched on this second point of "saying no".  Braithwaite agrees that, as a software professional, one has a certain level obligation to stand up for the way they intend to execute their craft, but that under many circumstances there exists a point at which they are best suited to accommodate the stakeholder's requests:

I can be swayed into going against my instincts if the person who bears the consequences of the decision insists on following their judgment ...  if [on the other hand] I am asked to develop software that is insecure and places private user data at risk, I will make the personal choice of saying no.

In response to Golick's post, Braithwaite added to the discussion by challenging that many "Crunch Mode" initiatives are not the exceptional, "just this one time" events managers might justify them to be.   Braithwaite asserts that a "Crunch Mode" effort is not an exception if it happens frequently or if it could have been planned in advance, and offers much challenge to what many managers and developers commonly write off as "unplanned things" upon the onset of a "Crunch Mode" initiative or failed project.

I may not know exactly which bug will arise, but I know statistically that bugs happen, that requirements come into focus, and that estimates are just estimates. I do not say to my boss, “I had no idea they wanted a view for this behaviour, I had no idea this other thing wouldn’t work as expected, therefore we need to finish the work without testing.”

I can—and do—expect these things to happen, and therefore I can—and must—plan for them.

For another view on why to avoid shortcuts in agile projects, see this InfoQ news post.