How to avoid video game development crunch

This week has been dominated by a recurring conversation that happens frequently in the video games industry - the matter of crunch.

Although 100-hour weeks are certainly not normal in games development, having to put in multiple extra shifts during deadline periods is not uncommon.

Yet crunch is not just bad for staff, it can be bad for business. There's plenty of evidence that tired, over-worked staff perform well below standards. When I worked in QA myself, some 11 years ago, the bugs I reported for Ratchet & Clank: Tools of Destruction at 3am one morning needed completely re-writing the next day. They were unreadable. Crunch is bad for the team and it's bad for the business.

Avoiding these issues, however, is not easy. Simply saying that it's down to 'bad project management' isn't especially helpful to anyone. What is bad project management? What is good project management, for that matter? What tips and tricks could be employed to reduce overtime and crunch as much as possible?

Last week we revealed the Best Places To Work in the UK: a timely reminder that not all games developers are suffering. Within those group of winners, a large proportion of them boasted about "zero-crunch policies" and "avoiding crunch at all costs". So we asked a few of them if they'd be willing to share with the world their advice on preventing crunch from happening.

This is what they said:

Casper Field, Wish Studios (Small Sized Company Winner)

"I worked some pretty horrendous hours in my 20s when I was establishing my career. Starting out in journalism in the '90s, I was normalised to the idea that 12 to 14-hour days, even working through the night on a heavy deadline, was what it took to get the job done. But as I've learned over the years, the issue was down to a combination of commonly occurring issues. These I would summarise as: poor planning by (often inexperienced) managers; under-staffing of the team; over-specification of the product; and refusal or inability of middle management to push back on demands from above or outside. It's usually a fatal combination of those factors.

"The myth arises that working late will fix the problem. To be fair, if used very sparingly, for a day or two, I think that additional hours can help if something is in crisis, but over the long-term they are never the answer. The solution is to plan sensibly, to trim specifications, to hire enough people, and to learn that it's okay to say no to external forces now and then.

"Equally, you cannot lean on just one of those solutions - it has to be a mix. Is it really worth staying late to implement a 'cool' feature that 95% of users will barely notice? What are the knock-ons of that feature on other parts of the development team? I would argue it's a waste of time, or even worse, outright risky for the entire project. I think that that the decision making related to feature planning grows more confused and less logical as accumulated exhaustion kicks in. I know, because I've done it myself.

"There is a dangerous notion of team members being 'heroic' when individuals pile into problems and crunch like crazy to fix them. I find this entirely toxic and incredibly risky"

"You also need to be honest with your team - it might seem cool having people start at 10am or later, but that leads to leaving at 6.30pm or later - there's still a working day to be done. That's why at Wish we operate a standard 9am to 5.30pm working day, with an hour for lunch that we encourage people to take (and to get out of the office, or at least sit in the kitchen, to get away from their screens). We flex 30 mins earlier if it helps with school or travel, but that's it. Come in, work your day, go home, live your life. Similarly, eating pizza while 'working late' usually means you're not really working, you're just sat around the office ordering and eating often middling-quality food while not achieving much at all. And, how much more frequent are bugs in code that's written and art that's checked in at 10pm, versus work done in the normal working day?

"There is a dangerous notion of team members being 'heroic' when individuals pile into problems and crunch like crazy to fix them. I find this entirely toxic and incredibly risky. What does it say about accountability, about planning, about culture? If you're at the point where this kind of behaviour is necessary, guess what? Someone, some people, messed up badly, and there's nothing 'heroic' about it - it is indicative of a failed process, and it should never be celebrated. Back to where I started out, as a young, inexperienced team member, I should never have been put in the situation of working week after week of 12-hour days, of working through the night. 20 years later, I know it still goes on in some places, and it is well past time that we, as an industry, make clear that it is unacceptable."

Shaun Rutland, Hutch (Mid-Sized Company Winner)

"Avoiding crunch is fundamental to the way we operate. As a mobile free-to-play games-as-a-service company that serves millions of daily active players, we need our team to be happy and productive, so crunch simply doesn't work. 

"Teams who are having fun make better games and making games should be fun - otherwise, what's the point? We have a responsibility to our staff to ensure our development culture and processes foster a productive, creative and motivating environment. There's always enough work and urgency from our players that we could easily ask them to work 12 hour days, 7 days a week. There's just no let up in our opportunities so we simply never allow it to happen, its zero tolerance attitude towards crunch. 

"Ultimately, crunching is a result of feature creep, design iteration, poor planning or, most commonly, an all-or-nothing approach to design, which is often mandated from the top down. Understanding and appreciating lean development is about understanding what is valuable to the players and prioritising the core quality of the product over everything and trusting your team to execute and understand their audience. We have greater access to our players than ever before, with beta programs, early access systems and soft launches now commonplace, there is no excuse.

"Ultimately, crunching is a result of feature creep, design iteration, poor planning or, most commonly, an all or nothing approach to design, which is often mandated from the top down"

Here are my key tips:

1. A leadership team that fundamentally understands that crunch doesn't work as a planning option. When developing games-as-a-service the workload increases and evolves after launch once you are supporting a community. If you've burnt out the team by the time you launch, you're not putting yourself in position to succeed.

2. The leaders in the business need to lead by example, avoid sending important emails on week nights or weekends and encourage holidays and long breaks. Your next big idea will come from rested and motivated staff returning from holiday. 

3. At Hutch, we use Lean methodology, we find the value for our business and players as quickly as possible, if we are working on something that takes a long time, we break it into smaller and manageable pieces of work. Our teams are encouraged to estimate honestly, it's this honest bottom-up approach to planning that enables the team to make the right choices and manage their own work and time. 

4. Bottom-up planning means staff are defining how long it takes and therefore are accountable for their estimates. Sprint retrospectives enable the teams to reflect on their planning accuracy, which then makes planning in future better. 

5. Adopting agile and lean help with better planning and ensuring good work life balance.

Saying all that, we are in no way perfect. Our team, on their on volition, sometimes work long hours because they either feel they need to or want to, so there's still some work to do on this. By getting our team to define their tasks and fostering an accountable and inclusive culture for planning they're taking responsibility for their work load. As we are services company, we do require after hours support from engineers from time-to-time. We rotate this across the team and ensure they're not doing excessive hours as well. 

But in summary, you need leaders who fundamentally understand that crunch doesn't work in the long run. GaaS is ideal for moving away from date driven/feature-bloated development. And empowered and responsible teams that define their own work schedule ultimately plan better and deliver better work.

We will be updating this feature with more responses from the Best Places To Work Awards winners as they come in.