Scrum and Agile in a game dev studio – does it make sense? How do we work project-wise at Brave Lamb Studio

During my 10 years of work in the game dev sector, I have noticed a desire among producers and department leads to seek ever-improving methods of managing and supporting development projects. It is also trendy to try to transfer methodologies known from ‘hard’ IT “as it stands” directly to game development projects. In today’s article, I will talk about the possible applicability of Scrum and Agile in game dev and how we manage projects at Brave Lamb Studio and how to approach agile methodologies in game development projects.

Purpose of introducing agile project management methodology in game dev

When I talk to new start-ups in game production, I often encounter expressions:

• we need a project management methodology to control the development team;
• we need to know if they will deliver the game;
• we need to rush them to make the game faster;
• we don’t trust the team because we don’t know them – we need to understand how they work.

Why do the statements above occur especially to novice development teams? More often than not, it is for several recurring reasons:

• at the time of starting work on the game, the scope of the project is not known, only its general outline;
• the real needs of the project vis-à-vis the capabilities of the team at one’s disposal are not known. A common phenomenon is “blind tank” behavior, where a strong push towards the realization of the scope without looking at the real capabilities of the team is evident;
• producers do not understand the complexity of individual tasks and make decisions on priorities intuitively (after all, the physics of a car may be a package from the asset store), rather than based on the scope of the game and the team’s feedback;
• the team is built opportunistically. No one has worked with each other before, and even the leaders of each technology area (yes, today 3D graphics is also technology!) do not have the experience to empirically understand the scope of the project.

As you can see from the examples above, often the search for a project management methodology is based on the wrong or even adverse motives described above. In what way then, can we implement agile methodology of project management into game-dev, at the same time making it serve the right purposes?

Firstly, we should remember that the most important goal of Scrum or Kanban methodology is to improve the team’s comfort level. The team here is not defined as a group of developers put in opposition to producer(s). The producer is a part of the Scrum team, and his to participate in the ongoing work of the team. The comfort of his work is therefore put on a par with that of the development team.

Secondly, let’s not forget it’s the methodology that serves the project, not the other way around. If, in the course of work, we come to the conclusion that any component of the methodology does not work properly, we should adapt it to our own needs or think about adjusting it. Of course, it is necessary to distinguish convenience of work and laziness, because the risk of missing the point of project management may be very high. Not writing tasks in the game backlog is laziness, but changing the configuration of areas that form the task under the will of the team is a convenience.

Lastly, let’s make an agreement with the team to follow certain rules. During a certain milestones it might be a necessity to work overtime, intense feelings about the process of creation and ownership of what we create, and willingness to fling ourselves into work when critical moments approach. I believe that by being able to predict arrival of such moments, we can enable the team to develop a methodology to deal with them. At our studio in high-stress situation – such as the recent completion of vertical slice, we manage such situations by:

• determining what we need to do (definition of done)
• determining how it should be done (definition of ready)
• adjusting tasks to the reality – grooming to make sprints more realistic
• introducing the right, refined tasks with realistic time estimates

The aforementioned methodologies keep the situation in order, in case of crunch or increased workflow rather than typical crunching over iteration of things without clearly defined acceptance criteria. At the same time, we need to remember that Scrum and Agile in game-dev or other methodologies are the only a way to achieve a certain goal, not an end in itself.

How do we manage projects at Brave Lamb Studio?

Each day at Brave Lamb Studio is marked by so-called stand-ups. Every day at 9:30 a.m. we hold teleconferences with all team members, who update the others on the status of the work according to the scheme:

• What did I do yesterday?
• What will I do today?
• Do I need to talk to someone or do I have any problems?

This activity keeps me, as a producer, informed about the current situation in the project and enables to quickly identify potential big risks that we should discuss or reprocess. This way, we are all in control of the project and are able to respond appropriately to any changes each day.

In addition, each team of programmers, designers and artists – usually holds a grooming meeting once a week, during which new tasks are created for the next project units (called sprints). During this meeting, the project’s framework roadmap and current goals are analyzed, from which tasks are then created for the backlog of subsequent sprints. We adopt the general principle of developing each element of the game according to the scheme:

• design of functionality,
• feedback to design,
• implementation of prototype,
• feedback to prototype,
• target implementation.

Such structure is reflected in tasks positioned in the backlog, which falls into specific sprints, i.e. periods that end with a meeting called sprint review. At Brave Lamb we work on War Hospital during two-week sprints, and we invite all members of the development team and external stakeholders (e.g. investors, board members or publisher representatives) to the sprint review. During the meeting, we present the progress of the work according to the order of the tasks that were completed during the sprint.

When the presentation is over, the team is already internally conducting the planning process. Together, we put in a new sprint board the tasks that will be implemented in the coming weeks, along with checking their completeness (references, materials or specific acceptance criteria). We also do the evaluations.

At Brave Lamb Studio, we are in the process of transforming our pricing system. So far, tasks are priced in man-days, with the smallest unit of account being 0.5 working days. We try not to schedule tasks that exceed 5 business days due to the high risk of not completing them on time. I try to work with the team to break down such a task into smaller ones to get more accurate unit pricing.

An example of a sprint burn chart. The red line reflects the planned scope of work, the green line is how the team completes tasks. Here the visible mistake rate (pricing error rate) is about 16% so in the upper limits of the norm, given the time in which the team works with each other. Closing requests at the end of a project is a signal to the producer regarding, either less attention to closing tasks in the Jira system, or that large tasks are being finished at the last minute – this requires deeper analysis

In the coming months, we will gradually move to abstract valuations (so-called story points), which will allow us to assess not only the time-consumption, but also the complexity of the task, thus increasing the accuracy of our estimations.

Is it worth it to run projects using agile methodologies?

Given my own experience of working in static and agile project planning, I much prefer working in agile methodologies. Scrum and Agile in game dev allows that, thanks to this approach, the role of the producer ceases to be “commanding”, and becomes supportive of the team and “preemptive” against any of its difficulties. Responsibility for the results becomes team-based, and the game roadmap becomes more realistic, as it is based on the team’s estimates, rather than the mark-up of the producer, who most often does not have full knowledge of design nuances or technical difficulties. This makes the project much more transparent.