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.
I’m still relatively new to agile, but I’m very interest in your Agile Community of Practice meetings. How do they work? How does a typical meeting go? Or maybe you could point me to some further reading. Enjoyed the post.
Sure, the idea of a Community of Practice is to facilitate sharing knowledge and best practices across various teams in a specific area. Basically it’s a method to keep people on the same page on a subject between cross-functional teams which can be lost in a move from functional silos. For example we have Communities for Python, Agile, People Management and the like. How they are run is up to the Community organizer in our case but usually it’s a topic for discussion they choose, a presentation or something another person has bought to the table. Everyone’s involved and attendance is usually by interest rather than gated by specialisation. Although some of ours are limited to people with a direct interest, for example People Management is only attended by our people managers AFAIK.
There’s a fair bit written on them but the concept is very straightforward.