Search

Tuesday, February 11, 2014

How Do You Turn a Vicious Cycle of Distrust Into a Virtuous Cycle of Trust?

Very often, I see this cycle occurring in studios:

I call this the "Vicious Cycle of Distrust".  Having been on both sides of this cycle, I'm quite familiar with the damage it does to a culture.

I've also seen the reverse of this cycle, I call a "Virtuous Cycle of Trust":


I've changed the term "management" to "leadership" because a significant purpose of leadership is to drive this cycle, to create safety and purpose.  I've also called out "teams and individuals" rather than "developers" because the two act differently and teams are ideally more capable than just the sum of individuals.

I've also left some question marks at the interfaces as a question to you.  What are the interactions and values that need to occur to drive a virtuous cycle of trust?  To me these include:

The Scrum Values

  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.
What else have you seen that drives a virtuous cycle?

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.

Monday, February 03, 2014

The Attention Deficit Product Owner

We need to focus on everything” - an anonymous dysfunctional product owner.

 It’s great when a product owner has a strong vision. It’s not so great when that vision changes daily. Some famous game designers have been known for this. They have a dream one night, or their cat does something interesting that sparks an insight, etc. Next thing you know, they are running through the studio excited about their new insight and impatient to see it being implemented. Unfortunately, this can have a bad effect on the team, game and business. There is such a thing as “too much change”. Change should include empiricism. The product owner needs to measure their vision against the actual game and not fall in love with their ideas alone.

Don’t get me wrong, I love enthusiasm, especially when it can be shared, but it needs to be combined with a focus on demonstrating fun in the game. Focusing on too many things that will somehow come together months later is a debt we don’t want to owe.