During my recent talk at the Develop Conference, someone asked me how we approach project management, particularly what methodologies we use and specifically the parts relating to iteration.
This got me thinking about my opinion on agile and waterfall project management methodologies, the two most commonly discussed and used in games.
Agile has become something of a buzzword in the game industry in recent years, largely because it allows for iteration and does not require full design upfront. Before agile was adopted by the game industry, waterfall was a more usual management method but has caused many development problems over the years.
Its structure is rigid and does not allow for changes to design and it directly assumes you know exactly what you are building before you start. Whilst that may work well with more application driven software, it is nearly impossible to implement correctly in game design, where you can’t, and shouldn’t, try to know every detail before you start.
I’ve worked on a lot of games over the last six years. Most of them on the smaller end of the scale, with two-to-six month development cycles, but I have also worked on a number of projects with up to 12-month development periods. This includes games of different technologies, genres and feature sets, with varied team sizes, all presenting unique challenges. Most of the work I have done has been work-for-hire, and those projects have ranged from very open briefs with the design, timelines and budgets defined by us, to fixed briefs where we implement what we are asked to.
Throughout this, we tried many different approaches to project management, learning about agile and waterfall in particular. My conclusion through all of this is that:
a) There is no right or wrong answer, different projects and teams need different solutions, and:
b) Whatever is right for you is probably a mixture between various methodologies, and following any one precisely is going to lead to processes for processes sake.
The right solution really does depend on the project. For example, when a client comes to you with a brief, they will usually want to know (and reasonably so) a fair amount of information, e.g. what features it will have, timescale, what you will deliver and what it will cost.
If you decide to follow a purely agile process, you will at best only be able to provide two of these. Either you commit to a timescale and cost, but not what it will include, or you could commit to what the game will be, but not have an answer when it comes to the timescale or cost. If you are lucky enough to get a client who is happy to work on this basis, that’s great, we had it happen once in 40 projects.
In most client projects, you need to commit to a feature set, a deadline and a budget. Therefore, you could revert to a pure waterfall method – but we all know the risks that this entails, not producing a game that is fun, even if it meets the brief.
Compare this to developing your own IP. You probably have some boundaries, maybe you have a fixed amount of money, or you know you need to release the game by a certain point, and hopefully, you know what you want to achieve, but not every detail. This is a lot more conducive to an agile approach, but what if your team is three people – do you really need to follow the methodology processes to the letter or will you then spend more time project managing than actually developing the game?
Consider a two month development cycle on a small game – if you do two week sprints, how can you actually get a game done in that time period? If you have six months on the other hand, you can probably be confident of delivering something through a more agile process.
Another defining factor when deciding on a management method is your team. If you have a team of industry veterans, led by management who are there solely to manage the process, an agile type approach could well be preferable, because the team members can manage themselves relatively well, and have the backup of the managers to track progress. You will still have a large budget to manage, which can easily spiral out of control.
Compare that to a team of mostly inexperienced developers or graduates, in a small start-up with management who wear ten different hats a day. Can that team really support a truly agile process and deliver effectively?
Lastly, I feel it is important to mention the large number of software tools available to help you with your development; they range from the very simple such as Trello, to extremely comprehensive systems like Hansoft. Software is only really there to aid with your process and should not in any way define it, once you have decided on your method; you simply find the right software or solution to best support it. The right way for you could even be as simple as post-it notes on a board.
We tried a great deal over the years, and no single one was perfect. It's very important not to get hung up on the tools, use them to support what you are doing already. Keeping it as simple as possible is often more beneficial than a needlessly complex system.
My belief therefore is that a mixture between methodologies and finding what works for you is the best approach. Do not feel that you have to follow anyone else’s process. Learn about them, understand their benefits, adapt the ideas and then take those and create a process which works best for you and your team.
Your process may vary slightly per project, and I’m sure it will evolve and improve over time but this will come often from making mistakes as much as making good choices.
Ella Romanos is a consultant on commercial development, design and production for games, and commercial director of Strike Gamelabs. www.ellaromanos.com/@ella_romanos, http://ift.tt/1qqcONC/@strikegamelabs
By
Develop FeedRead it
the full article here
