Agile, a practical point of view

Agile, a practical point of view

Over the past five years I have worked on several AAA console titles, including our most recent game GRID Autosport, and I wanted to share some of my experience in the world of Project Management with you. This article is nothing more than a blog post - my intention is only to share my experience and point of view on a subject that has been debated multiple times ;)

I have read several books and articles about SCRUM, XP, and DSDM that detail the agile methodologies as a whole package. At the beginning of a project, I always wondered how on earth I am going to implement these methods. Development can require so many changes at so many levels that it can be discouraging at times. However, if you look at the details, you can breakdown Agile into two separate themes, and that helped me a lot to understand the philosophy behind being ‘Agile’.

The first aspect is about the people and how you organise your project – that’s I what I call Agile Project Management. The second is about how you develop your game layer after layer, which is Iterative Development.  Both of these aspects achieve different objectives, which I’ll detail below in this post.

Agile Project Management

Agile Project Management is all about how you run your project on a daily basis. Processes and information flow are tailored, so the team can react to changes and problems in a very rapid and conflict free manner. For me, Agile modern project management principles can be applied for any game project and I recommend that project managers should follow them. Here are the most important in my opinion:

Short Milestones

A famous quote in Agile, is ‘Fail often, fail early.’ In order to do that you need short milestones (or sprints). I determine milestone duration based on the quickest turnaround to properly support the milestone with a tangible outcome. On my projects, which are AAA multi-platform racing games with a large team onboard, a short milestone is around 4 weeks. As a production team, we need at least a week to prepare the milestone (user stories) and another week at the end to review deliverables (or user stories) and the overall scope in general. This leaves two weeks in the middle to fully dedicate on tracking the milestone and resolving issues. On leaner, smaller projects, I’m sure you can reduce a milestone to two weeks overall, but it’s critical there are a clean Start and End points so the team can identify progress and achievements.

Regular stand-up meetings

Regular and scheduled stand-up meetings are essential to confront any problems and deal with them rapidly. It’s far too easy to book meetings but, while you are waiting for the meeting, the problem still exists, blocking other team members. You are potentially losing time that you will never get back.

Self organising teams

A key strength of SCRUM and Agile is to empower the team – there is no doubt a self-organising team is more productive, more motivated, and, generally happier.  It’s important to highlight to the team that being self-organised is a two way street - you give them the freedom to make their own decisions without going through layers of approvals, but in return the team becomes accountable. As a project manager, you don’t force the scrum team to do [X] amount of work, you give them a menu and empower them to choose and estimate what needs to be done and how over the coming weeks. When they have decided, they are committed and as a project manager (or SCRUM master) you can set the expectation to deliver 100%.

Prioritised backlog

Schedules are difficult to understand and the source of many debates, but you can’t argue with a prioritised backlog. The prioritised backlog is a simple tool to communicate your scope and limitations. Each feature is estimated (high level or detailed estimation), you can only deliver what you’ve got capacity for, and then you can either have a discussion to reduce scope, increase capacity (time or resource) or finally spend more time to understand the estimation.

Identified roles

Everyone in the team needs to have an identified role that is known and recognised. Who is actually signing-off the features that were just delivered? Is it the designer that designed the feature and written the user stories? Or the creative director that owns the vision? Or the producer that is committed to ship the game? There is no right or wrong answer, but what you don’t want is these people giving separate opinion at different times and overruling each other. The product owner solves this conflict; someone is assigned to take responsibility of the feature requirement, work directly with the team and become the single interface.

These five Agile principles do not stop you planning your project or even creating a Waterfall schedule. On all the console games I have worked on, I always associated Agile with Waterfall in some capacity because, even though I have done everything I could to keep the development flexible with cross disciplined teams, prioritised backlog, etc, I will always have dependencies and external constraints that are planned in advance (Voice casting, Localisation, Content creation, Outsource teams...) that will prevent the development being approached from a purely agile way. The Waterfall schedule helps to predict the project timeline in the long term and analyse risks. That said, I don’t expect the schedule to be constant during development. The schedule will have to be updated every time you are evaluating the product backlog, but that’s fine. I refer you to Dwight D. Eisenhower’s well known citation:

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”

The planning exercise is what is important and Agile Project Management is all about constant planning.  And best of all is that the team even don’t notice it:

Iterative Development

Iterative development means the features literally grow through development. Starting with a simple expression of the feature and then sprint after sprint, complexity and diversity is added, but all stages of the feature are done within a single sprint. There is no doubt this type of development is very effective. At each milestone end, you should be able to play the feature and decide where to go next based on priority, but it comes with several hurdles that can make it tricky in AAA console development.

AAA Games are complex software developments

In order to iterate features you need to be able to change your codebase and quickly see the result. This can be sometimes challenging. A video game is a highly complex piece of software that deals with huge amounts of data, which takes time to process and the build is not always ‘green’. You can easily have couple of days delay before you review a ‘done’ feature in your build, which does not help when your sprint is only four weeks away. I strongly recommend that you define how a feature is going to be demonstrated in the user story as there is a huge difference between proving an experience with a code hack/placeholder art or actually implementing the real thing that may require content creation, pipeline or system change.

Do less, but better

When AAA console games have several hundred of features in the backlog which must all be completed for date [X], can you reasonably iterate your entire product backlog?  I prefer to pick my battles. Iterating features are amazing, but it’s no secret that it requires additional production support and being a Scrum Master is a tough job where you can easily become overstretched. The Scrum Master needs to coordinate multiple disciplines in parallel, resolve dependencies and problems as soon as they are raised during daily updates, ensure the boards and burn-downs are all up to date, and more... But not all features in the backlog are player driven. The tech or art directors are likely going to add tech features to improve tools and processes, which can be treated outside SCRUM approach.

You also need to question yourself. Why are you are iterating a feature in collaboration and what is going to be the benefit? Iterating a feature where the system already exists is ideal, but doing this for a completely brand new system needs some consideration before committing multi-discipline teams. As an example in my last project, we had an idea to add a new race game mode. From the beginning we started to iterate this new feature with multiple disciplines involved in the scrum (AI, Game, UI, design & Art) in order to produce a playable prototype quickly. On the first sprint we had a playable version that was really promising but the mechanics were not there yet. On the second sprint we realised the mechanic specified was not fun and when the third sprint did not improve the mode, we decided to stop because it was going to take too much effort to take it to the quality where we want it to be. This was clearly the right decision at the time. We stopped early without impacting the content production, but I always wondered if we could have obtained the same conclusion by analysing the feature more upfront by doing pretotyping, for example, we could have faked the mechanics through role play and an illustrated video explaining to measure the fun aspect.

Adaptive Design

Iterative development requires a different approach to design; from a personal experience it’s the most complex change to implement, which I still have a lot to learn from. As a designer, you don’t necessarily design the features you want, document it and finally present it to the team as a package. Instead the designer has to step away from writing the ‘design’ and become more of a service for the team. The designer becomes a hub of information during an iterative process that will answer questions and prepare the next set of user stories for the sprint coming. They have the delicate job to specify where the design is going next, based on what’s been delivered while adhering to the creative director’s vision. The documentation is also very tricky to balance. On one hand, the designer cannot document too much in advance as it is against the iterative approach and will ultimately be a waste if things change, so everything is focused toward user stories. But at the same time you need to keep some form of a design backbone that you can always look back to ensure the game vision is consistent.

The reason why iterative development is so beneficial for game development is because it makes you challenge your own development at every step of the way. It also reduces waste and the risk of failure by having working software at all time, where you can either review to add more features or lock because Alpha is tomorrow.

Iteration helps you to prove that your features are working correctly, without spending the full development cost. This is especially useful because having a ‘fun’ feature is nearly impossible to quantify; almost everything we do is subjective and most of the time we need to see it to realise whether what we’ve got in our hands is right or wrong.

The last words...

I believe it’s critical for project managers to have clean processes to run the projects on a day to day basis; you cannot bring confidence to your executives that you will deliver a AAA game involving 100 strong team in 18 months if the team keeps under delivering each milestone. Momentum is key. Changes during a game development are too frequent and more than likely unpredictable, so a project manager in the games industry needs to focus first on the short term before looking at the long term.

Agile project management is the foundation of agile development. You can either go for a pure form with iteration or, for some sections of the game, adopt a Waterfall approach. After all, the mixture of Agile and Waterfall is no more than being lean, which is ideal for content production and takes me back to a key pillar of Agile - “inspect and adapt”.

I hope you’ve enjoyed the read, if you have any comments feel free to post.

Vincent.

Reference: