Someone can correct me on this but I feel like formal specification and games is an oxymoron. Does anyone actually do alot of formal process and design? I'm talking UML diagrams, several rounds of testing, etc.

Scrum and agile development seem to show up in alot of discussions about this. I've never used them though, perhaps other have?

I'm currently in the middle of the fourth iteration (two weeks each) working on an independent project. Our agile process could be described as 'mostly XP with some Scrum and a little common sense.' So far, we're all really enjoying it and the game is coming along very well. Much better than other games we've done following a more traditional waterfall methodology. A few things are starting to come up though...

1) Because the 'team' is five programmers, and no artists, we don't have any content creators actively participating in our iterations. They are all treated as 'outsourced' content generators. Unfortunately, our planning games have focused quite heavily on gameplay features and the programming side of things. We have been keeping content further on the horizon because we don't have immediate control over it. We've paused the current sequence of stories to nail down the assets and get the final ones in the game. And, of course, the real killer is that all our content creators are volunteers. We haven't had the best luck with people coming through on content.

2) Due to, perhaps over application of, 'You ain't Gonna Need it', we've accumulated a lot of gameplay functionality that has been pushed to the side because we don't have assets to actually finalize the behavior with. Using placeholder content only goes so far. Again, to address this, we are now taking an iteration to nail all this down.

3) A few times people have finished all of their tasks and been unable to jump on and help other people in a significant way. Most of the time it's because the remaining tasks are trivial, or in the process of being completed. When pair programming can be done to speed up the process, that's what we do. But, because the "system architect" is also the "coach", it's been very difficult to pause the workload to do a quick planning game for the completed programmer.

4) Having satisfactory unit tests has caused some frustration. There have been many instances where a bug would be discovered and that subsystem didn't have thorough unit tests, so the only way to "fix" it is to use the game as the test. I don't particularly like this. Although, I have run into situations where it is significantly easier to test something by just using the game as a test, as opposed to writing an automated unit test. In particular, all our "game specific code" has no automated test. We just use the game (which, as of now, is rather small so it's not difficult to do a thorough test -- this will scale terribly though). In addition, I've been unable to convince everyone on the team that taking the extra effort to write unit tests for everything is a worthwhile practice, including myself. This is partially because we started with a large codebase that did not have automated unit tests. We try to write automated tests whenever we add new functionality. In practice, this happens less than it should.

So those are things that come to mind immediately. Don't take these as reasons to not use an agile process. Even though these issues exist, with a professional art team -- or at least a dedicated one -- many of these problems would have disappeared. I will give one caveat: the team must be strong and get along well. A few times people have brought up some issues that could arguably result in fist fights. But because they were done in a professional and polite manner, we were able to address the issues and move past them. By being completely open with each other we have overcome a lot of significant obstacles.

I believe someone once said something like "What's important is the people, not the process. Poor people with a good process will do poorly. Great people with a poor process will do well. Great people with a good process will do incredibly well."

So, to directly answer your question. Our form of documentation is very lightweight. Our documentation process is pretty much what Mike Cohn describes in "User Stories Applied." We've detoured from that to more traditional documentation for our assets, because of the previously mentioned reasons. So far, we've found the whole "user stories and tasks on notecards" to work incredibly well, and I highly recommend it.

As far as UML diagrams and system specifications go, we use UML to do quick design bursts on a white board or piece of paper. Occasionally we write it down. There is also a very rough system spec. The system architect has the whole vision in his head, and everyone else has a detailed view into the various sections they've worked in, along with a good idea of how it all works together. We are very open with asking and answering questions, so if anything comes up it is immediately resolved. Now, the problems with this is if the system architect gets injured or something along those lines. There is another programmer on the team who is about as familiar with the framework as the architect. It's important that the architect and his "backup" be very strong software enginners, not just 'programmers'. If no one is particularly strong in the "Software engineering" dept., I recommend some additional formal documentation.

Also, something which just came to mind is that if the team has trust issues, you absolutely cannot rely soley on informal documentation. Otherwise you'll end up debating the same issues, over and over, time after time, and never get anywhere. Fortunately, everyone on my team has known eachother for almost two years now, and are all awesome people. So we don't have this issue.

Good luck.