Rob recently wrote about Test-Driven Development, a lecture that will be given at the Game Developer's Conference (GDC) in 2006 from High Moon Studios. High Moon is also giving another talk about Agile Development and something called "scrum". Curious, I decided to take a look.
I'm with Rob when he says "I’m not one to chase after every new programming methodology that someone thinks up" but I have to make mention of this upcoming lecture. In the past, I had learned peripherally what "agile development" is in relation to "eXtreme Programming", but Wikipedia gives me a better idea what Agile Development and Scrum Management are. Scrum "has been documented to dramatically improve productivity in teams previously paralyzed by heavier methodologies".
There are many companies and industries that are indeed "paralyzed by heavier methodologies". The in-place process has been developed over the years (often decades) but the lengthy development cycle can occasionally get in the way of developing the product you intended at the start of the requirements or vision stage. Mind you, "agile" development and quick "sprint" cycles are probably not as effective in products and industries where deployment is not as simple as installing the new piece of software on a computer or updating a website and testing it out (think about industries like aerospace or manufacturing software or telecommunications infrastructure). Also, often times these heavier methodologies are put in place to counter the effects of having a global workforce where requirements, development, test and documentation teams are separated by oceans and timezones and cultures or where staff churn is high. Can you tell I speak from personal experience?
Nonetheless, I can definitely see merit in the idea behind agile development and "scrum" for many industries (like web development, desktop applications and games) because I've had personal experience in this on my hobby projects. See, I have a day job that takes up a good deal of my weekly day time and a family that takes up a good deal of the rest of my time. This leaves precious little time for my hobbies (like game development and web projects). As a result, maybe two years ago I started migrating from "big projects that never get done" to smaller projects with incremental updates that can be released “fully functional” and as often as possible. I first blogged about this here. This is exactly what people are calling "agile development" and the "scrum" management methodology but with the team size reduced to a size of one. It gives me a sense of validation that I stumbled upon this process on my own, but I guess this falls out of the fact that scrum/agile development just makes common sense in a lot of cases. So I'm proud to have common sense, I guess 😉
According to Wikipedia, scrum management is characterized by:
- A living backlog of prioritised work to be done;
- Completion of a largely fixed set of backlog items in a series of short iterations or sprints;
- A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.
- A brief planning session in which the backlog items for the sprint will be defined.
- A brief heartbeat retrospective, at which all team members reflect about the past sprint.
Another example: In the third quarter of 2005, there was a burst of activity from myself and Jeff Sinasac on our pet project Ten Nights of Killing and Mayhem. Sinasac and I had internally developed an ad hoc process where we put all bugs and enhancement ideas into an internal wiki with the bugs/enhancements prioritized. As we found them, we'd plunk them into the page immediately and try to prioritize them (showstoppers, high severity, low severity, enhancements/very low priority). Sometimes we'd have internal discussions in the wiki about certain bugs/ideas/concepts. Our "living backlog" grew long in quite a short time.
Then we'd go to work on fixing as many of the higher priority and simple low priority ones as possible and release a fully functional build (called "sprints" in scrum methodology), then strike off the bugs that we verify have been fixed. There's a very close match to our informal process and the scrum methodology so again, I get that satisfaction on stumbling onto this idea on our own. Again, common sense prevails, I guess.
You can see how the process sort of evolved from the Ten Nights Readme/History file. Build 48 is the first one mentioning a bug with an ID (from our internal backlog list). Between August 25th and September 6th, we released 6 builds culminating in 104 bug/enhancement fixes resulting in a much more stable game with some nice enhancements to game rules, graphics, sounds, etc. After that our personal/professional lives got in the way and we had to put our activity on hiatus, but this methodology allowed us to still have a functioning game available for users to download and play. We both agreed that using this methodology increased our effectiveness and really allowed us to focus on what we should be working on.
Anyway, I look forward to learning how others apply this common sense approach in the game industry and how effective it can be. One challenge I foresee could be that remote teams could make daily meetings less effective. This is a challenge primarily for management.
High Moon Studios seem to be making sure they are well-represented at the GDC in terms of the talks they are delivering with respect to software process and methodology.
I think one theme that I see arising from the XP practices that I’ve read about so far is that they rely on real dedication, interest and skills on the part of the participants. In other methodologies it’s easier to tiptoe around the fact that many people working on a project might not be very highly skilled or that most people see the project as just their job. Being just-a-job reduces enthusiasm and something like a daily heartbeat status meeting could quickly degrade into a bitch session for all the problems with a project.
In your examples, you’ve got a couple people who are enthusiastic and commited. It sounds like XP is a way to enable enthusiastic, commited people to work effectively. As for the unenthusiastic, uncommited and possibly unskilled… well, I guess the methodology’s not the root problem there.