Paper Burns: Game Design With Agile Methodologies gives a nice insight on the benefits of using SCRUM and other Agile methodologies to develop games. You can make games in weeks and months rather than quarters and years. After rereading a bit about the use of SCRUM at High Moon Studios, I was wondering how I could apply it to my own development. After all, I still don’t have Oracle’s Eye finished, and I started that project last August.
But like a lot of things I learn about, it seems to apply best to teams of people rather than individuals. In fact, I don’t think I’ve ever heard of techniques or methodologies for individuals to develop software, let alone games.
Are indie developers expected to just wing it with subpar techniques and figure out the best way themselves? Are we supposed to hire partners/coworkers in order to make decent progress? Or are there tried and true methods for single-person development teams? Pair programming is obviously out, but can’t other methodologies be tweaked a bit to provide a benefit for the lone wolf?
If you work alone, what tips do you have to share?
The first time I learned of Extreme Programming was when I was running a software company together with a friend. He introduced me to it and suggested we adopt some of the practices. As you say, pair programming is obviously out, even when you are with two, but there’s quite some other stuff that proved useful. On the technical side, we adopted unit testing. On the business side, we experimented with iterative design and development. Both proved useful. Today I’m a lone wolf again, but I still use much of the same practices I did when we were together. (Although I rarely use unit testing for game development.)
In other words, even though most methodologies won’t work for you without change, you can always adopt the parts that do and create a methodology of your own. In fact, I don’t think it works differently when you’re working in a team. I suspect it’s rare that a team can use a methodology without changing it to fit their situation. Extreme Programming even explicitly states: if a part of the methodology doesn’t work for you, change it.
Extreme programming - and probably other agile methods, too - has more to offer a lone developer than most other methods, because it is intended for smaller development teams to begin with.
One of the great things about being a lone developer is that you have a lot of flexibility. Large development methodologies like SDM, Prince II and - to a lesser extent - Unified Modeling all have a degree of bureaucracy because they need to deal with communication lines within the development team. For some of them, that’s the main problem to solve. As a lone developer, you don’t have that problem at all.
Left by William Willing on June 30th, 2006