I've just discovered this gamedev.net article on how to manage indie teams and found it quite interesting. It mostly describes common pitfalls and how to avoid them.
Mason McCuskey wrote:
It's always a sad thing when a group goes down for the count, leaving only a half-baked demo that crashes on startup as the only reminder of their great game idea. It's too easy to say that every dead development team died because of "lack of dedication." There are many circumstances where all the dedication in the world won't help the situation. By carefully looking at my own experience with now-dead development teams (both amateur and professional – in my pro career I’ve worked on a couple of cancelled titles), I've come up with several ideas about why teams fail, and what can be done to prevent them from dying.
Of course there's always the slight hope that those are just the things happening to others, but I've seen quite a few of the described cases in teams I have been working with - not excluding myself. Tunnel Vision
seems especially infectious to programmers and I've seen a lot of I Can Do Anything in a Week
as well. I guess, one practical example of The Mutual Admiration Society
happened during the development of Nullpunkt
where the lack of early, focused testing resulted in a steep learning curve and difficult control scheme. It's not like one isn't able to spot the described issues - but rather that addressing them just comes too late.
Though, I'm still not sure about the point regarding game design documents - are they really necessary in small teams with lots of communication? I think it depends.