Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 29, 2014
arrowPress Releases
July 29, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Agile, a practical point of view
by vincent meulle on 07/02/14 10:05:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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:

  • Shorter Milestones to increase frequency of planning reviews
  • Regular stands-up to talk about dependencies and blockers
  • Self organised teams which plan themselves
  • Prioritised backlog that is essentially a 1-Dimension schedule

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:

 


Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[07.29.14]

Cinematic Animator (temporary) - Treyarch
Activision Publishing
Activision Publishing — Seattle, Washington, United States
[07.29.14]

Senior Software Engineer - Services - Activision Seattle
Camy Electronics & Plastics
Camy Electronics & Plastics — Los Angeles, California, United States
[07.28.14]

Sales and Marketing Assistant
Red 5 Studios
Red 5 Studios — Laguna Hills, California, United States
[07.28.14]

Localization Project Manager






Comments


Andrea Di Stefano
profile image
Thanks for the article. Very thruthful vision of how day to day development comes down to a huge balancing act :)

On to my question:
It seems to me that the time needed for planning and review is maybe one of the points that are less touched upon when talking about Agile applied to games.

In the past I struggled to establish a consistent process that would allow me and other stakeholders to evaluate and plan the next steps while at the same time keeping the team focused and not waiting for other people to define the next sprint (even one week of goal-less downtime can be frustrating).
I countered this by having a few days of debugging after each sprint delivery to maintain the stability of the game to a decent state but it soon became a "boring" process (to the team at least).

How do you go about paralleling development/reviewing/planning and avoiding downtime?

vincent meulle
profile image
Thanks!

Euh, personally I never suffered of downtime. There is always too much to do :), If the scrum team finishes a user story earlier, they will be more than pleased to have couple of days to polish it or maybe help another team.

In our last project, we used to have an Hardening week (unplanned) at the end sprint to ensure the sprint ends and start with no overlap which is something that worked really well.

Clinton Keith
profile image
Andrea,

There are a couple of practices that teams have used to avoid this:
- have about two sprints worth of small stories at the top of the backlog for teams to draw from in case they get more done or have to skip if someone is absent (sick, etc).
- separate sprint planning into two parts. The first part can happen 2-3 days before the end of a sprint and establishes a potential sprint goal for the team to bring into sprint planning part 2 on day 1 of the sprint.

Doing this I can reduce sprint planning for the team to about 1-2 hours per week of sprint.

Clint

Andrea Di Stefano
profile image
I especially like the split sprint planning, I did it in a non formal way and it worked fine yet I never considered making it a standard process.
Thank you for the advice!

Charles Palmer
profile image
I think this is a nice summary of how some components of various Agile processes can be used in day-to-day development. Though I think it's missing or misleading about some key pieces that really make Agile, agile.

The first is that Agile is not just about iterating and improving the product you're making based on a virtuous cycle of rapid iteration and lots of feedback. It's also about improving your work processes in the same manner and one of the principles of the Agile Manifesto states this explicitly. All the things you mention are tools to solve problems but its the choice of the right tool and perhaps switching to better tools for the context that lead to better development quality and velocities. For example feature development might work best with a cross-functional team working with Scrum but production art might work better as a support silo using Kanban. It takes iteration and experimentation to work out the correct setup for any context. I think you sort of touch on this but to me it's more important than any particular tool you choose to use. It's the engine of the process.

The second was this phrase:
"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."

Tools and pipelines still have customers even when they are internal. You still want to deliver value to them as quickly as possible. In many ways it's much easier to run these teams as Agile or Scrum teams as you can get much more direct feedback from a customer that is sat just down the hall. Whereas game features tend not to get as much direct interaction with the end-user unless your are working on a live service.

Clinton Keith
profile image
Good, pragmatic article.

Vincent Meulle
profile image
Cheers, thanks!

Matthew Horsman
profile image
Nice work Vinny!

Now I know what producers do all day! :)

Thomas-Bo Huusmann
profile image
Thanks for the insight. Some really good notes on project management.
At the same time I have to agree with Charles Palmer, that the article could have had more on exploring for finding the right setup for a given production. though I think you have the same concept behind the written as he mentions.

"I always wondered if we could have obtained the same conclusion by analyzing 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."

Even though we at Huusmann Media only make casual / mid-core mobile games. I can only agree to the illustrated film concept/pretotyping.
As a former producer/story-artist in animation, it is natural to Pretotype, like acting in front of the camera or sketching out beats or emotions, on paper to see what works.
So in games we always aim to make fast animated films, to show how a feature would work/feel (using Flash). This way we can potential save weeks of work on ideas, that would have been wasted time.

Lastly.
As a young studio in games, our personal experiences are that in-experience in leadership in game development, most failures happen in the tactics implemented, and that this makes life sometimes impossible for managers.
Like when the creative director and game designer say the same at a meeting, seemingly agreeing. But soon it turns out they have two completely different meanings behind the words.

This aspect might not fall into the use of SCRUM on AAA titles. But I am curious if you might have some great insights to share?

vincent meulle
profile image
Thanks Thomas.

Oh Yes! I know what you are talking about and it's not just in Design, the same can happen in other disciplines. For me to mitigate this situation, you need to ensure the Vision of the game is communicated as wide as possible: Wiki, Presentations, Videos, posters on the wall...put this everywhere so everbody is on the same page.

Regarding your specific example, a big thing about SCRUM is delegation. The Product Owner can only be 1 person per user story. HE/SHE writes the user story and owns it, the product owner will be THE interface in the scrum team. He/she will liaise with the stakeholders to manage expectations and protect the scrum team. This way, there is less risk of confusion between feature 'a' from the designer and feature 'A' from the CD.

I also do agree with Charles, this article is a view of Agile from my personal experience from a specific game type, project constraints and environment....as always inspect and adapt! :)


none
 
Comment: