meet the client and gear up for scrum

It has become impossible to keep up with all of the things going on at GAMBIT, so I am writing this well after the fact.  Thursday involved a two hour lecture for each group by the product owner / researcher about the nature of the content and goal of the game. Often additional constraints were introduced. I sat in on a few of the presentations to find out what the strategy was for each of the researchers. I see now that I need to talk a bit more to some of these researchers to understand how their question came about and how they chose / prioritized the constraints.

The lectures were quite informative, and even deep related to the central subject matter. I sat in on part of the relativity lecture and didn’t realize that a) it was a smaller team and b) they had something that was at least partially developed prior to the beginning of the summer. I felt comfortable and even interested in the relativity discussion because of the musical I had made regarding Einstein’s theory.

I find myself moving from group to group quite a bit as I am interested in the different approaches that each researcher is taking, both depending on their experience and goals with the teams.  I need to have a much more in depth discussion with researchers (particularly those who have launched multiple GAMBIT games) to understand their considerations.

This work is in preparation for the first Design Sprint (which ends June 22).  The format that they have adopted for game development is based heavily on http://en.wikipedia.org/wiki/Scrum_%28development%29 and it is quite visible in the setup methodology.

The first design sprint accomplishes several important things, seeing as this is the second week of an 8 week process it is important to jumpstart the work and get the teams limited resources working as efficiently as possible. The first sprint’s goal is to create a beta prototype, perhaps more than one in different genres. This also permits research into other games, creation of priority lists of features, practicing workflow and pipeline design-code-build, affording time to look at others portfolios to understand their background and practice and to contribute to the Vision Document that informs the Design Document.  This also allots time working with the product owner and communicating about what the team understands about the project.

This is about prototyping and brainstorming. Team members need to get use to working out and testing one idea or a limited set of ideas within a constraint, getting critical feedback and either abandoning or adopting the results from the prototype. This also permits experimentation with content and mechanics.

So what is the final deliverable, and how does it factor into the design sprint? Incremental and experimental, focused more significantly on process than specific elements of the final project, but contributory.

Watching teams work on paper prototypes and research games was encouraging, I am impressed by the way the teams are keeping focused and making incremental progress towards the presumed goal (though I am not sure how well that is understood, or can be understood).

To see what the results of the design sprint look like the video series at http://gambit.mit.edu/making is really quite complete: http://gambit.mit.edu/updates/2010/09/making_a_gambit_game_series_ep_2.php

— links about scrum —

http://www.mountaingoatsoftware.com/presentations/50-scrum-for-video-game-development

http://www.mountaingoatsoftware.com/presentations/30-an-overview-of-scrum

http://www.indiepinion.com/scrum-resources/scrum-in-game-development/

http://www.gamasutra.com/view/feature/3724/top_10_pitfalls_using_scrum_.php

Advertisements