Sunday, December 30, 2018

Improving Live Game Feature Flow

A studio I visited had a live mobile poker game that had been very successful. Money from in-game purchases of poker chips had been pouring in for years, but the competition had been heating up and revenues were slowly falling. The root cause of the problem was the success of the game. The might sound strange, but a successful game often hides problems. It’s human nature to tell yourself not to change anything when things are going well. Ironically, that’s the time when you should explore improvements: you make better decisions when it’s not an emergency.

The other reason success is so dangerous is that it leads us to splurge. For example, it’s easier to staff up by 50% when you’re making a lot of money. But all those new hires need something to do and often that extra work can slow things down. This was the main problem for the poker game. They had 160 people on the team and it was taking six months to implement major new features.

The six-month development cycle created problems:
  • Taking that long to determine if a major new feature will be successful in the market is a very expensive gamble. 
  • The competition that has shorter development cycles can beat you to market. 
Although the team was using Scrum to implement features, there was a lot of waste outside of Sprints that had to be eliminated (and a few challenges for the Scrum teams as well).

The first thing to do was to map the flow that an idea for a new feature went from concept to player delivery. Doing this exposed the following:
  • New feature ideas were huge. They were captured in 20-30 page documents. 
  • Because features were so large, they went through numerous revisions and reviews which took one to two months. 
  • It was easier to shoot down a revision because of the risk and cost of the feature than to approve it. 
  • It took time to gather all the principles for a review (at best twice a month). 
  • The Sprints were not addressing debt as well as they could have, which resulted in a lot of rework in subsequent sprints after a QA team found problems trying to validate builds for submission.
To address this, we implemented two main changes. One hard, one harder:

The hard change: Improving the “definition of done” with the Scrum teams to address debt. This required some automated testing, QA joining the teams and improved practices such as Test Driven Development. This was hard because it was taking for developers to change how they work and for teams to reorganize a bit. However, the benefits were easy explain, which made the coaching easier.

The harder change: Weaning management off of their need to make big gambles with major features, which led to the big design documents. The new approach was to create smaller experiments that could be tested with players and could inform product ownership enough to evolve better features.

An example of this would be a tournament feature for a single-player puzzle game. The original approach would be to design the entire tournament, with ladders and player ranking systems. This could take months and be subject to many design discussions before even the first UI element is created. The new experimental approach was to introduce a simple head-to-head mechanic where the game could experiment with how players could use the puzzle game in a competitive way. This greatly reduces risk as well, because a tournament that took months to develop would likely be a failure if the core of tournament play—the head-to-head mode—wasn’t fun.

This change in design culture took a while to optimize, but seeing the metrics of the flow improve became a motivational token for the leads and they embraced being part of the solution.

Ultimately, the business metrics saw a benefit from this new approach. The throughput of new features (albeit smaller, incremental features) increased from one every three to six months to every four to six weeks. Revenues started increasing. A side-effect of these smaller features was that the team could be smaller. Most of the team moved to other games and the poker team size was reduced to about 60 people.

No comments: