Gamasutra: The Art & Business of Making Gamesspacer
Top 10 Pitfalls Using Scrum Methodology for Video Game Development
arrowPress Releases
September 1, 2014
PR Newswire
View All





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


 
Top 10 Pitfalls Using Scrum Methodology for Video Game Development

July 15, 2008 Article Start Page 1 of 5 Next
 

[Industry veteran Miller looks at the leading Agile methodology for game development, suggesting the ten top pitfalls - and ways to overcome them - for those using Scrum to manage a video game project.]

There has been some hype about using Scrum for game development, including presentations at Game Developers Conference. There are books and many internet resources that describe Scrum, and this article assumes the reader is familiar with Scrum and Agile methodologies for product development.

Scrum can be a beneficial for some kinds of software projects. There are, however some pitfalls that are easy to run into when employing Scrum to manage a video game project.

Some hazards can occur because the importance of well-established, existing best practices is ignored. There can be consequences when Scrum is used as a replacement for existing best practices. Here are 10 pitfalls that were experienced on a recent project while employing Scrum methodology.

10. A Game Design Document (GDD) isn't needed anymore because the backlog spreadsheet replaces it.

While maintaining both a GDD and a backlog, the team is drowning in an overwhelming amount of paperwork every day. The ScrumMaster or Producer responsible for the backlog ends up spending less time writing or maintaining the GDD and as a result there is a lack of product design specification. Team members are left guessing what code to write or what components or assets need to be constructed in order to make the game that is going to ship.

Lesson Learned: Backlog spreadsheets are not a replacement for printer-friendly game design documentation. Team collaboration is not a substitute for someone putting the product design specification in writing.

It's hard to see up front that the lack of printer friendliness of the backlog spreadsheet is actually going to inhibit everyone's ability to communicate. Before backlog spreadsheets, it was possible to print out the GDD and bring it to the team meeting and scribble notes on it. It was also easier to provide feedback in writing. By printing out the GDD and bringing it to the meeting, you could talk about the design and refer to it without sitting at a computer.

While using a backlog spreadsheet as a replacement for design documentation, one issue team members realized is that after a meeting they walk back to their desks, start to concentrate on tasks and have forgotten seven of the eight points that were discussed during the meeting. The solution proposed was that everyone needs a laptop to bring to the team meeting so team members can type into the spreadsheet simultaneously. Imagine the team meeting is like a LAN party and everyone can see each others' cursors on their own view of the spreadsheet.

Unfortunately spreadsheets do not have a multiplayer mode, and the company is not going to buy everyone a laptop just for Scrum methodology. The obvious solution is everyone brings a notepad and pen to the meeting and takes their own notes, but why didn't the designer put the design in writing in the first place? Why is the design done on the fly and everyone has to take notes like an executive dictating a letter to multiple secretaries at a time?

In multiple team project review meetings the ScrumMaster has remarked "We need more communication on our team." All the developers then roll their eyes and ask "where is the design specification in writing? Wasn't the printer-friendly GDD a form of communication?"

Best Practice: Before there was Scrum, writing the GDD in Microsoft Word and putting it in source control was a best practice. A wiki as the GDD is perhaps better than a Word document in source control.


Article Start Page 1 of 5 Next

Related Jobs

InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Software Developer JavaScript (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Backend Developer Marketing / CRM (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Software Developer Flash (m/f)
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[09.01.14]

Mobile Developer iOS (m/f)






Comments


Michael Black
profile image
I stopped reading at "A Game Design Document (GDD) isn't needed anymore"

Anonymous
profile image
"A Game Design Document (GDD) isn't needed anymore" is a pitfall, not a lesson.

Jobe Lloyd
profile image
Its important to keep in mind that Agile and Scrum advocate adapting the process to your particular situation/project as a key component. That said, all lessons learned should be viewed in the light of the project. There are certainly general types of projects, ie games, but I doubt even they can be so easily grouped into a single bucket.



All that said, I have had very contrary experiences and learnings to a number of these learnings, and others seem very on target.



#10 - I think this could be number one, not number 10. Very important



#9 - I think you can see a pretty direct relationship between #5 and #9. If you let daily stand ups turn into status meetings then you have already lost. They are not status meetings, and you those speaking should not be reporting progress scrumaster or Project Manager. They are commitments to the rest of your team, in front of the team, to achieve the current sprint. No electronic tracking will every replace face to face interaction about what an individual is doing to make the team succeed, in my opinion.



#8 - Interesting approach, very cool if you can pull it off.



#7 - pretty straight forward, as long as the person is not compromising the sprint by pulling tasks from beyond it and neglecting tasks they could do in the sprint



#6 - This one is kind of a mess, you are talking about QA and process management in one item. They are seperate things. Integrating QA from the start is a HUGE win, 100% agree there. But I dont see where the "Decide that your Scrum stories and sprints are 100% completed months before" comes from, thats very un-agile. You should know that you cant possibly plan 100% of your stories months in advance, thats why you break them down as you get closer to their delivery (Epics/Themes/Stories).



#4 what? again a confusing entry. Of course scrum is just a tool in the toolbox, it shouldn't necessarily be mandatory for every process in the company. But then you switch to management feedback...kind of lost me there. Management feedback is important but whats that got to do with scrum being mandatory?



#3 - good point. We frequently employed design stories that were intented to guide future stories (in and outside the current sprint) to help solve this. Also employing XP in conjunction with Scrum helps here.



#2 sounds good



#1 kind of the same as #10...but agreed





Interesting read, thanks!



-jobe

gfsd gfsz
profile image
Wow, that really reminds me of just how bad the games industry can be.



Have you actually have a book describing Scrum, Agile or XP? Just one? Perhaps read a few more before applying it.



I think you need to think about the roles on the team, perhaps consider designer to be a customer. The customers generate user stories and the programmers generate the tasks for the back log. Often games design docs are fully of designers supposed technical information that is useless. This really cuts down the ammount of work the designer has to do.

Chris Osborn
profile image
Actually, spreadsheets do have multiplayer mode. It's called Google Docs. We use it for collaborative spreadsheeting a lot and it's pretty damn cool.

Shane Neville
profile image
I personally feel really bad for Paul Miller and his poor experiences with Scrum. It's like reading "Spike TV Presents: When Good Scrum Goes BAD!"



With 9 non-Scrum games and 1 Scrum game under my belt (and another on the way), I am a firm believer that when Scrum is done right it results in higher morale, better games less risk and less overtime.



Every single problem mentioned (yes, all 10) come from a misinformed and improper implementation of Scrum and not adhering to the principals of Scrum and Agile development.



Scrum doesn't stop bad managers from being bad managers. No project management system in the world can do that.



Paul - it would be very interesting if you took a couple of nights and read "Agile Software Development With Scrum" by Schwaber/Beedle and reflected on your experiences with Scrum to see how they lined up.

Chris Osborn
profile image
I agree with Jobe, you cannot and should not replace face-to-face scrum meetings with databases. If the answer to the question "What I am going to do today?" was just that, a database could work. But as Clinton Keith points out, that question is actually "What are you committing to finishing for the team by the next time we meet?". Promising work done (and delivering the next day) in front of your teammates is extremely motivating. I have however seen electronic scrum databases work just fine, but only with the team physically meeting and updating it together.

Chris Osborn
profile image
Link for the Clinton Keith post...

http://www.agilegamedevelopment.com/2008/06/daily-scrum-question-
2.html

Clinton Keith
profile image
Good article! I had some lengthy comments, so I posted them on the Agile Game Development blog:



http://blog.agilegamedevelopment.com/2008/07/feedback-top-10-pitf
alls-using-scrum.html

Clinton Keith
profile image
Thanks Chris!

James Wiggs
profile image
Great Article!



Scrum is a tool, nothing more and it always takes great people to make great games. It only takes "weak" management or "feature creep" to destroy milestones.

Anonymous
profile image
At the core of the process is adaptation. Perhaps you would be served spending more of your time assisting your colleagues in adapting these methodologies to fit the needs of the team and less time writing long-winded treatises on what you perceive to be their shortfalls. A refusal to be flexible (or even participate) puts the process - and potentially your project - on the fast track to failure.



You have to adopt processes before you can adapt them.

Fernando Angelico
profile image
'I stopped reading at "A Game Design Document (GDD) isn't needed anymore"'

sad ,because the article tells the exact opposite

Clinton Keith
profile image
Agreed, esp. effectiveness over efficiency. "Slack" by Tom DeMarco is my favorite books on this topic.

Etienne Christophe
profile image
Funny how the first to stop reading is the first to comment :)



And his comment was completely erroneous.

There's a lesson in there somewhere...

Etienne Christophe
profile image
Whoops, hit submit too early (a lesson there, too?)



The problem with software process critiques is that a software process is like a user interface. Everyone *thinks* they know the best way to do something. As a TD, I'm more interested in what works.



I usually find case studies on successful projects much more useful than top 10 lists. I like to hear a real story of how a successful project came to pass, rather than "this sucked", or "this was great".



Every organization has it's own context. I can imagine an environment where all 10 of these pitfalls were actually beneficial. If you can't, you haven't been around long enough :)

Diogo Neves
profile image
I don't know much about Scrum but it looks like the problem here is that the management team are using a reactive approach and expecting a proactive attitude from their team.



In other words, they are assigning tasks to individuals and waiting for them to know by themselves what to do next. Because in the first place they (workers) have to wait for management team they'll start to adopt that behavior.



Just an opinion ;)

Jay Brown
profile image
Excellent article, Paul.



It’s true that I can’t address Agile and Scrum methods to any real degree, as I’ve only a cursory understanding (I bought the books, etc – never actually on a project).



Nonetheless, I have been part of the game industry for a long time. So, like Mr. Christophe I have seen it done six ways from Sunday. I have spent years working with producers, designers, and engineers (artist too, but mostly the ones with the more nebulous interactions) in attempts to figure out best methods. Hmmm. I think I might be the guy that rolls his eyes every time I hear some “can’t plan a thing” wack-a-mole start talking about lack of communication. To me this is often more indicative of those not well versed in the job. Don’t get me wrong, please. I don’t want to be negative, or slight the strengths of any particular methodology. But that’s just it, some methods work better with certain sorts of development/developers, perhaps even based on genre or pre-existing technologies. I agree with the general consensus here (Grassroots, good stuff!). If you have a good idea and great people, and you can stomach microsoft project, then you have a chance at success (I'd like to think there’s some out there that can do it with postit notes). Mediocre staff, or vision/leadership, and all the scummin’ in the world won’t help. Anyway, your suggestions are forged from real world experiences. So even if these methods are a response to “those not managing scrum correctly”, they are valuable bits of knowledge for that very reason.

Drew Miller
profile image
I like the "Agile is a toolkit" thinking. I have tremendous respect for people and places that are trying to improve their work-flow. It's always gonna be a risk, somethings are going to fit, others ain't. I found this article very beneficial.

Jack Crow
profile image
Let's counter some of these "complaints" that are just plain bad implementations of Scrum methodology.



10. Nowhere does Scrum say that a GDD isn't used. Features and tasks are not Design specific, they are planned goals. If you need to collaborate there is a perfectly good way to get lots of people on a single document, and lots of crappy but "good enough ways". This is a failure to research collaboration tools or to read up on Scrum methodology.



9. Scrum meetings dont have to take place away from the developer's stations. A phone and a shared desktop view is more than enough for each station. In the end, people being late has to have consequences for there to be incentive to attend. Some take a soft hand to it, I always suggest a hard stance. It's a business requirement and making the product owner wait for a demo meeting versus making your team wait to start a scrum meeting needs to have the same impact. If you can't stomach that in the early stages, we'll replace you. You agree to come in to work every day, you better be on time when it counts and nap after, we have a couch.



7. Scrum tasks should be continually updated by the Scrum Master. It's a role with RESPONSIBILITIES. If the scrum master says he's creating a task, that should be good enough to start. Again, it's a matter of not being a dick about process. If you're gonna be a problem, you're gonna be replaced. If the task never gets made, add it to the story of the next task you work on. Documenting what everyone does is part of scrum.



5. This is exactly what most scrum meetings are. This is a Good Thing(tm), since it brings up issues commented on in later points as a complaint "where do we talk about this". Daily Scrum meetings is where. Once you see adherence to documenting whatever is said in the scrum meetings, just have the members mention the feature, task, and that's it. Joe: FEAT-31, task 2. Started FEAT-31 task 4 and 5. The Scrum Master should be reading through the task notations. All of them. Welcome to 50% focus factor OR LESS.



3. Design is not the scrum's concern. They are handed that BEFORE starting (Sprint 0). The fact that the features are obviously incomplete or not planning for the future is something you bring up during sprint planning. "We're not going to do FEAT-52 because xxxx was not thought of." as you pull things from the backlog and leave others behind and either the product owner revises, adds, rethinks FEAT-52 for next sprint, or replaces a member with some schmuck who will do it and that's a choice members have to make. Product owners make the decisions, developers implement them. If you wanna design games, change your job title.





As teams grow, you simply create scrum hierarchy with scrums of scrums. This is how Microsoft created the MSN AdCenter and a number of other products.



The primary problem with SCRUM is where Bugs fall into the work flow and how to categorize, prioritize, and handle them. Most people assume QA is handled outside of sprints which is terrible. Concurrent QA is necessary from the start.

Andy Trowers
profile image
@Jack Crow



Maybe I'm misunderstanding you here, but I disagree that design is not the scrum's concern.



One of the strengths of scrum is that each of the team members has an input into the design and therefore has increased buy-in into what they are creating. Sure there should be a high level design for each area of the game so that you have an overview, but the design for each area should be fully fleshed out by the team assigned to work on it in conjunction with the lead designer at the start of a sprint. This leads to greater motivation from team members and a fuller understanding of the overall area they are working in.



Agreed with your last point about QA though and about scrum masters being at about 50% focus.


none
 
Comment: