How to Manage an Exploratory Development Process
(Kellee Santiago and Robin Hunicke, thatgamecompany)

For this first session of the day, the presenters focused on solutions to problems that arise when developing games like Flower where experimentation is required to find the "magic." These problems were generally planning, communication, and interpersonal relations problems. However, the talk actually had broad applicability regarding quality of work environment in the game industry.

During development and after the release of Flower, thatgamecompany was experiencing serious morale problems, resulting especially from stress and arguments about experimental game mechanics. For example, there would be a disagreement about whether a mechanic would be workable, people would get into a heated discussion, one person would refuse to accept a mechanic and then another would come in over the weekend to implement it to prove it works, etc. The result is that everyone gets emotionally burned out. They realized that this situation was essentially unsustainable -- that working in that sort of environment would destroy developers and their company. (They posted a quote from an IGDA whitepaper that most game developers burn out and leave the industry within 5 years.) Recognizing this, they started searching for ways to fix their problems.

One of the primary problems they addressed is that developers often are not open and honest in communication. For example, and developers are often afraid to show weakness by being open about the fact they are having trouble implementing features on schedule. As a result they suffer silently and can experience serious anxiety. The solution is to create an environment in which it is okay to say "I need help." This extends to relationships with publishers as well -- thatgamecompany gave an example where they had to admit to their publisher that their initial prototype for Flower wasn't quite right yet -- and as a result they were able to get more time to iterate their prototype and ultimately make a better game. These discussions may be difficult, but having them is better than pretending these issues don't exist and letting them cause anxiety.

They also presented a rough outline of their scheduling and estimation methods. Unfortunately I'm not sure there was enough detail to really replicate their process, but the overall idea is that they estimate using large, rough blocks of functionality placed at approximately monthly resolution to create a schedule estimate, and then for finer-grained task tracking they keep track of units of functionality that take about 2 weeks to complete. Progress updates from developers are required 3 times a week. They claimed to not be a proper "Agile" studio, but a lot of their processes sounded similar to agile development in practice.

The session basically ended with a sort of collective ego rub, congratulating the attendees for being part of one of the most difficult and anxiety-inducing industries in existence.