Sunday, April 22, 2007

Power of Two Games

Noel Llopis and Charles Nicholson (two former High Moon programmers) have created their own startup game development studio called Power of Two Games. Besides being two incredibly talented programmers, they were instrumental in our adoption of agile processes. Noel's team beach-headed our adoption of XP and TDD. Charles was a great agitator at High Moon for doing things better and contributed to our evolving process that eventually led us to Scrum.

I'm very interested in what will grow out of this venture. They've started a blog to document their experience. Let's watch!

Sunday, April 08, 2007


Thoughts on the best way to prototype using agile practices.

Pre-Production & Production

One of the major differences with using agile for game development is the separation of activities during pre-production and production. In the past I have shown this using a version of Ralph Stacey's Agreement and Certainty Matrix:

This argued for more iterative and exploratory development during preproduction. One of the goals of preproduction would be to gain certainty of the game's technology and come to agreement on the requirements for all production assets. This would likely be done by creating a number of final quality levels and characters, for example, that would demonstrate the scope of the full game.

Once in the "simple" area of certainty and agreement, you can apply production methodologies (some prefer "lean production", others more traditional waterfall like methods) to complete the set of assets to ship the game. If you are using Scrum, then you might change some of the practices in production in the following way:
  • More is scheduled and preplanned. Less planning occurs in Sprint planning.
    • Smaller backlog, bigger Gantt charts
  • Sprints and Daily Scrums address support for the production crew.

Where do Prototypes Fit In?

When you are working on new genre, engine or platform, you're actually in the "anarchy" area. This area is so fluid and uncertain in nature that the standard Scrum practices need tweaking here as they do in the "simple" area.

Prototypes of what you want to do in a new genre, engine or platform environment would live in the state of "anarchy". The main value of prototype iterations is knowledge, so prototype efforts differ from pre-production because you're more likely to throw away what you've tried during the last iteration and try something else.

Scrumming for Prototypes

So how should the Scrum practices change for prototypes? There are two issues that need to be addressed.

The first issue is that even trying to plan for a two week Sprint cannot be carried out with a great deal of certainty. When you can't do that, you can't make a commitment to a well defined Sprint backlog. The team needs to be able to commit to take ownership.

The other issue is focusing on building knowledge through focused discovery. We don't want the team going off hellbent on some open-ended, ill defined goal that could take up too much time.

The answer to this is use more spikes. A spike is a time boxed experiment which is meant to produce knowledge. This knowledge is used to improve technical certainty or requirements agreement.

Spikes usually refer to tasks which produce knowledge for user stories, but in prototypes we use them to refer more to stories themselves or even the entire Sprint.

So getting back the Scrum practices our team has tried a few things that work during prototypes:
  • More fuzzy stories for the Sprint
    • More exploratory
    • Conditions of Satisfaction that are more subjective (e.g. is it fun?)
    • Can be met early in the Sprint, with room left for continual improvement at the back end of the Sprint (iteration within the iteration).
  • Full team ownership
    • The product owner for the feature is on the team doing work and the entire team is creating new ideas (the fate of the PO and team are shared).
  • Larger time-boxed tasks
    • e.g. "iterate with game designers for four days" (you have four days to make it fun).
  • Daily Scrum is different
    • We start by playing the prototype (let's see where we are at).
    • New tasks introduced (inspect and adapt)
      • Time-boxed work is broken down (we get specific when we have the knowledge).
  • Eliminating the burn-down chart
    • When almost everything is time-boxed, what's the point?
These practices have resulted in very rapid progress which is very quick to exploit new discoveries when even two weeks is too long to wait.

Hey! That's not Scrum Anymore!

Yeah it is. See my last entry.

Saturday, April 07, 2007

Kill Gates and Product Owners

Kill Gates

I often read DanC's "Lost Garden" articles and have been thinking about this one written a month ago that struck a chord. "Kill Gates" are a brilliant way of approaching a portfolio of games for a publisher and a set of key features for a single game.

The idea is that a team can use an iteration-feedback cycle to rapidly converge on the best game possible. Conceptually this is very straightforward and makes sense. Teams adopting iterative practices, such as those with Scrum, have typically seen immediate improvements. However there is a typical stumbling block that occurs with many teams that prevent the full benefit of an iterative approach that DanC describes. This stumbling block has to do with the role of "Product Owner".

Product Owners

In Scrum, the Product Owner (PO) is a customer who prioritizes the set of features desired for the game into the "Product Backlog". Each iteration the team looks at this backlog and selects a number of higher priority stories that they commit to completing. They come back two to four weeks later and show the game to the PO.

The stumbling block is that many teams often don't have the best possible product ownership in place. There are a number of reasons for this:

1. PO experience. Mike Cohn and Ken Schwaber have been conducting Product Owner Certification Training classes to address this issue.
2. No PO in place. Teams can be their own worst PO. Pet features and individual interests can prevent the objectivity that a good PO can provide.
3. A PO who is too distant from the iterations and teams.

This third condition is the one that can be the most difficult to address. One of the key Agile Values is "Responding to Change Over Following a Plan". If a PO doesn't see the game often enough or prioritizes based on the plan on their head, then you could be iterating towards a bad product.

PO with a Plan

The "document in the PO's head" sets very strict limits that prevents the team from responding to what is working or not. As with any other "upfront plan" based approach, it postpones the reality of what is being created and results in wasted effort (cost overrun, schedule slip and crunch).

Aligning the PO role for success
One of the major emerging differences with our implementation of Scrum (as opposed to the standard practices you start with) has to do with the role of the PO. We no longer believe in having a remote PO. The reason is that it's almost impossible for a game Scrum team to work for two weeks without input from the customer. Too much of game development involves intangible elements that defy enough definition for a team to predict their work for even a Sprint. In fact, when prototyping a new mechanic, the team will often want the PO available all the time. The teams have changed a few things to make this work:
  1. More Spikes where necessary
  2. Product Owner as a Pig
  3. A Hierarchy of Product Owners
More Spikes where necessary
How many hours will it take to make Mechanic X fun? How many tasks are required? You can probably predict a lot of the work that is required to get the mechanic working with some test assets, but you need daily, hourly and even instantaneous iteration to explore and discover the magic recipe that will entertain the player. That part cannot be easily broken down into tasks, but the team can estimate a certain portion of time that it will explore. This is called a Spike. A Spike is a time-boxed task that allows flexibility with some predictability. By trying to predict too much with more defined tasks you can actually limit yourself and go down a wrong path (it's a form of a plan with not enough knowledge). Spikes create knowledge. In fact while creating a initial prototype, half the team's time taken up with Spikes.

Product Owner as a Pig
If the team wants to explore with Spikes, they will need instant feedback. This feedback is not only cross-discipline (e.g. designer-programmer), but with a customer. The customer may own the vision of a key mechanic.but the customer is supposed to wait for two or four weeks before they can give feedback. This may not be best for the progress of the mechanic. So does the team drop the practice that the customer is supposed to let the team take ownership and commitment or make them wait? Neither choice is best under these circumstances.

Our answer was to make the customer part of the team. Typically the on site customer is a programmer, artist or designer anyways, so they can add value to a team by taking on tasks. By giving this customer the ability to prioritize the work for that team, you are also making them the PO. By making the PO a part of the team, you are creating accountability in that PO for the work being done. Accountability works wonders on how well that PO will prioritize and pay attention to cost. It works.

A Hierarchy of Product Owners

So now we've created a PO for every team creating a mechanic. This can create problems. This can cause a bunch of mechanics that aren't consistent to be created. These PO's need to work together and there needs to be one PO who is guiding the entire project's backlog. Call this the "Lead Product Owner" if you'd like.

Hey! That's not Scrum Anymore!

There's been a great deal of debate (again) about what Scrum is at the Yahoo Scrum Development mailing list recently. This time around Ken Schwaber created a separate list for those who want to carry on with the debate. The message from Ken (that I agree with) has always been that the Scrum practices are meant to be changed for each application. The agile/Scrum values and principles behind them are supposed to remain constant.

The main debate that we have had is whether the changes above take ownership and commitment away from the team. For large teams, we have found these changes to be necessary. Small teams self-organize fine, but large teams have additional issues that prevent this from happening. Mary Poppendieck uses an analogy for bands when describing the level of leadership required for different sized teams:
  • Level of Leadership
    • Jazz Ensemble – Set the tempo and start the piece. Rotates.
    • Jazz Band – Direct the band, but not featured instruments.
    • Orchestra – Direct the orchestra and interpret the piece.
Large teams are like orchestras and require a conductor.

Remember, this is what we came up with and may not be best for you. Don't be afraid to experiment. At worst your velocity will suffer for a Sprint and you'll change things again. Scrum is about reacting to change.