Archives For scrum

A Simple Agile Game Design/Development Process

July 2, 2014 — 3 Comments

Usually when Agile is introduced to people it’s done so with Scrum which is seemingly filled with arcane terms and voodoo ritual. Very often the context behind those rituals and terms is lost and the general advice is to, “do it by the book,” until you understand, before you adapt it. There are a couple of problems with this. Firstly that the context Scrum was developed for might not fit the context you are making games in so rather than enabling you to move faster and make better games you are standing in a corner with your wizard hat on. Secondly Scrum as an introduction obscures some of the elegance behind the Agile Principles, concerned as it is with day-to-day process in service to that elegance.

So let’s cut back to the elegance. In yesterdays post I made a simple re-drafting of the Agile Manifesto to make sense of it for games design/development. Today I’m going to take those re-drafted principles and show how they fit into a simple Agile process.

First a diagram:

simple agile

That’s it. That’s the beating heart of Agile. So simple you can describe it in one sentence. Come up with an idea, make it and try it out to see what it’s like, then use your learning to refactor your idea and processes. So simple it gets repeatedly invented in an intuitive fashion. So simple I can retire this blog forever! Done!

Well not quite, we’ve only managed to deal with a few of the Agile Principles in this loop the rest involve what happens during each stage. Currently we’re hitting:

  • Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • A playable game is the primary measure of progress.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Ideate

We want to keep our ideas lightweight. Over-complicating our ideas too early means wasting a bunch of time both coming up with them and also implementing them. We’ll be refining our ideas over the course of many iterations so starting with a ‘perfect design’ is not going to help particularly as we have not yet managed to evaluate how perfect the design really is! The watch phrase some canny individual coined was “Just Barely Good Enough”.

Ideally we’re keeping these principles in mind:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.

Create

Creation is in many ways the ‘easy bit’ where we turn the idea into something playable. The main point to be aware of is that almost every task is going to require some Just-In-Time design. Having whiteboards (or a pad if you’re by yourself) handy is incredibly useful to quickly solve design problems. If you’re creating a videogame then this is also the time to make sure you’re refactoring the code your are working on to keep it simple, elegant and easy to work with. There are lots of ways to make this less painful but that’s outside of the scope of this post.

The principles to keep in mind are the same:

  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity–the art of maximizing the amount of work not done–is essential.

Evaluate

Evaluation means putting real people in front of your game and have them play it. Ideally you want the audience you intend to release the game to playing it as early as possible (or a close facsimile). At the very least you want some people that aren’t you playing the game to give criticism and feedback. Other developers can be good as they can excuse some of the rough edges of a product in development as well as being able to understand the ruleset and provide critique of the design. If you’re in a company then you’re probably going to have a list of stakeholders responsible for your project who should be playing every iteration and providing feedback. Other excellent although more time consuming methods include using Usability testing methods. For example doing some User Testing, a technique where you watch a players game session and take notes on friction points in the experience.

Schemes like alpha and beta testing, attending games shows, plus funding methods like Early Access also provide a host of willing playtesters. A caveat here is that the quality of the game experience does matter when showing something externally to large groups of people in a manner where there are quality expectations. First impressions count, word of mouth is important and it can be hard to dig a games name out of the toilet if every comment on articles about your game references how rubbish an early version was.

The end result should be a collated list of feedback and some action points to take into the next Ideation phase.

The principles being hit here are:

  • Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

The remainder of the principles deal with things like team composition, team management and day-to-day practices that are effective rather than process. They should be kept in mind at all times.

So why is Scrum so complicated?

Well it turns out as you start to use the above process a whole bunch of questions will routinely come up that need to be answered. Some can be answered by reading the Agile principles but others need a bit of cogitating on the best way to handle them.

For example how long should it take to move through the whole loop? According to the Agile Principles:

Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.

So we want to move through the loop pretty quickly, what if our idea is complicated? Well we’re going to have to cut the idea up into chunks we can implement and we’re going to need to work out roughly what order to do them in. But that means we won’t have the “full game” playable for some time? Well we should build a prototype first so we can get early feedback on our complete game design or we won’t worry too much and let the final design fall out in the wash as we receive feedback. Scrum basically provides a ready made solution to a lot of common problems that come up when trying to implement this elegant feedback loop.

Whether you pick an off-the-shelf solution or grow your own from simple beginnings the important thing to remember is that the entire process fails if you don’t keep up the virtuous feedback loop for both the game being made and the processes you use to make it.

In Agile, Game Design, Game Development, Prototyping , , , , , , , , , , , ,
permalink

On the Prevelance of Scrumbut in Game Teams

March 1, 2014 — 2 Comments

“Yeah, we’re doing Scrum but…”

Speak to nearly anyone in the games industry about their Agile implementation and this is what will come out of their mouths. It’s also a prevalent issue in Scrum adoption in other software creation industries. Leading to the term ‘Scrumbut’ being coined. It seems to signify, particularly in the long-term that a company has chosen to adopt Scrum, usually because they think it will fix some problem in the development process but has hit snags fitting their existing process into Scrum so they end up adapting the methodology they want to use rather than the process they want to fix. Then typically a project fails, the process is never fixed so the same problem rears its head and tears are shed. The collective take away often seems to be that Scrum didn’t work because it didn’t fix the problems. In reality it was the company or project that failed because they didn’t fix their own problems and saw/were sold Scrum as a magic bullet.

That said for any existing company and project there has to be a transition period between the previous way of working and the full adoption of a newly chosen Agile methodology. Many of the technical parts of Agile methodologies have a non-trivial amount of work to implement. For example setting up a continuous integration process and the suite of automated regression tests it runs. Further you can’t just bodge an existing set of processes into Agile methodology de jour and expect good results. Agile implementation is as much a reworking of culture as it is process. Any good Agilista will tell you we should be favoring people and interactions over processes and tools and the change in a companies working culture is probably the biggest impediment to changing process. In my experience this culture shift can’t just be a top down endeavour or a bottom up ‘revolution’ but something that is embraced at all levels and given adequate nurturing. This shift is ultimately about trust. Executives must be willing to let go of a strong command and control structure and developers ready to be open and honest about any problems they face so they can be addressed in a timely manner. The cultural shift to Agile also needs to extend to external partners/customers as working relationships will almost certainly need to change. For example you need a much more collaborative working relationship with your customer (but you know that it’s a tenant of Agile!) which for a lot of game developers means working closely with a publisher, a working relationship that doesn’t exactly have a reputation for trust in either direction! Everyone needs to have at least understood the Agile principles and what that means for their working relationship.

Some of this can result in some odd Catch-22s.

“We want to release more often but we don’t have confidence in the build, so we want to setup continuous integration, but we don’t have any regression tests, but we’re too busy working to ship the build to write them.”

Worse still there don’t appear to be ready, easy answers for how to transition any particular company or culture to any particular Agile methodology nor are there many/any games companies talking about how successful they have been. At best the advice seems to be ‘use this to fix your problems don’t expect them to magically disappear’.

In games the default methodology adopted appears to be Scrum which for a lot of reasons does not appear ideal to me for the totality of the lifecycle of a game. Games have distinct phases in their lifecycle, we don’t typically build out all the levels when the core gameplay is still being worked on extensively because it’s wasteful and we can look to Lean manufacturing to see some good discussion about why this is. Further some bits of game development like content creation which are much, much larger than in other software projects don’t really fit into the Scrum model. Games are very often boxed products or built as such and not sold as services so there needs to be a planning phase, however short and high level in order to set a clear vision, goals and build an initial product backlog. There are lots of fiddles like Sprint 0 added to Scrum to try to cope with these problems but to my mind Scrum needs to sit within a larger framework. Further Scrum doesn’t seem to scale very well beyond small teams and games projects are often huge in comparison to the ‘Scrum sweetspot’.

The really good news is that games development isn’t a unique snowflake in finding Scrum a bit lacking. In fact looking at data from the likes of the Ambysoft Surveys it’s easy to see that large teams in general are finding Agile adoption hard and that a lot of the barriers are very similar to the ones mentioned above. There are lots of other methodologies out there like Disciplined Agile Delivery that although not targeted towards quite the same projects as games try to deal with the larger complexity and team sizes found in enterprise IT projects. Whilst I don’t think they show the way out for games projects interested in Agile they definitely show the direction we should be looking towards.

In Agile, Game Development , , , , , ,
permalink

My Experience of Agile in Games Development

February 24, 2014 — 2 Comments

As a software developer I’ve always had an affinity for the Agile Manifesto. However as someone who has spent their professional life creating games products I know that the environment stymies many of the bigger principles involved. The purpose of this post is really to state my experience before I try to go on and talk further about Agile so those words can be set in context.

Previous jobs and other group projects had no or ad-hoc project management but my introduction to Agile “in practice” was actually intuitive. It occurred whilst I was working at Realtime Worlds and had finished APB and there was suddenly a decision vacuum from our project leaders about what exactly we should be working on next. Previous suggestions were in the vein of “go wide” with game districts themed around things like a zombie apocalypse or a “no-rules” districts (which was awesome fun). The state of the project was such that many of us were deeply unhappy with the core game prior to shipping but could do nothing about it because we were in heavy bug-fix and polish mode. The project was organised in classic functional silos myself on a Gameplay Programming team with other silos representing special engineering interests and disciplines. A core group of us spread across these teams really wanted to tighten up and juice the core experience. In the decision vacuum I pitched an idea to organise a cross-functional team working iteratively to improve the core game experience. We had a set of really good ideas formed from feedback about where the main pain points were and how to tackle them. We knew we wanted to move quickly but not too far with each iteration so we avoided unnecessary work. We also knew we needed to work closely in a collaborative relationship between developers. In short we accidentally formed our own ‘agile’ team. Sadly Realtime Worlds died soon after we released our first iteration so we didn’t learn some of the lessons about project management I’ve since come to appreciate but the core of what made us successful was the core of what makes Agile tick day to day for developers. Caring about the customer, creating something simple in a cross-functional team, tight collaboration and improving on things in an iterative fashion. The work we started was continued by GamersFirst who transformed APB into APB: Reloaded a pretty successful F2P shooter.

After Realtime went bust I moved to CCP Games to work on EVE Online. EVE itself a marvelously interesting product but I was also drawn to CCP because they used Scrum and were organised in a way that I thought was closely aligned to how I wanted to work. After three years here working in myriad teams on myriad things I can state that it’s reasonably true, we may still be doing Scrumbut however people are at least receptive to working improvements and the EVE project is pushing towards different way of working and has come far. One of the nice things we have is a fortnightly Agile Community of Practice which is not a cabal of senior managers deciding working practices from on high but a collection of interested developers from the project discussing Agile and how we can improve our working practices. This has lead to some interesting developments in working practices with some teams now running on one week sprint cadences (after their Scrum master gave a great evidence filled presentation on why they should), the questioning of our own general working practices, release practices and such like. Last week I chaired a discussion where we took each Agile principle and looked at our how well we as a project meet it. It was illuminating not only because different perspectives on our situation were shared but because it made me question some of the validity of the Agile principles (or at least their wording) to game development. Working here has definitely shown me is that Scrum is probably not the answer (but it might be part of it) to large scale projects for a whole load of reasons. Both topics for future posts.

An amazing amount of Agile literature and methodologies have been generated by the general IT community but very little has been game specific. Over the course of this blog I’d like to try to put together my own thoughts on the subject into something a bit more organised that goes beyond the usual siren call to “adopt it and see magic happen”. A colleague Rob Galanakis is already blogging about this sort of thing and is part inspiration for restarting a blogging effort.

In Agile, Game Development , , , , ,
permalink