Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
September 19, 2014
arrowPress Releases
September 19, 2014
PR Newswire
View All





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


 
Agile Game Development is Hard
by Rob Galanakis on 02/19/14 05:45:00 pm   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.

 

I've spent the last few weeks trying to write a blog post about why Agile software development is inherently more difficult for games than other software. I searched for some fundamental reason, such as games being works of art, or being entertainment, or being more difficult to test, or anything about their very nature that makes game development different from other types of software development.

I couldn't find one. Instead, I came up with reasons that are purely circumstantial, rooted in business models and development environments. Nonetheless, it is the situation we are in; the good news is, we can change it.

4+ Reasons Agile Game Dev is Tricky

Number one: the insane business model based on packaged games. Develop a game for years, market the hell out of it, ship it, profit, repeat. Crunching hard is probably in there, as is going bankrupt. Each year fewer and fewer games garner a larger share of the sales, and budgets are often reaching into the hundreds of millions of dollars to continue this model. This is pure insanity, so development methodologies of greater sanity, like those based on Agile principles, simply cannot thrive. Often they struggle to even take hold. Don't underestimate the depth of this problem. We have a generation of executives and marketers (and developers) who know only this model, and trying to explain to them how you need to be flexible and iterative with releases and develop with tests can feel like a losing battle.

Number two: We've equated Scrum with Agile. Agile embodies a set of principles, but we've equated those principles with a (limited) set of tools: the Scrum project management methodology (you can substitute Lean and Six Sigma in the previous example; this phenomenon is not unique to games). If you're ever tried to impose Scrum on an art team, you can see how much of a disaster it is. Rather than take Agile or Lean principles and ask "what is a good way to work that values these principles?", we just institute some form of Scrum. I've seen many people dismiss Agile because Scrum failed, which is a shame. And like Scrum, I've also seen forms of soulless Kanban implemented (soulless because it doesn't support the principles of Kanban, like limiting work and progress, managing flow, and understanding constraints).

Number three: Game development was late to the Agile party. Software has had about 15 years to figure out how to apply Agile to business and consumer applications and websites. While "flaccid Scrum" now seems common in games, that's relatively recent; combined with multi-year development cycles in these so-called "Agile" shops, there hasn't been much of the learning and reflection that underpins Agile. On top of this, Agile is in a period of maturity right now and is being appropriated by project management, so it is difficult to innovate in the methodology space to come up with an alternative to something like eXtreme Programming that works in game development.

Number four is pretty interesting: Game sequels are not iterations. It is very common to build up mountains of debt to ship a game, and then throw away and rewrite those mountains for the sequel. This worked okay because sequels were usually much more disruptive than innovative so there were more opportunities for rewrites. In contrast, consider that the MS Office UI stayed basically the same from 1993 to 2006. Now as games are entering a loosely defined "software as a service" model, our development priorities must change. We need to be able to iterate month-by-month on the same codebase and pull things forward. This is a new set of skills we need to develop.

There are a number of smaller items that are less important but still should be pointed out:

  • Game development hasn't embraced open source and is on Windows. Many developers and executives I've met have a distrust of OSS (CCP's use and support of Python and other OSS is a source of pride for me and others here) and the majority of game development is on Windows. The Agile movement has strong roots in OSS and Linux, so aside from the cultural differences between the two communities (which should not be underestimated), there was just a lack of engagement between game developers on Windows and Agile evangelists on Linux.
  • Game development reinvent wheels. The availability of lots of excellent open source middleware has given non-game developers a leg up on focusing on their core product. If you had to develop your product and webserver, you'd incur not just the cost of developing both but of splitting focus. Game development has historically done a poor job of using middleware and has often reinvented the wheel; this has probably historically been due to the desire for maximum performance and ridiculous deadlines and business models. With more hardware to spare, I suspect this will change and we'll see things like HTTP used between client/server instead of custom RPC stacks.

Reasons Agile Game Dev is not Tricky

Finally, there are a number of arguments I have thought over and rejected, including:

  • Games are art and art cannot be iterated on like other software.
  • Games require too much 'infrastructure' to make anything playable.
  • Games want users to spend time, not save time.
  • Games are impossible, or at least significantly more difficult, to test.
  • Fat clients are difficult to distribute.
  • Frequent releases are confusing for games, which are traditionally content-heavy.

Call to Action

There are solutions to all of these problems, but it requires getting to the core of Agile's principles, and even more importantly, the Lean principles those are based on. What game development needs is a new set of practices and tools, better suited to our technological problems, that fulfill the same principles and can be mixed and matched with existing Agile practices and methodologies. Some ideas or topics for discussion in future posts.


If you like this post, head over to my blog at robg3d.com. I only cross-post articles occassionally.


Related Jobs

Trion Worlds
Trion Worlds — Redwood City, California, United States
[09.18.14]

Senior Gameplay Engineer
Heavy Iron Studios, Inc.
Heavy Iron Studios, Inc. — Los Angeles, California, United States
[09.18.14]

Game Programming Intern
Wargaming.net
Wargaming.net — Hunt Valley, Maryland, United States
[09.18.14]

Sr. Gameplay Engineer
Wargaming.net
Wargaming.net — Chicago, Illinois, United States
[09.18.14]

Sr. Gameplay Engineer






Comments


Katy Smith
profile image
Nice article :)
I think another thing that contributes to the difficulty is that publishers still want firm dates, and dev teams don't want hard commits to tasks / features. This makes for "soggy scrums" which are pretty gross!

JJerry Smith
profile image
Any recommendations for Agile project management software?

Tanner Brackett
profile image
For the project I am working on, my team uses a mix of kanban and scrum for the programming side and pure scrum for the art side. It works out pretty well as the programming side has different needs than scrum provides.

Michael Wenk
profile image
I think that using agile/scrum in game development is no harder than any other shop using it. So in that sense I call BS on the article. However, I do think that going from waterfall (or any other development methodology) to agile/scrum is very hard. It does not matter whether you're developing a web app, a game, a business app, or system software, it is all hard. The problems are many and varied, and the end result is rarely something "purely" scrum, and frequently doesn't produce improved product, which if you remember is the whole reason *for* agile.

And while I personally prefer agile/scrum to waterfall, I don't think a shop should ever convert to it. IF you're setting up a new company with new people who aren't married to their ideologies, then I think it would work, if not, I think you're just asking for trouble.

Matthew Mouras
profile image
I worked for a large IT company that dove head first into Agile methodologies after being firmly invested in waterfall for many years. Nodded my head while reading all of this comment.

Rob Galanakis
profile image
I'm not sure what there is to call "BS" on. As I said:

"I've spent the last few weeks trying to write a blog post about why Agile software development is inherently more difficult for games than other software... I couldn't find one. Instead, I came up with reasons that are purely circumstantial, rooted in business models and development environments."

You're totally right- Agile is not inherently more difficult for games than it is for software. That said, we have remarkably few "case studies" of Agile done right (I should know, we held ourselves up as a posterchild of Agile conversions but the truth is we were doing it absolutely awfully). The reasons in the article are more-or-less unique to game development. They are new- not inherently more difficult- problems we need to solve in a public way.

Regarding the Agile conversions, I totally disagree. If you are stuck with people married to ideologies of whatever type, your company will not evolve, and it will die. That marriage is something that is difficult to break, but it needs to be broken.

Paul Furio
profile image
Agile is Religion, by which I mean that there is no one way to do it right (and, potentially, some people will find it pointless). Teams have to figure out what methodology works for them.

As the Technical Lead for a bunch of game groups, I found that the key things were 1) find a system that people understand and can implement on a daily basis, and 2) get buy-in on the iterative process where the team marches forward, looks at the results on a regular basis, and then reevaluates direction. Maybe that's Scrum, maybe it's Kanban, maybe it's something else.

My personal favorite, and one that my teams enjoyed, was what others derisively called "Scrumerfall". We would run 3-week sprints, with the following criteria: Monday morning was evaluation, rough planning, and discussion of what we BELIEVED we wanted to work on. We'd pick some tasks, and then spend the rest of Monday and all of Tuesday meeting with each other, making quick prototypes, and doing research. Wednesday morning, we'd meet again, armed with our data from the past two days, and do a real planning session, committing to our work. Then we'd crank out stuff for two weeks. On the third Wednesday, we'd stop at Noon, and then test, stabilize, fix bugs, etc. If we met our goals by Friday at Noon, great, team party, go home early, brainstorm, whatever you want to do guys. If not, we'd be back on Saturday to keep debugging.

The advantage of our system is that we avoided Big Bang Integration and Tech Debt problems at the end. We also had much more accurate planning with our up-front prototype & research phase. Those forced meetings and prototype sessions meant that we didn't just dive into code without understanding the cross-group implications. The disadvantages were that it wasn't "Real Scrum", but it was a system that worked for us.

The iterative approach is critical. We have to understand if we're building something fun and compelling as soon as possible. Three weeks is a good pace to really flesh out some functionality, get some good art in, and take a step back to ask "is this moving us in the right direction?"

jeff grant
profile image
In my 20+ years leading dev teams in corporate (banking, Fortune 50) environments, online games, and two of my own startups, I fully agree.

I've never been in a development situation where one specific methodology fit 100%. I've always found that you had to evaluate the project and its unique business, management, reporting, and deliverable constraints, and then mix and match to come up with something that works for your specific team.

I'm quite surprised at the number of tech leads I've worked with that are afraid of this "mix and match" concept, and prefer to subscribe to the strict teachings and rules of their methodology du jour, even if it's to the detriment of the project.

In the same way you pick the right tool for the job, pick the right development methodology... and sometimes that methodology is a mutt.

Amir Barak
profile image
Heh, I once had someone tell me "we're so agile we don't need to timebox our sprints" :P

Kenneth Barber
profile image
Frankly from my experience agile anything is hard if you spend more time managing and nurturing the process than developing software. I have used scrum with success on projects that involved the implementation of lots of small disparate backlog items (bugs) on a mature codebase but have had trouble applying the same process to new development that required the creation of new systems and algorithms. You have to be strong enough as a team to modify the process to when necessary.

Mark Warren
profile image
Great blog, Rob. As you're at CCP I hope Perforce is helping! If you haven't seen it, there was a good article on the Develop site about how Supermassive Games adopted agile principlesm(http://www.develop-online.net/analysis/the-four-pillars-of-agile-
game-development/0117636). I think this is part of what you're saying. It's important to remember the principles, not to get bogged down in check-boxes.

Judy Tyrer
profile image
I agree that ONE of the problems is an almost religious belief in SCRUM as the magic blue pill that will solve all problems. Anyone who knows me has heard me rant about it. Development process should be flexible and the right process applied to each project based on the needs of the project. Sadly, that doesn't seem to happen.

A team of 200 needs a completely different process than a team of 12 or a team of 2. Heck, with 2 people you hardly need process at all. The purpose of process is coordination and communication. If the process you are using for developing your game neither helps with coordination nor with communication, chances are you are adding overhead and accomplishing nothing.

On third party developer I'm partnered with doesn't use schedules at all. "We add features and fix bugs until we feel we have enough to warrant a release and then we schedule the release, but not before." I kind of like it.

King Lee
profile image
Nice article!
I've started using Agile for several game projects since 2006 and got the same experience as you mentioned.
I agree that agile is hard. But there is no easy solution which can be perfectly fit for game development.
I think the best way is to practice and try to make your project being 'Agile'. You can't make every sprint can be finished on time or even the game can be shipped without delay. But you can improve the development plan and process based on each iteration. That's very helpful for your product and team.
I've also seen some teams just followed a fixed agile method like what the book says. It's totally wrong. Because every game or dev team is different. If a team wants to use agile methodology such like scrum, the first thing is to evaluate the current requirement and customize a better process. Then improve the process when you find any problems or new requirement. Build, Analyze and Improve... It's not only for your product but also for your team and development process.
I still suggest every game team should try agile or some of its methods. It's hard, but helpful.


none
 
Comment: