Gamasutra has an interesting article about applying Agile software development methodology in game development. The argument is basically that the Waterfall model should be abandoned in favour of an adaptive Agile method called Scrum. Scrum requires more communication and collaboration, and rapid iterations in which functional versions of the software are released often – in general, it pretty much follows the Agile manifesto and seems suitable for game development.

On page two of the article, you can find a few diagrams over finished functionality versus time - the Waterfall method won’t show results until the very end, while Scrum’s functionality boost is primarily in the beginning of the project since it concentrates on making rapid releases with the most relevant elements first. I agree that the tendency is along these lines, but I think the author’s optimism is colouring things a little. Scrum relies on adaptation, so the functionality can go up and down depending on the decisions; and in fact, since the functional requirements change due to adaptation, the functionality axis can’t very well be displayed completely static, can it? The functionality becomes subjective since the goals change, unlike with the Waterfall method.

Don’t get me wrong: I’m not defending Waterfall thinking. If the requirements are static, it means either that

1. Someone has the hubris to think that they can define a project’s end result detailed enough from the beginning, or
2. The project will probably fail. It may be a de facto success, but still probably a de jure failure. (If we assume that the requirement specification is law – you’ll have to give me some poetic license.)

An interesting question was posed in a blog entry which also comments on the article above: are there software development methodologies that are applicable for individuals? At first glance I agree that there aren’t many that apply directly - development methods mostly concentrate on using resources optimally, and that is never really an issue for a one-person project. After all, a single person rarely finds himself waiting for himself to get done with that bloody document, or for himself to finish coding that damn module that’s needed for the next part. But one thing does spring to mind: rapid iterations!

I’m a firm believer in fully (or as good as) functional increments delivered in relatively rapid order. At work we are moving more and more toward rapid iterations in order to constantly have a stable base for testing. When I work on my hobby applications I try to specify many minor increments that span over a long time, since it helps me keeping focused. “1.0 will have this functionality… 1.1 will have encryptions on this part, and an improved user interface…” and so on. Of course with room for adaptability as well. Technically this may not be following either Scrum iterations or the Iterative method, but I find that specifying desired increments ensures that I don’t get side-tracked as much.

I guess I should have posted this bit as a comment to the blog entry above, but I’m not only a cynical bastard - I’m lazy as well.

This entry was posted on Friday, June 30th, 2006 at 1:24 pm and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.