Problems to Avoid When Introducing Scrum to Customers

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.

Problems to Avoid as a Scrum Project Customer

If you are a customer of the game (especially on the publishing side), there are things you need to do differently from traditionally run projects to avoid problems specific to agile:

• Avoid the "too many parts on the floor" warning signs.
  You and the team may agree on a vision for the game, but don't count too much on the future of that vision. Avoid excessive parallel development of multiple features where possible. If you find yourself saying "all these new things are great to see, and they'll be fun when they all come together in the future", then you may be planning too far ahead. You should expect some loose ends every Sprint, but you should also see the game getting more fun as well. Not every Sprint will be an improvement, but most should be. If the game continues to be iterated with problems that remain unsolved or parts that are not being assembled to make "more fun", then you need to demand that the team address these. This is your responsibility as a customer for an agile team. You can even request that they spend a Sprint just assembling the parts together.

• Don't replace a document with a plan in your head.
  Scrum is not a tool for you to micromanage a team. It clearly divides team ownership from the product ownership. As a customer you have to balance your vision of the game with the results that are being produced every Sprint. If your vision for the game is not panning out with the game that's actually emerging, it's time to ask yourself some tough questions about your vision.

• Being too distant or uncommitted.
  Customers need to participate in regular reviews of progress and iteration planning. It is not merely beneficial, but necessary, to the team's success. If you are too distant or have not committed to the regular cadence of the review and planning cycle of agile, then don't assume you are going to be pleased with the game when you finally see it months later. The team and customers rarely share the same vision of the game from the start. By understanding and influencing the small steps of the project, you remain committed to where the project is heading. If you cannot make regular trips to see the game, have the studio PO visit you. Receiving just the build is usually not enough. If the team is too far to send someone regularly, try to get them on a conference call with the latest build running at both locations and discuss the game.

• Communicating a vision for the game.
  Communicating the product vision within the team is hard enough. Communicating it between customer and team is even harder. As the customer for the product, you need to communicate about the goals for the project. This involves a clear understanding with the marketing team and every other stakeholder on the customer side and the team as well. If you don't do this you allow the team and the studio PO to define priorities different from your own. This may result in the development of a game you did not plan for. You also risk having the team retrace missteps, and waste time and money.

If the barriers for all the customers to regularly review and plan is too great, then there needs to be a single customer whose responsibility it is to represent them. As with the "studio PO", this "customer PO" can be the conduit for all the others. This role is closer to the traditional Scrum PO. With these two roles, the customer PO and the studio PO communicate on a frequent basis about the game and the backlog. The customer PO may have the last say on rare disagreements of priority between the two, but they should share a common vision.

Agile is About Continuous Planning and Change

Planning and Scrum are not incompatible, but the particulars of when to plan and how much to plan at once change quite a bit when switching to Scrum. Publishers and developers cannot replace detailed plans and schedules with anything but frequent communication.

Long term agile planning has been greatly enhanced by the practices that Mike Cohn has introduced in his book Agile Estimating and Planning, and in the courses he provides through Mountain Goat Software. These practices give teams additional tools to apply in predicting how much work can be done further out in the future, while still allowing an agile project to introduce change.

The bottom line is that Scrum is a set of principles and practices that can support great teams making great games. The practices are meant to be adjusted to the team, customer and product where it is being used. The team and customers should get used to iterating on how they work together in the same way they iterate on the game. It can take years to achieve the full benefits of Scrum, but you should start seeing some benefits right away.