(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)
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.
- Don’t replace a document with a plan in your head.
- Being too distant or uncommitted.
- Communicating a vision for the game.
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.