Projects need structure for them to work. Different parts of the project may require different processes and workflows due to the way different disciplines work. Usually producers are not the top hiring priority of various game projects, but they should be. For each discipline, art, programming, level design, game design, UX design, UI design, character art… All of them require different kinds of production support. In general there are a lot of moving parts, and all of them have to work together in order to spit out a game at the end of development.

Scrum and Kanban, both agile development methods, are used to create a framework for the process of making the game. Some companies use other agile software development methods like lean and similar. The intent with the methods is to create a flexible way of developing that allows for iteration. Most methods, in a very simplified description, aim to clarify:

  1. The amount of work to be done
  2. How long the work will take to complete
  3. How many people are needed to complete the work and what their skills are
  4. Internal priorities and dependencies – some work is impossible to complete before other work has been done

Before looking at those aspects though, you need to know what you’re making. Games may change as development progresses, in fact I have never been in more than one project that knew what it wanted to accomplish from the outset, but even then, iteration happened.

Regardless, it is leadership’s responsibility to communicate a clear vision, a clear goal, and a clear intent to the game team. Without those, you may as well burn the money1.

This does not mean that iteration is forbidden or bad or wrong, but – and this is the important part – if you have a process in place, such as a change request process, you are usually fine. But the process needs to be established – everyone should know how to file a change request, and it has to be followed.

We have issues with both. Following process and being aware of processes.

Let us be optimistic. You have a clear goal, intent and vision for the project. That vision is reiterated by leadership on a regular basis. Asking anyone in the team, they can describe the goals of the project from their viewpoint and their discipline’s perspective. No, none of this is easy. Yes, it requires a lot of work. This is why leadership gets paid the big bucks.

The thing that seems to be the most problematic in setting up and completing a project is deciding on a vision, intent and a goal. But even harder, sticking to the vision, intent and goals.

Having processes in place, like change management, makes it more difficult to pivot a game without clarifying what the consequences of the pivot would be.

Returning for a moment to the process used – in my experience as long as there’s a consistent way of measuring the amount of work to be done, how long it will take2, and who’s going to do it. Priority and dependencies are also good to know, since those two affect the rest of the schedule.

The issue is usually that people find process boring and a waste of time. Because of that, they choose to not follow it. Again, this is the responsibility of the project management to make sure that the process is clear to everyone on the project. This is not easy either. Yes, it requires work and more than anything it requires trust.

In a project where features are constantly changing, project management are the ones making sure those changes do not have a negative impact on the team. In my experience this is where it usually falls apart. Shortcuts are made, project plans are manipulated to hide work, developers are burned out. I once had a producer promise that I would do what amounted to three weeks of work in four days, without consulting me, in a leadership meeting with directors and representatives from the publisher. I worked 16 – 18 hour days plus the weekend to deliver on his promise. What did I get? Not even a thank you or a sorry from the producer, despite telling him how it impacted me.

As a producer and project manager, it is your job to protect the team and your job to implement a working process. Shortcuts are tempting but in the end they hurt more than they help.

So what can you do? Make sure that there is a process. Follow it and update it in an orderly fashion as you work. No process is one size fits all, but don’t abandon the process if it doesn’t work.

Another nightmare scenario I’ve experienced was a producer that – without real input from the team – decided to implement Kanban. The implementation consisted of changing the entire backlog to Kanban cards – something he did not do himself – a written document about how Kanban was supposed to work and then nothing.

The team was expected to handle it on their own. No experience of Kanban in the team and no help from our producer.

Reader, it didn’t work.

A few months later we returned to using Scrum, shortened the sprints and increased our productivity because we followed a process that we knew. I helped make that happen, because our producer gave us no other choice.

As a producer your most important task is to build trust. Don’t lie to your team, don’t take on work for your team without anchoring it in your team and don’t lie to leadership. Keep your promises. If the team is overworked, put a stop to it.

When I was a producer, I followed up on everything. If a developer wouldn’t fill out their burn down, I spoke to them. If they were stressed, I did it for them. There was a lot of work going into the administrative side of our process. It wasn’t work that would get recognition, in fact it rarely did. Was it worth it? A colleague told me I was the second best producer they’d ever worked with, and they had a lot of experience. Based on that? Yes, it was worth it.

If you only take a few things with you when closing this blog, take these:

  1. Don’t skip or ignore process. The smaller the team the lighter it can be, but it should be there, if nothing else than to provide data.
  2. Hold directors accountable for vision, goal and intent.
  3. Don’t gloss over how impactful even small changes can be.
  4. Hold yourself accountable for change requests, communication to the team and teaching the process to the team.
  5. Hold developers responsible for accurate data but adapt the process to help them, not hinder them.

I’ve got more to say. More to come.

  1. In game development today, triple-A, most of the problems I experience come from one or two sources. Toxic teams or unclear goals and visions. Usually both. Toxic teams are usually due to the inability to create trust between team members for various reasons. Dysfunctional teams are all based on a lack of trust, and a lack of trust is usually built on being fearful of giving honest feedback and asking questions of leadership that leadership doesn’t want to answer. This usually goes hand in hand with a game project that lacks clarity and direction. As soon as the Latest Thing™ has dropped usually leadership is unwilling or unable to see the impact the changes have on the game team, and the producers – due to a dysfunctional working environment where there is no trust – gloss over the issues because it’s easier to gloss over things than to bear bad news. Game development is hard, sometimes because we make it hard.
  2. This is however somewhat iffy. It may seem counterintuitive but the best way to measure how long something takes is not by assigning days, unless it’s a time boxed task. Complexity is better, because it’s abstract and people won’t get stuck on the “days” and “hours” part. Complex tasks are still complex by the end of the project, but at that point the developer has learned how to navigate complex tasks and can usually complete them faster.