Search

Tuesday, February 04, 2014

Tunnel Vision Product Ownership

"640K ought to be enough for anybody." - Bill Gates (supposedly said) in 1981

No vision is perfect, but sometimes the hardest person to convince of that is the visionary.  Given that a shipped game rarely resembles the original detailed design document, an equally detailed and prophetic vision buried inside someone’s head can be just as capricious. A common result is that the emergent gameplay quality is not taken into account and teams become disengaged.

I call this dysfunction “tunnel-vision” product ownership.  It’s common in studios transitioning from a design-document approach to an agile one.  Although the visionaries admit that detailed design documents fail to create a shared vision, they haven’t yet adopted an agile mindset which requires:
  • Frequent face-to-face engagement with developers.
  • The ability of teams to produce iterations of an emergent game that validates the vision (or not).
  • The ability of the product owner to evaluate their vision against the emergent game.
This leads to a major of pattern of dysfunction called:

Parts on the Garage Floor
The product backlog become a component list of features and functions that are necessary to fulfill the vision…someday.  This reminds me of someone building a prototype car, part-by-finished part.  They build a carburetor, then the tires, etc.   Eventually, when all the parts are built, an assembly phase is entered.  Even if all the parts fit together, it rarely results in a very functional car (check out how cars should be prototyped - http://wikispeed.org/the-car/).

The same thing happens on games.  The following practices are seen with the parts on the garage floor dysfunction
  • There are too many component (or functional) teams.  Examples:
    • AI team
    • Animation team
    • Design team
    • Graphics team
This is not to say that component teams are all bad.  Often they are necessary, but when a majority of a project is composed of component teams, it usually results in delayed integration and knowledge (i.e. debt).
  • Crunch sprints (usually called something else) with lots of overtime, little velocity or just tackle user stories created to address debt (refactors, bug fixes, polishing, etc). If most user stories don’t read like features users would pay for (e.g. I wouldn’t buy a game based on how many bugs the team fixed), it’s generally a strong indication that a good definition of done is not in place, teams are doing a lot of component work or debt is piling up,
  • Team disengagement - Teams that don’t have a tangible vision or one that is months away from being realized have a hard time engaging in their work.  This is especially true on larger projects.  Nothing will drag velocity down more.
Addressing Tunnel Vision
As with any cultural issue, tunnel vision is hard to fix.  Transforming a detailed-design-document focused culture to one of frequent communication and inspection doesn’t happen overnight.  There needs to be some bridgework between the two.  Before the documents are shrunk, the product owner needs to gain skill in communicating vision and in learning to respond to the emergent game.  To start with, I’ll find ways to improve communication in sprint planning, reviews and retrospectives.  Establishing a better definition of done, and phrasing the sprint goal in terms of true value (e.g. “what are we going to be able to play at the end of the sprint”) sets the context for what is expected (in the playable game).  Focusing the sprint review on the state of the gameplay sends that message as well.  For the team, it’s easier: having a product owner responding to gameplay communicates priorities.
For the product owner, it’s more challenging.  I encourage ScrumMasters to be diligent in asking the appropriate questions of the Product Owner in planning and review:
  • Sprint planning questions:
    • “What do you want to be able to do in the game by the end of the sprint?”
    • “What should the player be able to experience by the end of the sprint?”
  • Sprint review questions:
    • “Does the game demonstrate the gameplay you asked for in sprint planning?”
    • “Are these mechanics are as fun as we envisioned in sprint/release planning?”
    • “Do we need to make changes to the release plan/product backlog to course correct based on what we’re seeing?”
    • “What are the biggest concerns in making this game as fun as we envisioned for the release?”
  • Sprint retrospective questions:
    • “How can we decide earlier in a sprint if gameplay quality is achieving a vision?”
    • “What can we do to achieve the litmus test of a gameplay mechanic earlier in a sprint?”
    • “What parts of this game’s vision do the developers not believe in or have concerns about?”
These are questions for the entire team.  Discussing them as a group is very beneficial in supporting a shared vision.  Keep in mind the product owner will still own the final decision about the product backlog priorities.

It’s better to have a vision than none at all, but a vision must be tempered with reality.

No comments: