Game Law: SCRUM Deals - Good, Bad or Ugly!

I just read this interesting article in Gamasutra. In it, Tom Buscaglia makes the case that if you are using Scrum to develop games, signing a contract with a publisher that takes Scrum into account is difficult. He raises a concern that many developers adopting Scrum have raised.

I agree that contract solutions for iterative development are different, but there is no reason that existing models can't be applied. In fact, Tom wrote an article about flexible milestone deliverables. He does point this out, but says that Scrum is incompatible with "hard-set objective-predetermined milestone deliverables", but this is not what the flexible milestone deliverables article is saying. In that article he says that the publisher and the developer define each milestone (past the first two) based on the the last milestone. This is an iterative contract approach! This is not incompatible with Scrum. In fact flexible milestones, used by many publishers, are a acknowledgment of the iterative nature of game development.

Scrum is a framework. For example, it doesn't define technical practices or how to handle "milestones". Practices can be added to support both. For example, many teams add XP practices like Test Driven Development to create code that can better support iterative development. Another set of practices are those defined by Mike Cohn in his book Agile Estimating and Planning. There is nothing against with defining milestones the same way you would define releases. Your product owner should pay attention to the amount of change that is introduced during the release so that the release backlog matches the milestone definition agreed to. If this is too hard to do over three months, work with the publisher to have shorter milestone intervals. I don't think many publishers would argue with receiving more regular builds.

If anything this iterative milestone approach encourages communication about the product between publisher and developer. Contracts with fixed milestone deliverables/payments discourage change and therefore communication. Both parties may agree that the game is not as fun as the original design document and contract anticipated halfway through development, but for the sake of those payments, no change is allowed (and I have never seen a contract rewritten during development).

A Product Owner for Every Team

At Agile 2007, I went to a session called Product Ownership. I was interested in any session of product owners because we have hit issues with having one product owner for a large team and have experimented with having embedded product owners in multiple teams. I was hoping to hear stories from other teams who have addressed the same problem.

The session consisted of three good presentations, but one in particular hit the mark in addressing the multiple product owner solution. The presentation was called "Effective product ownership within a multi-component project" by Mike Lowery and Marcus Evans.

The presentation covered a project being developed at the BBC which delivers television shows across the internet. The project is large. Nine Scrum teams have been created to work on it.

The team immediately ran into problems having one product owner (quotes from the proceedings in italics):

• The Product Owner was so busy that he was not available to make timely decisions.
• Even though the Product Owner was manically busy, he never actively empowered the teams to make their own decisions. This lead to an interesting shift in development. Some teams were frozen by this and development slowed to a crawl. Other teams did what they felt like and moved the development forward only to have work scrapped when the rumors stopped and the Product Owner finally gave direction.
• Product backlogs were not prioritized so teams started to build items in the order that they preferred and moved unattractive items to the bottom of their product backlog...
• Whenever any attempts were made to prioritize the product backlogs, the Product Owner struggled because the items on the list were only understandable by the teams who wrote them.
• The number of scope meetings rose to fever pitch, as what was in and out of scope was never clear and the Product Owner was never available.

The team went through a few changes to the product owner role, creating two product owners and eventually moving to having each team appoint an embedded product owner (PO as Pig). The benefits were:

• Clear product ownership.
• Definite project direction.
• Questions were answered quickly.
• Delivery teams had planned thought out product backlogs.
• Work picked up pace and we were back to delivering new functionality each iteration.
• The in-team Product Owners became subject matter experts.
• Each team put itself into a specialist silo.
• Team direction was not always business direction.
• Product backlog items fell through the gaps between teams.

The first concern raised about this (and we raised it ourselves) was how to avoid silos for each team and a lack of vision for the product as a whole. This is addressed by maintaining the central, or core, team with a project product owner.

The Product Owner from the central team does not give direction on individual features and rather is there to ensure that the overall business direction of the project is maintained. They also ensure that things do not fall through the perceived cracks between the teams, and that dependencies and impacts are captured mapped and coordinated. The in-team Product Owners were retained to act as product specialists more than pure Product Owners who set priorities.

The role of the core product owner is to identify the epic (large) stories and their priorities for the project.

This has worked well for the BBC and has worked well for us. Communication among the product owners is important and deserves a regular stand up meeting to address impediments to the vision of the game.

Agile adoption story from Google

Following questions from someone introducing Scrum at their company, I reread an article called "Ssh! We are adding a process..." by Mark Striebeck. I'd recommend this article to anyone introducing agile to their company, especially a company as anti-process as Google.