Tag: gaming industry

Posted on

Game Development Should Not Be a Marathon of Sprints

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.

  1. Sprint duration varies from studio to studio. For the purpose of this article, we will count a standard sprint as 2 weeks long. ↩︎
Posted on

What does a Producer do in Video Games?

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.

  1. 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.
  2. 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.
  3. 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).
  4. 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.
  5. 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.

Posted on

Apprentice in the Gaming Industry

Sorry to be blunt, but traditional college degrees are rarely important in the gaming industry. Whether you’re a producer, an animator, engineer or community manager, there are plenty of jobs where a degree is optional. More important than the degree itself, will be any projects you can show off to a potential employer. Real world experience has high value, especially if you have shipped something.

Studying game development in a school setting is one step removed from actual game development and usually comes with a hefty price tag. For those reasons, I don’t think the diploma is a good investment.

I would argue that developing and launching games is a trade better suited for an apprenticeship model. Not just for the student, but in an industry infamous for crunch culture and burning people out within a few years, it’s a step towards a more holistic approach to doing business long term.

For students, the more hands-on experience you can get, the quicker and better you will learn. Not just technical skills, but also process related and interpersonal ones, like how to run meetings, working within budgets and deadlines, and taking ownership in a real-world scenario.

Being in production, you’ll always be ahead of any textbook, and the stakes will always be higher. So you learn fast.

In real-world environments, you’re faced with a blend of new and established tools, proprietary software and depending on the studio, a chance to work with cutting edge and unreleased tech. The bigger the studio, the more of this there usually is to learn.

In my first real industry job, I had to work around hardware that was still in development (the Xbox One and its Kinect attachment). This was tremendously challenging and equally exciting, in part because of the level of secrecy involved.

The 3-Year Model

So how do apprenticeships work? If you’re not familiar with the concept, think of it like a boosted version of an internship. One that involves real work, a salary and benefits (and zero student loans), stretches over a few years and leaves you with a well-rounded education – maybe a job. It traditionally culminates with a graduation project that really showcases your acquired mastery, also known as a masterpiece.

Let’s imagine an apprenticeship that runs over 3 years. You start out making slightly less than a typical junior position but still more than a paid intern. At first you won’t be contributing as much as learning, but in the final year you should be on par with, or slightly above a typical junior salary.

In the first year, you’ll focus on the basics. Sit in on meetings, work under guided supervision, mess around in the different tools, learn about budgets, timelines, testing and release. You will do mostly low level work at this point, but still actively contribute to the making of a game. After year one, you’ll have a good big picture overview of the industry, the studio, title and your role within that environment.

In year 2, you dive into the discipline you are looking to specialize in. You get ownership of smaller projects, where making mistakes won’t halt production. Making mistakes is expected and part of the learning process, but that doesn’t mean there won’t be expectations and real deadlines as well.

In the 3rd and final year, you pick one major feature to fully own alongside the work you are already doing – this is your masterpiece. The apprentice and their mentor set the final scope together, but it should highlight a “specialty” skill as well as other skills covered during the apprenticeship. What that is depends on what you do, of course. An animator will have a different goal than a producer.

At the end of the apprenticeship, the apprentice becomes a master and technically graduates out of their job. Ideally, the company has spent 3 years training a perfect new hire but even if they don’t convert the apprentice, that person walks away with 3 years of industry experience, no student loan debt, and hopefully at least one shipped title to their name.

Where do I start?

If you’re a newcomer hoping to get into the industry, the options are very limited. To my knowledge, there aren’t any studios or publishers offering apprenticeships. I have seen interns get hired into junior positions, but it is rare. If you know of anyone with an apprenticeship model, I would love to know about it.

If you run a studio or are a publisher in the gaming industry, I would strongly urge you to consider something like the model I have proposed. Do the math, and take the benefits to your company culture into account. It’s an investment for sure, but a worthwhile one in my opinion.

Adopting apprenticeships industry-wide would require a lot of leg work and for some, a shift in mentality. It would take time and people with greater expertise than myself to iron out the details. There are legalities and Human Resources to consider, and I am certainly not an expert in either of those. But I do believe that a well-structured variation of the apprenticeship model is better suited for the gaming industry than what we currently have.

Apprenticeships could also be developed with the support of unions, which are perfectly suited to help define win-win apprenticeship models. We need more unions across the industry, but that’s another topic for another day.

Would you take on an apprentice? Would you want to learn this way? For me, the answer is yes to both questions.