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".
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:
- More Spikes where necessary
- Product Owner as a Pig
- A Hierarchy of Product Owners
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.
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.