Category Archives: Project Management

The Chore Problem

In an equal partnership, both sides feel like they are doing more than their fair share.  It may seem like a paradox, but consider that the work that you do is immediate, tangible, and fully known by you.  Every bit that had to be worked out is in your memory, because you did the work.  Your partner’s work, on the other hand, while you may understand the outcome of it, cannot be as detailed in your own perception as your work.  Thus, two people, each doing the exact same amount of work, each feeling like they have done more than their partner.  In a successful partnership, both sides accept this inequality with grace, invert it through humility, or fail to register it entirely.  Others argue about who’s doing more of the chores.

This problem can be explosive in project management.  If you have one or two, even a handful, of people on your team who feel like they are doing more than the people around them and – this is key – feel this is an injustice, you’ve got the seeds of dissension.  Let these things simmer, and they will boil over.  Agile has a number of tools for handling this.  For example, at the daily stand-up, the group establishes a consensus about where they are and where they will be when they next meet.  This helps make the work that everyone does more visible; sprint planning has a similar function.  Even more powerful is the sprint review, because there people can demonstrate the work they have done, what they have accomplished, how they have contributed.

Agile is not the be-all and end-all.   You can accomplish the same goals through milestone reviews, team meetings, peer review processes, pairs programming, etc.  But, keeping your team calibrated, efficiently communicating how everyone is contributing, acknowledging and rectifying any deficits, and celebrating the accomplishments of the team (through individuals) can help to promote a culture of mutual respect.  In diverse, cross-functional teams, this can be a challenge, but leadership is about stepping into those vacuums when no one else even recognizes the dynamic.

Happy Valentine’s Day.

Minimum Viable Product: Still Viable?

One of the early revolutionaries in thinking about game development as a process was Mark Cerny.  He evolved something that became known as “The Cerny Method” over a number of development cycles, the basic summary of which would be along the lines of “build one of everything you’re going to have in the final game, prove that it’s fun with those pieces, then throw all of that away and re-start the project knowing what you now know.”  That’s rough, crude, and over-simplified, but it was a watershed moment because it gave a clear shape to pre-production vs. production.

What are you trying to accomplish in pre-production?  Prove the fun.  How much do you need to build?  One of everything.  Should you carry over your architecture from pre-production into production?  No.  It was a clear and practically universal standard and goal that could be applied to a variety of projects.  It allowed developers to answer two key questions: do you know that the game you’re trying to build will be fun and if so how long will it take to build it.

The Cerny method evolved in turn into the notion of a first playable, then a vertical slice, and eventually in more agile environments into the shippable version of the game that you’re preparing each sprint.  In social/casual games, this morphed into the MVP – minimum viable product.  The goal is similar: build only as much of the game as you need to verify you are ready for the next phase.  In this case, it’s usually about going from production to beta, but the structure is almost identical.

Both the Cerny method and MVP are about mitigating risk.  Fail quickly, if you’re going to fail; reach your market as quickly as possible; optimize production knowledge about resources and requirements before committing.  MVP has the additional benefit in the free-to-play space of getting you to the point where you can begin to monetize, and therefore generate revenue, as quickly as possible.  In a rapidly evolving, high-growth market, launching early is not a liability; no one is quite sure what the experience is supposed to look like anyway.  In a highly competitive, red-ocean scenario, though, it can mean death.  If you’re trying to pull users away from other services that are already meeting their needs, you need to be at least as polished as your competition, or you will suffer from the comparison.

When social/casual games blew up, MVP was a critical tool for success and became part of the common knowledge of people working in the space.  Now that the market is reaching (or has passed) the saturation point, though, the question is whether MVP as an approach helps or hurts the success chances of projects.  As an optimization tool, I feel it is still a valid point of reference.  The key nuance that needs to be understood is that what qualifies as “minimum” has shifted.  Just as the Cerny method evolved from first-playable to vertical slice, MVP needs to encompass not just the core gameplay loop, but also the core viral hooks, monetization paths, and new-player on-ramping.

All of the “free” channels for driving user acquisition have dried up, at least compared to the scale on which you could leverage them previously.  When launching a product, then, you need to be sure that you’re competing at a level that is appropriate for today’s marketplace, not last year’s, and the bar gets raised day by day.  MVP isn’t obsolete, any more than the Cerny method is, but they’re tools that have to be intelligently applied.  User error can still do tremendous damage.