June 2019. How can I use Agile methodologies to deliver better and faster with my planned update on Find the Gnome?
It is a question that is bothering me for some time now.
This is an article in the ‘Research’ category where I dive into a subject on game production.
Update: as of June 2021 I have released an updated version on how I look at iterative development. This article was written when I didn’t actually know that much about the actual state of the industry, and thus fail to address the real issues. See the updated article for a much more nuanced and helpful take on this subject. I think this article still does address some real issues though, but a lot of it is already know to the industry and can be fixed by reading the book ‘Agile game development with Scrum’ by ‘Clinton Keith’ (2010).
The things at hand
How is the industry currently using Agile methodologies? This questions could send me on the right path to find practices how to deliver better and faster with my planned updates on Find the Gnome.
When I look at developing games from a birds-eye perspective, I see the following area’s where Agile development could have its impacts:
- Business: Production methods, payment/evaluative structures
- Management: Delegating responsibilities, building on trust
- Daily work: Planning and executing on work
- Production: Executive team priviliges, Team-only driven improvements, Full-product deliveries after (a few) iterations, Course alignments on real consumer data only. (Inspect & Adapt)
Point 1 is a hard one. Companies are most of the time prohibited from sharing financial data, so finding info on this is hard. Production methods is a not-so-sexy part of game development so that’s another subject you don’t read that much on.
The funny part is, you can derive this information very easily from decisions made. Most companies in the industry are financially in business to business contracts with upfront payment structures and/or revenue shares. Production methods are most of the time ‘Pitch, pre-production, production, alpha/beta, release’.
There is very little Agile methodology here. But that isn’t that much different from other software industries, because it is very hard to steer on results and expenses with the current Agile practices.
Point 2 is a bit more difficult as it seems. This delegating/responsibility thing (and most of the times, combined with true multi-disciplinary teams) takes already place in the smaller game companies. For larger companies though it is really difficult to get away from the line thinking, because due to the scale of the organization the money and legal things tend to be too concerning to let them being handled by individual teams.
However, I’m seeing signs of change too. Due to the huge amount of pressure to innovate. But they are still doing it ‘differently’ from the small companies because in companies that large there are KPI’s, organizational guidelines and other steering tools that are introduced to keep things in line.
For point 3, I think everyone is already on board. Across all industries we know the iterative approach in daily work is a more manageable way to execute on work. I had trouble finding evidence that game studio’s are on-board too, but I recently saw this YouTube video from a big studio that confirms my thoughts on this (link below). Talking with game devvers on Dutch meetings further confirmed it, most studio’s are doing a form of Scrum.
I think there is something left to argue about: using Scrum can make you Agile but that isn’t a guarantee.
Point 4 is where the icing on the cake is. Because this is where currently companies are making the difference. In this area of Agile, the bosses aren’t the ones leading but facilitating (and don’t like being called ‘the boss’). It is this area where you aren’t an expert when you have idea’s but you are an expert only when you are able to execute on proven demands from consumers, or when you are data-proven able to forecast real consumer demands.
It is very hard to get this down in gaming, because production with the current practices of pipelines and content creation don’t facilitate easy/cheap changes down the road or facilitate working incremental product delivery to users.
Most of the companies doing this kind of (business) development are in mobile because the environment natively supports working like this.
Ok… so… how to do Agile on FtG?
To succeed on my own game development projects, I have to think big when maximizing benefits from my experience as software developer in business software.
So, I think I have to go with the maximal Agility on my own projects. Inspired by the Gram Games YouTube video I think it will look like this:
- Keep releasing full products at Steam at low intervals
- Release features stand-alone to mobile platforms
- Move winning features from the mobile platforms to the full product release on Steam
The release-feature-to-mobile-first is the core idea, and here is some more depth to it:
- 1-3 iterations
- Real stand-alone gameplay
- Full of metrics (but AVG compliant: I don’t need user specific data, only the global feeling)
- No monitization
- When 10 people use it 7+ days it is a win for me
Do I think I am right by choosing such a strange method?
Well, I can only think of 1 real cave-eat
- It is really hard to separate features and prove their individual value
But other than that, I think It is worth the try.
The video on a recent (2019) big company (Total War series, 550 people) that are doing some Agile form of planning and executing on work:
The video on a recent (2019) small company (Mobile games, 20 people) that are doing maximum Agile:
Update on January 2020: I was at the Amsterdam White Nights convention and attended to the talk ‘Defining the MVP’ from Tatiana at Etermax. They have this practice I propose and fine-tuned it. So it is definitely worth looking into.