Production FTW

Here at the Abbey we achieve greatness with our customized development method. When we applied this super awesome development method, our production efforts doubled, NO TRIPLED! Quadrupled?..

tl;dr: Scrum but not really. Team divided in two; production and pre-production. It works great for us.

We work loosely according to the Scrum development method.  I say loosely because we do not use all of the nifty ‘rules’ of true scrum development. Our development model is different but in essence it’s really quite simple. Our Scrum like model relies on one very simple rule: “Playtesting moves production further”. We think playtests are the fundamental building blocks of creating a game. When doing a playtest you can test whether the features you added since the last playtest work and also what could be better. It’s basically a point of reflection on the development process so far. Still, there has to be something to test. This is where Scrum comes in.

A sprint is the basic unit of development in Scrum. Our sprints last exactly two weeks. We start our sprint with a meeting in which we determine what exactly we want to playtest at the end of the sprint (friday-playtest-day). We write this down in one or two sentences on our wall of pure awesomeness (also known as a whiteboard) so we don’t lose focus half way during the sprint. Then we create post-its with all of the tasks to implement all the features required for the playtest. And that’s it! We are done! Seriously? Yes! Really? No.

After a few weeks of development (when we were just monks in training) we realized that half of the team was working with a ‘pre-production’ mind and the other half had a ‘production’ mindset. We hadn’t implemented all of the features for our amazing game yet and our game designer was working overtime to design the entire game (Pre-production-work). At the same time the developers and artists where pimping the features that had already been (or had just been) implemented (which is production-work) so our playtesters had an amazing experience. This worked rather poorly because our programmers (including me) where not busy creating the game but rather styling something that wasn’t finished yet. It’s like polishing an apple that is still hanging from the tree just being pretty and all. It looks jummy omnom, but you can’t eat it! It just didn’t make sense.

We thought long and hard about the problem, and we decided that we didn’t want to make changes to what we were producing. We still want to give our playtesters a feeling of awe but we didn’t  want this to go at the cost of the overall development of the game. We realized that the problem wasn’t the way we worked, but more a problem of work distribution. We have to keep pushing the implementation of new features so we can go full on production as soon as possible, but we also have to keep our code-base clean and still give the playtesters something nice to play with.

We solved this by reorganizing our team structure. Basically we have a production team and a pre-production team. We switched one of the programmers (we have 2) from the production team to the pre-production team. He basically hacks functionalities into the game and the production programmer (moi) cleans up his code and kinda polishes the feature. You may ask what exactly we achieved with this cause it seems we are actually doing more work. That’s not true, because as soon as the feature kinda works, the game designer is able to test and tweak the feature until he drops dead. Then, once he is satisfied with the result, production can take over, pimp the living shit out of it, and voila the feature is done. Not really though, cause there are probably a lot more iterations but the effect is that our game designer is now able to tweak has creations in a much earlier stage.

 

 

Another very important aspect of Scrum is the Daily Scrum. During this short meeting we explicitly state what everyone is working on. This allows us to spot problems way ahead of time, decreases communication problems within the team and allows us to review things we didn’t think of earlier (during the planning meeting for instance).

Then after two weeks comes the almighty friday-playtest-day. On this day playtesters come to our office and our game-designers closely watch them play the game. During that time they write down everything (really, everything) they can think of that could be better or shouldn’t be there at all. At the end of the day we all sit together and review the work that we did (or didn’t do) during that sprint.With the information we gathered during the playtest and during the review meeting, we start another sprint the next monday.

 

 

I will not say that this is the best development method there is, but it works really well for us. However, you may know more about development methods than I do. In that case, advise is always welcome in the comments!   🙂

Cheers

Bas