Three Ways to Avoid Crunch


runch refers to the period of time in which abnormal amounts of work are required, or expected, to be done in a short period of time. This period of crunch often occurs immediately before a major release/launch and usually lasts a couple of months. During the crunch, it can be normal for software engineers to be expected to work upwards of 60 or even 80 hours a week, and occasionally results in participants even sleeping at the office. The length of crunch and severity of it varies significantly by team, project, and industry, with the video game industry being the most notorious for it:

Crunch results from the fact that more work remains than there is time in normal business hours to complete it. Therefore additional ‘time’ is created by requiring people to work longer hours.

But why do projects get into the situation where there is more work required than time available?

Well, there are three main causes. Firstly, unforeseen events might occur during a project that slows down progress or generates additional work. This might be members of the team leaving, issues discovered with a solution after significant investment has already been made, or a global pandemic changing the way we work, for example. Secondly, mismatched optimism in a team’s capabilities, and excessive ambition when defining the project or the scope of a release. Thirdly, poor planning is often cited as a major factor in the need for crunch in the first place, as well as its length and severity.

Often the real cause is a combination of all of these plus a few other factors. As teams get large, and projects get complex, it can be extremely difficult to accurately plan how a project will play out. But once it can be seen that a project is trending towards a crunch, there are 3 main levers available to avoid, or at least soften, said crunch.

Image for post
Photo by C D-X on Unsplash.

Three options

The three options available are:

  • Increase the amount of time available.
  • Reduce the amount of work required.
  • Reduce the quality of the work.

Create more time

In order to create more time, you need to move out the end date. You can’t create more time under the existing timelines, but reconsidering when the project needs to be ready, or launch, is an option.

This can, however, be an incredibly tough call, and there are often many factors to be taken into account. Depending on the industry the project is in, the date, or at least the month, might be critical. For example, the video games industry is very seasonal, with the majority of sales happening in the months running up to December holidays. Missing that and launching in February can be extremely costly. Another example is software and projects that are parts of a larger product, such as a car or consumer electronic device, that need to be ready alongside that product. Delaying one project could mean having to delay additional projects, and have other knock-on effects.

If the target date is tied to a marketing event, such as a conference, rather than to a sales period or dependent product, then there are compromises that can be made. For example, announcing at the event but releasing independently. Marketing will still get their beat, and the project gets the coverage, but the release can still happen a little later with the extra time needed.

As mentioned above, there are many reasons moving the target date is not an option, so what else can we do? Reduce the amount of work needed to be done.

Remove features/reduce the scope

Reducing the amount of work to be done in the remaining time can be achieved by removing features, reducing the scope of features, or shrinking the surface area.

Removing features is again a tough call. Depending on the size of the project, and the features in question, it could significantly reduce the value of the final product. An approach less impactful to the product’s final value is to reduce the scope of features. This is particularly appealing if your project is one that will have continued incremental releases after the initial launch. The concept here is to focus on the minimally viable fulfillment of a feature and release that. Then begin improving it over time by fleshing out the pieces that were removed to reduce the initial scope. The other option is to reduce the surface area, which might mean releasing on fewer platforms (just Android instead of iOS as well, for example) or in fewer markets (saving the overhead of additional localization and other regional requirements).

All these actions are best taken as early as possible in a project, ideally prior to when potential crunch begins to loom. This is because each of these will likely result in wasted work. The time spent on work that will either never ship, or at least won’t ship in the current release, is time that could have been spent completing the objectively more important tasks that remained. On top of this, work getting cut after it has been started, especially later in its development, has a significant negative impact on team morale and motivation.

Reduce quality

If more time is not an option, and features cannot be reduced or removed, the only option left is to lower quality. There are many shortcuts that can be made to save time at the expense of quality, but they are all likely to result in losses that will cost the project later. That cost might be in the form of unhappy customers who need to be won back after bad first impressions, or in the instability of the project. An unstable project once released needs constant maintenance to prevent it from falling over. The cost will also be in the pride the team has in their work, and how they feel about what they have released.

Generally lower quality is a bad choice, but sometimes it is all that is left. Depending on the project, the corners being cut, and the availability of resources to address the quality gaps after launch, it is possible that this is the right option. But choose it cautiously.

What about more resources?

There is a fourth option, but I have intentionally excluded it here, and that is to increase the resources available to get the work done. This may mean hiring new people or transferring them from other projects or teams temporarily. I didn’t include this option because for many reasons it is often a nonstarter. Hiring new people takes time when done correctly and carefully. So, if a project is already heading towards crunch it is likely too late to do this. Even if your company is large enough that you can quickly transfer people from another project or team, there is still the overhead of ramp up that cannot be skipped.

In addition to the time required for this, it will also require those already on the project to devote some amount of time to help those new team members get up to speed. This means in the short term, you are actually creating more work for them to be done in the same amount of time, resulting in an increase in the crunch. Finally, once you have ramped up the new people and paid that overhead, you now potentially have the mythical man-month problem or at least added complexity to manage the additional people working on the same project in the short remaining period of time.

All of that is to say, adding extra resources is only really an option if considered much earlier in a project, before unexpected Crunch starts to creep in. Some might say in that case it’s simply good planning, not Crunch avoidance.

Image for post
Photo by Anthony Da Cruz on Unsplash.

Crunch has become one of the most divisive issues in the entire gaming industry over the past several years. One side feels that it is unavoidable and part of the job that developers sign up for when taking a job. The other side sees it as greedy publishers and studios making extra money on the backs of workers who are being overworked and underpaid for their efforts. There are options for reducing crunch, but they all come with a cost, so it seems likely that this will continue to be an issue in the years to come.

Post a Comment

Previous Post Next Post