leadership – Rasmus Rasmussen dot com

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 weeks¹. 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. ↩︎

If you know the expression “herding cats”, you already know half of what a Producer’s role is, and the challenges that come with the job.

Much like a conductor guiding an orchestra, the producer keeps each part of the development in sync and on task, when it comes to creating and launching video games. Instead of different orchestra sections, the producer conducts different teams, like designers, engineers, translators, etc. so that together, they produce an extraordinary experience for the end recipient, the gamer.

The Producer’s first priority is the Project, specifically its journey to completion. Even if a producer is dedicated to a single team, the project itself is still the foundation for setting priorities and making decisions. This might sound a bit harsh, but keep in mind that the project is nothing without its people, so it comes full circle, and a good producer knows that if the people are doing well, the project will benefit.

Producers are guardians of the Big Picture. The artists need to focus on their art, the developers need time to code, and so on. It is easy to lose sight of what everyone else is doing, when you are focused on your own work. That is where the Producer comes in as the Big Picture expert, to make sure no one falls victim to tunnel vision, Feature Creep, gets blocked by unsolved bugs, or prioritizes work that isn’t needed quite yet.

Producers are facilitators. You make sure deliveries and timelines align across teams, sprints and milestones, and you do this by assisting those doing the work. Here are 5 ways this might play out.

You help plan the work and prioritize items that will move other teams forward as well, before doing other things. Part of that is also following up and poking team members to do boring things, like write reports or updating their work items.
You sit in on a LOT of meetings, so you get a good idea of what is going on at a high level, and you can relate anything important back to the team. I like to say, sometimes the producer’s job is to have their time wasted, so the real talent doesn’t have to.
Running interference is related to the previous item. Some people like to go straight to the source, without checking whether the source has time. The producer can step in as a temporary gatekeeper. You take the questions or request, so that you remain in the loop, and if work was requested, you ensure it doesn’t get put ahead of the planned work (unless warranted, of course).
You take charge without being the boss. You run meetings with all sorts of people, and you can’t be too intimidated by asking senior leadership questions, or questioning the priorities of a team lead, if it doesn’t fit with the overall progress. Running meetings also means making sure all agenda items are covered in the available time, notes are taken, and follow up is done.
You’re a support class, to use gaming terminology. You make the others be all they can be by propping them up. Think like a healer, not like a tank. Strategy beats brute force when it comes to getting a game shipped. Especially if you’re like me, meaning strictly anti-crunch. Cheer your team on, and be ready step in with a quick heal or buff at any time.

What a (good) producer doesn’t do, is force everyone to follow their way, whether we are talking about prioritizing work, deciding how to track it, or anything else. You’re a facilitator, not a dictator.

For example, if everyone hates working in Jira don’t force people to use it. Find a tool that works with minimal frustration. People don’t have to love it, but you can do better than something they hate. For the record, I am a big fan of Jira. I only use it in this example, because it’s a tool many are familiar with.

That’s the high level look at what producers do. There are many approaches to the how things are done, but they all roughly try to achieve what I’ve outlined here. I will be writing more about producing games in the future, so leave me your questions in a comment or ping me on social media.

Tag: leadership

Game Development Should Not Be a Marathon of Sprints