The lean service model

I’ve spent a long portion of my career building services and the ongoing struggle has always been to deliver meaningful releases on time and on budget. However, in the indie world the pressures are different from that which exist in a big telecom or hardware platform, and as a result we have to think differently. But are there lessons to learn for producing games?

Over 15 years ago I was introduced to the idea of formal planning with a vast array of documents to write from PID, PRD, MRD and TRD*. Classical IT development seems to like a lot of three letter acronyms. In games we have our own versions of course; the infamous GDD most notably.

The trouble with this formal approach is that we have to know what we are going to make before we make it. I have never taken a proper PRINCE2 course but have worked within many projects which tried to incorporate ‘Waterfall’ project management.

There is value in the idea that we define our criteria upfront and have the team all agree that before we start development. Its not just about the marketing department telling the team what they want, but also empowering the developers to agree that they have the resources to deliver to the plan on time.

These documents all go towards clarity and especially with larger teams this shared agreement allows us to better track progress and manage the costs. For instance if we see a section of the project falling behind, perhaps even becoming part of the critical path we can do something about it. There should also be no ambiguity about specific details because our requirements documents need act as mirrors reflecting both the product requirements and the technical approach signed off by project owners and the development team alike.

This ‘gated’ process is very different from the ideas of agile development if only because it focuses on the features to be released; rather than a pattern of time-boxed development sprints. However, it does still include some scope to manage change reviews which can accommodate for problems in delivery, late requirement changes and of course dropping no-longer required features.

Agile on the other-hand is less concerned with the wider project definitions; requiring instead a product owner to maintain a finite list of prioritised items which represent which features can be delivered in the sprint period.

These features still have to be documented in some form and usually include detailed use-cases but the structure is often more flexible. Arguably Agile cares a lot less for the completeness of a project than it does the ability to move to market quickly; however, don’t let that fool you. Each release is required to be shippable intact and the relentless nature of sprints gives the product owner a lot of flexibility and control.

This model of production planning, especially SCRUM with its daily 15 minute reviews and weekly post-mortems can be extremely effective when we are uncertain how long a feature will take to develop as well as its final form. As many have observed this is ideally suited to games which require considerable iteration allowing the product owner to respond to releases as they occur; changing priorities as needed between sprints.

Agile also attempts to create an environment of intensity and shared endeavour. Often I’ve found a less blaming culture when Agile development is used as developers are encouraged to share everyday; rather than just being ‘found-out’ to be behind schedule. However, it requires a team invested in the project rather than just looking for their next bonus check.

Both of these methods work fine for building discrete products; but I’ve personally never seen a team adopt either in an entirely pure form for ongoing services. There is always some compromise needed. Sure we need a shared vision of the game; but there are parts which are more predictable than others.

We don’t for example know if our game mechanic is really going to be fun until we play it using something like the art it’s supposed to have. Without that we have no context. But other aspects of service deliver such as the database framework for data-capture or our chosen mechanism for delivering content updates programmatically are more predictable. We need these things to be robust and unchanging to provide the foundations which the gameplay sits on top.

As I’ve said before I’ve been quite influenced of late by the idea of the Lean Start-up Movement (based on the book by Eric Reis) which talks about simplification of planning so we make only what is required to create the minimum viable product.

In games this shouldn’t mean the smallest we can get away with; it’s about the simplest thing which can deliver genuine excitement in our audience. The minimum awesome product if you like. This is something I’m not usually very good at, especially at the start of a new idea, but that changes when it comes down to prioritisation.

When push comes to shove and I have to decide between two concepts I can be brutal. What makes me able to do that is knowing that a service is a constant state of test. Each sprint we produce a new feature or element of content and release that, we see how it does and then decide whether to keep it or remove it. We also have a duty to keep the experience alive and evolving. That takes effort and a way to deliver predictable ongoing delight. It also helps that being a service when I drop a feature it doesn’t mean we can’t come back to it later if it becomes relevant again.

To keep an experience alive we don’t just need a simple list of prioritised features delivered to time and budget; we need a pipeline of releases, each of which stimulate the adoption and retention of our audience. Each release needs some kind of meaningful or ‘tent-pole’ feature which communicate value to the audience.

These themselves need to be treated as an individual hypothesis and tested, adapted and evolved. Of course without careful planning we risk creating a multi-headed hydra.

I’m not sure if either the Waterfall or Agile production process are ideally suited to solve this kind of problem. Instead I think we need to be more sophisticated in our planning.

Classical waterfall may work well to support your high-level strategy for the ongoing pipeline of work, but you might find that the teams involved with each specific release may be better handled using time-boxed Agile workflows. This might allow you to keep an ongoing pipeline and still iterate your ‘tentpole’ features and deliver targeted fixes which reflect data acquired from player’s responses to your previous releases.

In practice I believe teams have to find what works for them but taking time to learn the benefits of these planning models will help inform those choices but for me I believe there is great value to be found when you decide to build in Sprints, treating each release as a test; yet managing your a long term strategy through a more formal structure to sustain an ongoing planned pipeline.

I often hear Agile developers confusing a code release with a marketing or operational release. There is always the temptation to immediately deploy your new code to players.

However, instead we cab make it easier both for effective testing and to sustain the audience momentum if we keep one or more ‘Tentpole’ features in reserve. Ok. Don’t get me wrong we have to be careful not to go too far with this. After all, we need to sustain our fail-fast-fail-early ideals.

However, we need to be able to keep up a consistent pace. Predictability and Rhythm are usually more important than the particular time interval (although this should be weeks not months ideally). Consistency creates the feel of a seamless living service which delivers predictable delight, we just don’t want to be exhausting the team in the process.

In the end my point is that delivering services requires a deeper understanding of the needs of your team and a long term commitment. However, done well this is a labour of love and a path of constant discovery not just for your players but also for the team themselves. Managing this predictably and repeatedly is what in my opinion turns a Lean Start-up into a Lean Service model.

—

Glossary: In case you want to know my definitions of those acronyms

*Product Initiation Document – The formal document used to get approval to kick off the project as a whole

*Product Requirements Document – The detailed list of development requirements and use-cases needed to explain the needs of the project to the development team

*Marketing Requirements Document – The higher level description of the marketing requirements including the user experience, brand guidelines and stylistic constraints that will operate. Essentially how the product will feel from a customer perspective.

*Technical Requirements Document – The analysis of the Product and Marketing requirements in terms of the functional detail to be developed. This is often accompanied by a Technical Specification Document which outlined the detail of the technical solution and any related interfaces between modules or components of the product. Typically these form the core source material for the Test Scripts.