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.
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
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.
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
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.
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.
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
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.