KB/Resources/IGDALF07/RoundTable1

International Game Developers Association

Contents 1 Production Methodologies in Practice 1.1 Participants 1.2 Introduction 1.3 Summary 1.4 Links and Resources

Production Methodologies in Practice

Participants

• Host - Chris Oltyan
• Lucien Parsons - Director of Production, Zenimax Online Studios
• (others who's cards are in a pile that I still need to find and sort.)
• (Enter your name here if you were there!)

Introduction

Many studios are looking into adopting Scrum and Agile methodologies that sound great in theory, but in practice how do these methodologies pan out? Also, TSP/PSP, PMBOK/PRINCE2, Rational Rose/UML, and Waterfall are still in wide use outside our industry. What elements from these methodologies can be applied to game development?

Summary

The time available and table makeup quickly made clear that there would be no time to delve into specific production methodologies. After a quick discussion three of the people at the table had implemented part or all of Scrum, but none had worked with any of the other methodologies listed. In fact, few people at the table outside of (?name) from Hansoft had heard of many of the methodologies. It appeared that while there were many flavors of Agile methodologies, few other than Scrum are well known in the game industry. It could also be a location issue, the European Space Agency (find source), are requiring Agile practices to be utilized for their projects. So rather than spend time talking about specifics of the methodologies, the talk quickly turned to "Why even use a methodology".
To open this open, I briefly introduced some problem solving theory presented by Dietrich Dörner. The theories are basically scientific analysis of what makes a problem complex and what must be address in order to solve them. Since project management is essentially large scale problem solving, it helps give a framework for what a methodology can solve. Not all methodologies have to address the ALL the issues of a complex problem, but in order to succeed, you must find some method to deal with the following:

• Intransparency – This translates to Requirements Gathering. The Client has a requirement or need that must be met, and the team must somehow identify what that requirement is. This is the first step in solving a problem.
• Polytely – Essentially, there are many goals for a single problem. We translate this to Tasking and identification of tasks.
• Complexity – A problem has many facets, dependencies, and decisions to be made. In order to overcome Complexity someone must properly set priorities. Accordingly, current methodologies have methods on how they handle Prioritization.
• Dynamics – There are many things that influence how a problem must be solved, but first and foremost among them is the fact that most people are on a schedule. Scheduling must also take into account risk and changing priorities.

After this discussion, we talked about what makes a methodology a methodology. We settled on a definition of what a methodology was, that being:

• Can provide a solution to a complex problem, as detailed above - When discussed, the methodologies all addressed the various areas of a problem, but sometimes had a lighter touch. For instance, UML is very structured in its requirements gathering, but Agile leaves a lot of room for determining requirements.
• Provides some method of Certification - The idea being it is not a formal methodology unless you can find someone trained in that methodology, and place them in your team. Sure, things are specialized in each company, but that certification will ensure they understand a basic amount of knowledge and can understand the structures of your team.
• Has its own specific Jargon/context for understanding - A plan is a plan is a plan. Or is it? Using words like Use-Case or Task can mean a lot of things, but within the context of a formal methodology, it has a very clear definition. It is key for a large group to be working under the same assumptions to be efficient.
• Has a structured framework - There are rules, and when everyone follows those rules, the methodology is being followed.

And from there, we talked about the adoption of methodologies. We came up with a list of things that need to be addressed for any company adopting any methodology. There was a general consensus that if any of these aspects were ignored, it would most likely ruin any attempt at installing a formal methodology:

• Monetary Cost - The very real cost of certification and training, as well as salary and time. For Scrum, this can be relatively inexpensive. For UML/Ration Rose, software alone can run up to $20,000.
• Opportunity Cost - What are you giving up to take on a new methodology? How much better than an existing system is it really?
• Follow Through - Implementing a methodology half-way and not supporting it is a good way to make sure the team thinks it was an awful idea. Management must be willing to try it for real if they are going to try it at all.
• Team buy in - Participants spoke of the difficulty in motivating the team to adopt more work, until it was made clear how it would improve their lives. The team needs to be able to see real meaningful results, and be willing to try to get there or things go poorly.
• Publisher buy in - To some extent, most methodologies have a certain way they handle changes to the project, and the publisher needs to be aware of these and willing on some level to work with the team.

Links and Resources

• Waterfall original source
• Scrum sites
• DSDM
• FDD
• UML/Rational Rose
• PRINCE2
• PMBOK