«    »

Crunch Mode

I have recently experienced two episodes of 'crunch mode' - the flurry of activity prior to deploying new functionality into production. The crunch happens because there is insufficient time to do everything that needs to be done. To compensate, people work longer or take shortcuts like skipping thorough testing. The result is often a higher rate of defects and shortcomings in the released application. I have spent several days recently during crunch #2 fixing and cleaning up a production defect introduced by crunch #1, and I wonder what new problems are lurking, waiting to be discovered.

I generally do not like operating in crunch mode, and I think it should be avoided whenever possible. The time 'saved' while in crunch mode is spent plus more afterwards reacting to and cleaning up the problems that the crunch has introduced. This is especially true for enterprise business applications, which are typically expected to be used and maintained for years. In this context, forcing a crunch mode to make a release a few weeks earlier is a questionable strategy. I have heard many stories of what I consider artificial crunch mode, where the imposed time constraints causing the crunch are arbitrary, frequently imposed by management for apparently no rational reason. Poor project management sometimes leads to crunches due to problems like overly optimistic estimates. Even with the best managers, however, crunch mode can still happen due to changes or events imposed by third parties like senior management, marketing, or the client.

If we cannot entirely eliminate crunch mode, how then can we lessen its negative impact? In my article on understanding project schedules I described the four factors that determine a project schedule: time, resources, scope, and quality. In crunch mode, the time and resources are typically fixed and insufficient for the amount of work to be done (the scope). I believe the main priority is to avoid taking shortcuts which comprise quality, as that is the most expensive to rectify afterwards. The best strategy is to minimize the scope as much as possible. While it is seldom possible to cut entire features, it is often possible to negotiate on specific aspects of each feature. Often slight simplifications in the requirements for a feature can greatly reduce the effort required. A related approach is to accept a certain number of low-impact defects in the application. This is often much less risky than rushing to fix these defects and possibly introducing new problems.

If you find this article helpful, please make a donation.

One Comment on “Crunch Mode”

  1. [...] in Crunch Mode right now and sparing more than a few minutes a day on this is a luxury (as would doing anything [...]

«    »