Problems to Avoid When Introducing Scrum to Customers

(I’m quoting a very handy short extract from Clinton Keith’s December 2007 Gamasutra article, so that I can find it again easily later. Clinton is/was the CTO of High Moon Studios, and is probably the most well-known proponent of Scrum in the games industry. Rather than wade through the whole article when I want to pass on some of his advice, I wanted to be able to copy/paste the relevant sub-bits)

When you give visibility and control of the feature set to the customers, there are some problems that you should watch out for.

  • The customer who doesn’t always know what they want.
    As Spider-Man’s uncle said: “with great power comes great responsibility”. You are giving unprecedented power to the customer with Scrum. Not all customers know what to do with this new power. Make sure that the customer understands that every decision has an effect on the entire project. A pet feature that is being prioritized over other features will result in a more worthy feature being dropped later in the project. Scrum allows you to focus test early. Do that with the customer and see if your true customer really enjoys the game or not.
  • Customers who don’t always agree with one another.
    Sometimes the customer that shows up at the Sprint planning sessions isn’t the one you really need there. They may not share the vision of the rest of the customers and they might give the team feedback that can send the product off into areas that the other customers do not want it to go.
    Scrum’s solution to these problems is embedded in the “Product Owner” (PO) role. This is the person who has the final say over all customers’ input. This role is difficult to assign to one person on either the publisher or studio side.

A Product Owner from the publisher may not know enough details of development to properly prioritize some of the work that the team needs to do. A studio PO can be more responsive for all the customers that want to know about the vision for the game. This role is closer to a Project Director role than a traditional Scrum PO role. A studio PO can lack sufficient authority to override all of the customers, however.

Leave a Reply

Your email address will not be published. Required fields are marked *