We’ve shared quite a bit about our alpha-driven development approach at One More Game. Today I thought I’d shed some light on how we square our extremely iterative and experimentative approach to development with the fact that we do, in fact, want to actually launch a successful game one day!
One advantage of being an independent, venture-backed studio is that we aren’t beholden to publishers or other stakeholders with tight deadlines. Our investors are betting on our team and vision, and they have a significantly longer time horizon (and broader scope of support) than, say, a game publisher might. That, combined with the fact that we’ve kept our team size small relative to the amount of funding we’ve been lucky to raise, affords us a tremendous amount of freedom. We can take the time needed to find the fun, build our technology, and plan for what we hope to be a successful game launch…"when it’s ready."
"When it’s ready" can be hard to nail down. Instead of working backwards from a specific deadline, we’ve chosen to orient our development approach around milestones.
Outcome-Driven Development
At One More Game, a milestone is organized around outcomes, rather than a specific schedule or set of development tasks. Outcomes are a way to communicate with each other how the world should look when the work comes out. Each time we’re planning our next big chunk of work, we spend some time as a team identifying the current state of the world, and how we want our players to feel when things come out.
Outcomes can be explicitly measurable: "Players can sign up for and participate in the Spellcraft Alpha Preview Event." In this outcome players either can sign up and play, or they can’t.
Or they can be more subjective: "Players feel like a match has a beginning, middle, and end." Less objective outcomes demand a bit of additional discussion to ensure we’re aligned on how we’ll know whether they’re true. By focusing on the outcome, we drive from discussing a problem, and that ensures OMG developers know what success looks like and are delivering solutions that directly address the change we’ve agreed our product needs.
Crucially, this is a whole-team exercise. It’s a fantastic way to ensure there’s broad alignment across teams and disciplines, because we’ve spent time together agreeing on the specific achievements we’re aiming to realize as a studio in the immediate future.
Once we’ve hammered out the outcomes we’re trying to generate, teams – sometimes existing Feature Teams, and sometimes new ones – break out and define the features and tasks we believe will result in the outcomes we’ve agreed to work towards.
As a fully remote studio, we’re even more obsessed with documentation and transparency than we might have already been. We use a combination of an internal Wiki and issue tracking software to manage and document the development of those features and tasks. Issues track the work efforts towards those features and tasks, while Wiki pages capture specs and supporting documentation. We never "throw specs over the wall" – every document is an invitation to a conversation, not a replacement for one – and specs are linked to one or more outcomes of a Milestone and issues are linked to specs. Linking our information chain this way ensures that at any time you could ask an OMG developer what they’re working on and – more importantly – why they’re working on it, and get a clear answer that you also understand (you’ve been regularly refreshing your memory as to what is on the Milestone, right?)
Milestones are not locked to a particular deadline – they are, at least for us, on average about three months worth of effort, as that’s the largest window of time we can reasonably expect to plan with this degree of accuracy. Further, we don’t need to check every single item off the list in order to move to the next milestone – we’ll still close a milestone after three months. We cross the outcomes off of the list that we’ve achieved and roll the others into the next Milestone. We examine if the top-level objectives have been achieved or not from the previous Milestone, and then we evaluate what the next top-level objective should be.
Likewise, we are not fixated on "passing" or "failing" milestones. Instead, we take each opportunity to examine our progress and create new goals based on what we’ve learned about our game in the intervening time. We do not necessarily roll forward any incomplete outcome or feature into the next milestone – we re-examine whether that item still merits being at the top of our priority list.
Phased Publishing
Developing by milestone helps illuminate the question of "when it’s done" by defining "done" for discrete stretches of development. The big question, though, is really: "when it’s ready for players to love." Our answer is informed by how we think about publishing our game: a phased approach also driven by outcomes.
Instead of setting a target release date based on market research or arbitrary goals, our publishing plan for Spellcraft is oriented around requirements and results we believe necessary to expand our audience. We start by laying out some basic phases (e.g. Alpha Tests, Closed Beta Tests, Open Beta Tests, and Launch) that are tied to granting game access to a growing number of players (in earlier phases, this should be heavily informed by the development team based on how many players they need to get the feedback or data required to test what we’ve built), and to set goals across all facets of the business for a given phase.
As always, we’re on a mission to build games that make players say "…just one more game!" That means that before we introduce Spellcraft (or other games we make) to a lot of players, we need to be pretty confident that it has that intended effect.
For each phase, we have outcomes we believe need to be achieved in order for us to move forward and invite more players to the community. How many players keep playing after a week? A month? Do we have the partners in place and plans ready to execute to generate enough attention to recruit new players for the next phase? Are our platform and services robust and battle-tested enough to deliver on our promises to players? And so on.
We apply these questions to each phase we decide upon, until we have what we think we’ll need to navigate all the way to a "launch" state. The nearer the phase, the more confidence we have in the outcomes we’ve defined, and the more robust our plans become.
Why We Love Milestones
There are a few big benefits to this style of planning:
As I mentioned, it’s a teamwide effort that results in strong alignment.
It’s not arbitrarily time-gated. As long as we’ve got the financial runway and there are no strong external factors forcing specific dates, the team can make decisions about phase changes rather than rushing or feeling the need to crunch.
It’s data-oriented. Because we’re setting discrete and mostly measurable goals rather than ambiguous or arbitrary ones, we can confidently hold back big investments until we know we’re ready.
It gives us anchors for Big Decisions. "Do we push the button?" can be a difficult question, but this process helps frame the conversation.
It’s a living process. Plans can and should change. Developing by milestones gives us the freedom to add, shift or remove priorities without blowing everything up.
Sound like a development methodology you’d like to be part of? We’re hiring!
