You probably know the quote, “it’s not a sprint, it’s a marathon.” Usually used in reference to long term thinking, resource management and prudent planning. However, if you work in games a “sprint” will likely remind you of how work is structured into similarly named time blocks of 2-4 weeks1. One sprint follows the other in a never ending line. So, while the saying suggests that you need to pace yourself, measure your efforts towards the end goal, and save your strength for when it matters, reality puts you in a state of constant sprinting.
Of course, at that point it’s not really a sprint at all. At that point, you are a jogger, pretending to sprint to keep up appearances.
The basic idea is rooted in Agile; a much-interpreted and widely adopted ideology within the realm of project management. Especially in game and software development. Many will tell you that Agile was never meant to be constant sprinting, and I agree, however this argument fails to address that it is what we’ve ended up with regardless. As with all ideologies, there are multiple camps. And like all ideologies, there are good intentions and useful ideas to be found, but putting too much weight on the wrong parts leads to needlessly rigid, misguided, and sometimes extreme implementations.
The Cult of Scrum
One such Agile implementation, or framework, is Scrum. It comes with several recurring “rituals” conducted by a “Scrum Master”. Yes, those are the actual terms, and yes, it has a cult vibe. The core idea combines accountability with planning, enforced by regular meetings (aka rituals) where the PM (aka scrum master) walks through the steps outlined in the Scrum guidelines. The regular meetings include: Sprint planning and retros, daily stand up, and backlog grooming. Pretty standard stuff, once you strip the ridiculous terminology away. So, what’s the problem?
The problem is that it doesn’t work as intended. It kind of works with a lot of tweaking, overhead and even fudging. The larger the game studio, the more of this you are likely to see.
One-Size-Fits-Nobody
Different teams work with completely different mind sets, expectations and needs. Squeezing all this diversity into a highly structured approach causes frustration, usually because of the time spent on meetings vs. production, the minutia of updating work items, or a feeling that the PM/management decision making is out of touch. Scrum tries to be one-size-fits-all which isn’t well suited for highly specialized teams. Environment artists approach their work differently than database engineers do theirs and forcing both to follow the same strict process should be an obvious, terrible decision. Yet, here we are, and it’s somehow the industry standard.
Now, if all your work fits nicely into 2-week pockets, you may not be able to relate to this. Small indie studios are also much less affected, generally speaking. If you can’t relate to anything in this article, I say – without any intended sarcasm – good for you! However, I hope you can appreciate that others may have a different take.
In my experience, Scrum unintentionally promotes the worst parts of constant sprinting, mainly due to its high number of meetings.
It’s All in the Numbers
Eventually, teams begin planning work so individual components can be finished within a sprint window, regardless of whether it matches reality. Some prefer writing out work items in the system that matches the work done, after it was finished. That way your time estimates are always accurate. As dumb as this sounds to outsiders, all this can usually be boiled down to making numbers look good on a report.
Once focus drifts to prioritize reporting, the sprints become more about completion rates, burn down charts, and making the team look like they know how to plan their work without taking on too much or coming off as lazy. After all, poor performance might attract unwanted attention when the next round of layoffs come around. Sadly, many team managers and producers out there are stuck with doing this dance as one of their main responsibilities.
What ends up happening, is that each team tweaks the process to fit their needs and get the work done, while trying to look as good as possible on the report. A large portion of work becomes about communicating progress in a way that fits into this pattern and may create a weird competition between teams, where there isn’t a winner per se, but no one wants to be the badly organized team on the bottom, or the team that over-plans and under-delivers. Whether or not that is the case comes down to those who receive said reports, and the culture they are fostering.
If you are reading this, and you’re in this group of stakeholders: studio leadership and upper management, I urge you to give this some thought. How much of this applies at our studio? Is it happening, and I am not even aware of it? What can be done?
Making Sprints Matter
The original idea of the sprint, is that you take a portion of time and spend that time narrowly focusing on a limited scope. You put in all your efforts toward achieving clearly defined goals within this allotted time, often a deliverable of some kind, after which you go back to work as usual. The finish line is not supposed to also start the next sprint, unless it’s a relay and a whole new team is standing by to take over. If that is really the case, I hope your documentation is good. Bottom line is this: No one can keep sprinting and pushing forever and still give 100%. That is how you end up with people trying to game the system, play politics, or simply burning out.
The 6:2 Ratio Split
What if teams worked for 6 weeks in a more freeform structure, where they don’t have to stop and think about story points and sprint retros, and in the meantime, the PM team alongside the team leads, can plan an actual 2 week sprint with a theme that fits where we are in the process. Everyone executes the sprint together, pushing to reach the goal, and when it’s done take a moment to celebrate it, and talk about lessons learned and all that good stuff. The stuff which tends to feel forced and easily forgotten, when sprint retros are held every 2 weeks.
Note that the non-sprinting weeks aren’t down time, either. There is still work to be done, and likely deadlines that fall outside of sprints. The difference is that while not sprinting, the individual teams are free to approach the work in any way that works best for them.
With a 6:2 split, you end up with 6 sprints per year, one every other month, compared to 26 if you never stop sprinting. However, you’re actually sprinting and not simply jogging along. I am not a behavioral scientist but I bet, if you compared this approach with constant sprinting, the productivity would be similar but with higher satisfaction among the majority of the people doing the work. I would even go so far as to say, using Scrum might work too if you don’t keep sprinting.
Isn’t That Crunch With a Different Name?
No. First of all, crunch is where workers are pushed to work long hours, sometimes sleeping in the office, in an effort to meet some insane and unchangeable deadline. Crunch is the result of poor planning at the highest level, usually starting with deadlines being set based on publishing and marketing rollout, without proper consideration for setbacks, individual team capacity, cross-team interdependency, vendor availability, recruiting and all the other variables involved.
The Sprint Purpose
The purpose of the sprint is to push for completion of specifically scoped work. Pushing, in this context, does not refer to pushing your personal life out of the way. Instead, if refers to putting other work-related projects and tasks on hold for this limited time, and instead put those efforts toward the sprint goal. And again, this only works if you are not constantly sprinting, which is why I suggest a split.
Experiment With the Format
Please don’t take the 6:2 ratio as some kind of rule, it’s just the ratio I would start with. If a different split ratio works better for your studio or project, by all means go for it – my point is simply this: Constant sprinting is bad and I encourage you to try a different approach.
One variant that I have seen a few times, which I don’t recommend, is that every so often a sprint is removed and developers are encouraged to work on pet projects or those nice-to-have things they don’t usually have time for. But it rarely works out like that in my experience. Instead, these non-sprints become unstructured catching-up-and-backlog-cleanup sprints. Best case scenario, it will feel like a short moment to re-orient before the next leg of the sprint-marathon begins. In this variant, the ratio is reversed and looking more like 2:10.
I would love to know if you have tried a split ratio or other alternative to constant sprinting, and what your experience was with it.
The Plug
Incidentally, I am working on a book on game production, where I will be exploring this and similar topics. In it, I tie my thoughts to anecdotes and personal experiences for detail and context. There is no link or anything yet, but feel free to ask questions and make suggestions.
- Sprint duration varies from studio to studio. For the purpose of this article, we will count a standard sprint as 2 weeks long. ↩︎
