The plan will change! Embrace adaptability

Video games are iterative products because great gameplay demands continual adjustments. This flexibility must be reflected in the working practices.

No matter how experienced the team is, the plan will always change. This is the one thing to remember about managing a video game project. It is not realistic to expect to design the entire game upfront and then follow the specifications for the duration of the development.

The fun element of the product is difficult to quantify and predict. We will often want to replace gameplay mechanics with better ones. Or we will have new ideas to improve the player experience. Evolutions can also happen for diverse reasons: external constraints, poor estimates and slippage, risks materialising as problems, as well as other various unknowns.

Therefore, it is more important to plan light and track the differential, rather than schedule everything thoroughly and try to conform to details that will become obsolete. Measuring how much the development drifts from the initial goals, while integrating changes, allows recalibrating the project regularly regarding scope, time, budget and quality. That is, in its simplest form, the essence of iterative development.

There are many approaches to project management. How can production principles support a video game?

Linear development – There is no going back

The waterfall model is sequential and progress flows in one direction. It is one of the less flexible methodologies, but can still be useful for video games.

With this model, the product moves through a set of stages, such as requirements, analysis, design, implementation, testing and maintenance. It is impossible to go back to a previous phase without major impact on work that has already been done. Splitting into smaller modules, or scheduling time to allow changes, can add flexibility. But the approach remains very rigid.


A software development Waterfall model

Building a house is a linear process; you cannot erect the walls before the foundations have been finalised. But if you did not include the need for a basement in the requirements, it will be extremely difficult, if possible at all, to retrofit the change once the roof is in place. You might get away with some updates, like adding a floor, at an extra cost.

In video games, there are few situations where this model can be used. Small, pure, technical tasks: if you need to write a maths library for new hardware, this is a sequential development. Or repeatable processes: once the art pipelines have been identified, assets of a given type go through the same documented workflow.

Linear development cheat code: waterfall is not flexible and only works for repeatable processes and workflows

Iterative development – Progress through feedback

Iterative development does not give you what you asked for. It gives you something better, which has been improved with criticisms.

Innovative and creative activities cannot have specifications detailed up front. Lean is a philosophy to reduce waste. Agile is a paradigm that advocates continuous refinement. Lean software development, Scrum and Kanban are methodologies that implement these guidelines.

Philosophy, paradigm and methodologies

Lean SD identifies the minimum viable product to focus on functionality. It offers a framework in the context of great unknowns. It removes everything not contributing to customer value to deliver as fast as possible. It deals best with uncertainty, such as research and development.

Scrum time-boxes iterations to focus on trackability. It breaks down work into manageable chunks: small features for small teams over short durations. It creates a structure to measure progress and calibrate the product. It is most efficient when the goals are clear, but details fluctuate.

Kanban limits tasks in parallel to focus on team capacity. It rationalises pipelines to minimise overload. It supports on-going improvements, while deliveries happen when sufficient progress has been validated. It is best-suited when demand needs to be balanced against available resources.

There are overlaps. It is possible to mix methodologies into project-specific solutions. For example, Scrumban is a hybrid that borrows practices from both approaches.

Iterative development cheat code: Lean SD, Scrum and Kanban improve product value with feedback and adaptability

Mix & match – Build your own

All methodologies have limitations. Best results are achieved by combining techniques and practices from different approaches.

Principles have domains of validity. Ideally, Scrum developers should have uniform skill sets to be able to work on any task. This is not always feasible when applied to video games. Also, processes change as the project evolves. Pre-production reduces risks; Lean SD is good for uncertainty. Production adds content and features; Scrum is good for timescales. Post-release provides support; Kanban is good for continuity.


Possible evolution of methodologies over project phases

Consider a game in production with elements of shooting and driving. It is natural to structure the teams around these. Each group requires artists, programmers and designers; skills are not transferable. Can you apply Scrum? Splitting people per discipline would lose coordination of features…

The two gameplays will need audio feedback. There is only work for one composer. How do you share across teams? Moving individuals between iterations would invalidate the tracking of progress through team velocity…

There is no perfect solution. A pragmatic approach, here, is to have cross-discipline groups using Scrum-like principles, and ad hoc processes for elements that do not fit. The producer must organise what can be, to spend time efficiently on what cannot.

Mix and match cheat code: methodologies have limitations. Know how to choose and borrow principles to design yours

Abstract quantification – The importance of uniformity

Production keeps the project under control. The methodology must be able to account for adaptability when reviewing deadlines.

Waterfall is easy. Break down specifications, estimate tasks, add dependencies, and voilà! The schedule shows the critical path and end date. But video games are iterative. How does that work with Agile principles?
We use past measurements to predict future progress. To build the data, we need a metric. Story points, business value or feature scores: terminology is irrelevant. It is important to understand the concept.

The quantification abstracts a feature into a single number. It represents the perceived complexity. The scale is project-specific, with lower and higher bounds. The values are relative: features score comparatively to other features.
Using these values, we can track ‘how much’ gets done over periods of time. This information gives a predictive model to extrapolate completion dates.


A burndown chart tracking feature points over time to predict completion

The next bit is usually greatly misunderstood. Pay attention. This only works if the valuation is uniform across the entire project! Why? If the error is not homogeneous, historical data is not representative of future features. Thus, making the predictions unreliable.
The quantification process must be quick so that it can realistically be applied to the whole game.

Quantification cheat code: valuation must be uniform across entire project to build a reliable predictive model

Producer cheat sheet

All tips in one sheet to add to your collection!

What’s next ?

We have talked about methodologies and principles, but have not yet looked at the actual details to implement these guidelines. In the next posts, we will discuss what makes a good management framework for video game development: processes, production artefacts, project assets, and assessment checklists.

The plan will change! Embrace adaptability
Share this content
Share on LinkedIn
Linkedin
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter

You May Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *