Starting up a game business: Contemplating processes

This blog was originally published at blog.epic-owl.com.

As my third Epic Owl blog posting I would like to share my thoughts about software development processes. I know lots of people who are passionate about their processes and might not share all my views so this should be interesting.

I’ve been using iterative software development approach for games since 2001 and Scrum in many forms since 2007; in software development, games development and in something else entirely so I have a pretty good perspective on what works and what doesn’t.

This is not what this posting is about, though. It’s about the dangers of processes, what is important to consider about them and how to avoid pitfalls when using any given methodology. So here you are:

A process… The word has a negative clang to it. Yet, processes are necessary to accomplish just about anything a bit bigger. Definitely it’s impossible for a game team larger than a couple of people to make a game without following a process. So why be so negative?

Well, processes as such are dangerous animals. You need to be really careful with them. The old saying about fire, “Fire is a good servant but a poor master” applies perfectly to processes, but processes are even worse masters since with them it’s more difficult to realise something is wrong. Once you have a process in place, it’s easy to think you have things covered and can move on. Unfortunately, the world and the people around us keep changing so processes need constant iteration, tuning and revision.

Processes depend heavily on people and the teams using them. What works with one team doesn’t necessarily work with another. A big caveat with larger companies is that when they decide to adopt a methodology, they usually make the decision high up, train the good folks below on it and expect it to be followed from there on out. Doesn’t work that way. It takes a lot of effort to adapt the methodology to suit a team and the team’s purpose, figuring out what is the actual goal the team is trying to accomplish and how the new set of processes serve that purpose.

Fortunately startups and other small companies are naturally more agile so developing and adopting processes is easier. In the case of Epic Owl, we are one team working on one project. With limited dependencies we can keep adjusting our development process fairly frequently and be very effective with it.

Now that we have established that working without processes is impossible and working with them is difficult, let’s talk about software development. The relevant question is: what are we trying to achieve? High-quality software that serves its purpose, keeping the schedule and scope, efficiently utilising the resources we have? Balancing these is the purpose for the methodology we are imposing on the team.

So, Agile and Scrum? Surely it’s easy, just have your daily meetings, plannings and retrospectives and get on with it? Scrum’s key point is to give the ownership of the development to the development team from the team leads and managers and anything else is secondary. A team lead (scrum master) is there to make sure the process is followed, a product owner is there to prioritise features, but the team makes all the decisions on how they go about the development. Sounds easy? It is not. It takes lots of effort to get the team to accept the responsibility and even more effort for the team lead to give it away. I have seldom seen Scrum teams functioning 100% “properly” in this respect. “Properly” is in quotation marks since the definition of proper in this context is vague itself.

My one advice above all is to keep your feet on the ground and use your common sense in all situations. No methodology is perfect, there is no silver bullet and no matter what you do, your game doesn’t make itself.

To conclude, here’s a short checklist on how I feel one should go about facilitating a new process or methodology and how to start working on a development process with your team.

Get first-hand experience on as many methodologies as possible. Every single one has aspects you can use and most of them are contradicting each other. This gives you perspective to mold and adapt the methodologies for your use. Figure out the very core of the methodology and build from there, take what works, discard what doesn’t.
Clarify the single most important goal of your team and write it down. Write also down a few secondary goals. The process you work with can’t work in contradiction to these.
Get to know your team and the processes they have been using earlier. You get valuable feedback and suggestions from them.
Never force a process on your team; work together to achieve the process everybody is comfortable with.
Never do anything just because it’s the process. If you don’t understand the purpose, odds are it doesn’t make sense to have it as a part of your process.
Double-check your goals every once in a while and make sure your process still works towards them.
Don’t be afraid to iterate on your processes and test new things. Bear in mind, though, that this is additional stress to the development team and there is a cost in all the testing you do. In longer term it does pay off since your process gets better and better.