Someone suggested that an article on teamwork would be useful, so I'm writing one now (Note that this isn't an article on project management, that one will come next year, once I have more experience)

Teamwork is a great way to get things done. In fact, I like teamwork so much that all my latest games were team projects. I'm proud of my team. In fact, I'd be happy to accept people who'd want to join my team

Teamwork is good because you can do things outside your skill level because someone else is doing them for you. It helps you assign tasks which you'd rather not do to someone who'd rather do them. Some people would say that it lowers the time it takes, which brings me to my first point.


Communication
Communication is the main delaying factor in teamwork. You have to communicate to assign tasks, get feedback, etc. In an office, it's easy. You just walk up to your colleague and talk to them. On the Internet, it's much, much harder - you can't just call up someone or talk about your game when you're having lunch with them.

Here, I'll use a term I call a communication line. When you send a single e-mail and get a reply, it's a communication line. With a chat or conversation, it's usually line, but there's a much shorter response time. With 3 people, you need 2 lines? Not exactly. I'll explain later

You should also take note of response time. For a chat or real-life conversation, you have a response time of only a few seconds. With e-mails, it's an hour at best, if the other guy has a Blackberry. Normally, it's a day, much longer if the person you're communicating with has a poor Internet connection.

So, one reply from one person takes a day or two. Discussing things about what sprites should look like would take half a week! That's assuming they're motivated and checking their e-mail every day. Sometimes you have to wait for a response from one person before replying to another, which doubles that time. If you want to be really diplomatic, everyone has to listen to everyone else!


Direct communication
This means e-mail or chat. You communicate them directly - no group meetings. It's great for groups of two, but well.. let's look at the following formula.

For direct communication,
Communication lines = n(n-1)/2

In plain English, it means that if you have 2 people, you need 1 line. If you have 5 people, you need 5*4/2 lines. With 10 people, it's 45 lines! Which is why you need a better way.


Manager
A manager is one who assigns all the tasks. Normally it's the leader/director. Most big teams form into this category at first, with the leader giving orders to everyone and cc-ing the email to everyone else.

For teams with a taskmaster,
Communication lines needed = (n-1)

It's much easier with a big team here! A group of 10 people needs only 9 lines. But there's one big drawback... if the taskmaster quits the project (a common problem in indie teams), everyone loses contact with each other.


Forum and chat/IM
The leading technology in indie teams is sadly, forums and chat rooms. Here, the forum takes the role of taskmaster. The communication lines needed here is the same as with the taskmaster form.

If you're lucky enough to be awake at the same time as your teammates, you can chat with them and drastically reduce the response time. Until someone figures out a better way, all major online team projects should be done on a forum!


Team roles
One thing about indie game makers is that they love to follow what the pros do. Since the pros have roles, most indie gamers also like having the same roles, just for the sake of it. However, with indie games, roles will usualy overlap (for instance, the lead programmer may also be a supporting artist, and the lead artist could also be a level designer). Because of the crazy communication problem, it's often easier that way, rather than getting several people to each do one thing.

Anyway, here's my comments on the most common roles.

Game Designer
The designer should be the leader and director, because the game is his/her vision. But remember - There can only be one lead designer! It is better to have 1 bad leader than 2 good ones. I assure you, you can never release a good game with more than one leader.

However, there is space for assistant game designers. These guys normally do minor grunt work like calculating design stuff, thinking up new enemies, new items, that sort of thing. The lead designer has the final say whether or not it should be in.

Programmer/Coder
The programmer has a hold on the engines and technical bits. Seeing how most indie gamers write code, this is best to kept to one coder per engine. If more than one coder works on an engine, it's well.. impossible due to communication response times and such.

Artists
I group all graphics, music, etc under 'art' as they have to merge together to produce something of art.. it's a common mistake to have music and graphics made separately, which don't suit each other in the end. I could write more detail on getting art to work together, but I'm sure there are a lot of people doing that. I'll just say that you should make sure that the artists' style matches each other. This applies also for music! If you listen to most soundtracks, you'll find that they don't work well by their own, but are great when in the game.

Background filler
Here, I group anything that are fillers for the game, like level designers, character designers, and storylines. Often you can have as many of them as you like. Heck, you could even write up a level editor and let them do it if you want. Note that I don't group it under game design.. it's a minor role, easy to replace.

Beta testers
Most people hire anyone to beta test their game because they want to see what the common person thinks. There's one small problem with that - the common person has no idea what game making is like, so they'll give unreasonable suggestions like make it 3d or this thing is ugly, replace it with something from Naruto because naruto is cool.

It's usually a good idea to get someone who's also a fellow game maker to beta test. Also, keep in mind that you shouldn't follow every request - 90-95% of suggestions actually hurt your game. If you're a good enough designer, you should have figured out the problems from most of the angles. But the 5-10% of useful suggestions are usually from the points that you didn't think of; skilled beta testers will help you find them.


Characteristics of Team Excellence
Leadership books are mostly theoretical and cover common sense, but I believe these characteristics as studied by Larson and LaFasto (1989) explain it all. Northouse puts it into 3 pages of detail, which I've simplified as follows.

Clear Elevating Goal
All teams need a clear goal. Give them a vague one and they will fail. Also, make sure it's motivating enough for members to really focus on it. Competitions are good for this

Results-Driven Structure
Basically, you need to find the best team structure to achieve your goals. Long story short, the best way is to make sure everyone knows what they are supposed to do. Be sure that everyone's roles suit the results.

Competent team members
Obvious, lol. The main point here is not to worry about technical competence. It's making sure that your team members have enough teamwork skills to work with anyone else. Sometimes you end up hiring out a guy who prefers to work solo - in that case, don't force him to share his workload with others; that's outside his area of competence. If he's an artist, let him do all the art. Just make sure he doesn't quit in the middle of the project.

Unified commitment
The team needs to be treated as a team, not as a bunch of different individuals, i.e. treat tasks as things that have to be handled overall as a team, not by any single individual.

Collaborative Climate
Basically, the group has to feel like they can help each other. That means that the causes of team failure may reside not only in member inability, but also in their collective failure to coordinate and synchronize their individual contributions. (Zaccaro et al., 2001, p. 451)

Standards of Excellence
Don't tolerate bad work from members just because you want to spare their feelings. It's best to give them positive criticism and tell them what needs to be improved, or whether it's not good enough to fit in the rest of the game. Not keeping up standards might be fine for the person who did the poor quality work, but it hurts the morale of the rest of the team.

External Support and Recognition
An important point. Here, your external support is your fan base (when you get one). Also, it's important to make sure you have the resources you need to make your game. With indie games, it's usually motivation, money, and tools. Teems need to have enough to accomplish their goals and be praised for doing a good job. A fan base will help out with this; try to advertise your game a little - post a demo, write a devlog/project page, discuss your game with others until they feel interested in it. Don't restrict your fan base to just The Daily Click!

Principled Leadership
Yeah. I'm sure you guys are good leaders anyway, so I'll leave it to you guys to figure out the 3 pages I'm too lazy to retype.





Permanent Teams
See that big line break there? That means that I'm just going into the real guts of this article - permanent teams. It's one thing to make one team to finish one game. But after a while, you'll find that some team members are worth keeping in the long run. Thus, why groups like Silvernova, A-coders, and FAInd exist. I'll be taking some examples from my own group, Abstract Soup.


Mood
Whether you're starting a group or joining one, the first thing you have to consider is the general mood (culture) of the group. Most groups tend to take on a particular mood. Some groups simply hire out any decent klikers they find. A few are dedicated to making famous games and spend some extra time on hype and presentation. Some prefer to write extensions and demos. There are some who enjoy making violent, sinister looking games. Some have a particular art style, which members tend to follow.

Abstract Soup's general mood is, as the name implies, a collection of many different type of non-conventional games by different people. It was once partly intended as an 'adventurer group' hunting down competitions, but evolved into more of a permanent team.


Leadership
There are quite a lot of teams which seem to try to avoid leadership, but it ends up with a leader anyway. Abstract Soup started off declaring that there were no leaders, but somehow, it ended up having a few unofficial leaders.

Does the team need a leader?
Indeed, we would argue that effective leadership processes represent perhaps the most critical factor in the success of organizational teams (Zaccaro, Rittman, & Marks, 2001, p. 452)

Like it or not, all change requires leadership. You can't simply have a goal and hope that someone else does it. Someone will end up leading everyone to achieve that goal. But no, there's usually no reason to elect a leader, usually someone will volunteer for the post whether he realizes it or not.

Who makes the best leader
Often someone will elect himself to be the leader. Don't be mistaken, the designer is usually the architect of the game, not always the director! Don't worry about it too much, leadership skills tend to show and all you need is someone who can distribute tasks. If it's a different person from the game designer, the designer just has to make sure the leader keeps the game on track.

What does a leader do?
I've got about 30 pages next to me on leadership models and stuff. Looong story short, it's about making decisions and making them well.

How many leaders do I need?
You can have a few leaders - in fact you will. Most people will be making decisions by themselves, especially with the communication problem.

But remember one thing, when it comes to making decisions and assigning tasks, be sure who you'll follow. If one person says go left, the other says go right, everyone gets confused. This is very important! A lot of teams have been killed off because of leadership issues!


Goals
Here's where more indie game teams miss out on. Many teams have a lot of very skilled people, they don't really do anything with them! Most of the time, they hope that a member releases something good and slaps the team logo on it. That way, the whole team gets a little prestige.

It's not really a bad thing. But it's a waste to have all those people but not use all that talent! What Abstract Soup does is that we discuss ideas and decide whether or not to launch ahead with it. Sometimes an idea is good enough it that everyone gets crazily motivated about it. Most ideas won't make the cut, and a few are good enough, but are left aside until they somehow fit the requirements for a contest and such.

It's good to set a goal for your team. It's fun and gives everyone a chance to do something together with other group members.


Strategy
Once you do have a goal, you need a strategy to achieve it. There are many, many ways of approaching a project; I'll write an article with more specifics next year. Overall, you need to make sure you get all the parts built right. A nice way would be to make all the needed engines, work them into smaller games, and then recycle or upgrade them into a bigger game.

That's why it's sometimes good to have an supergame in the queue. You'll have a long-term goal to work for but not stress the team on how to achieve it. And once you do get your supergame functional... well, let's just say that some supergames get $2000 on donations a month. Donations, not sales.

Uh huh, it's an ideal goal, but hey, what's more fun than having a hobby with 300 posts/day in your game's forums and making a bit of money on the side?


Self-preservation
One very important factor that a few teams forget is self-preservation. It needs to have a way to keep itself alive. Some teams die out from a lack of members - for that, it's important to keep hiring (and training) a few new members. Many groups die from inactivity. A few actually suffer from overwork. And you always have to count the members who'll leave your group because they don't like the whole mood of the group.

If you're going to start a group for the long term, remember that you'll have to put some time into keeping it alive.


Training
Training in indie games is fairly simple, but most people neglect it. There are many things you could improve, but perhaps the most important in training is teamwork.

At its most basic, you can just encourage people to build up smaller games. If you want to do be more direct with it, you can try to make a little game where everyone submits something. I've learned a bit from those, but it's hard to get people in on it. It's a good exercise in co-ordination, though. An obvious way is to make games together. Here, you'll get some practical experience as well as a lot of exercise in teamwork.

For skills training, a simple way is to write articles, make some game engines or sprites. A more advanced way is to try to actually teach skills to your team members, similar to the style Klik Academy used to operate. Teaching skills tends to really improve them, and much faster than making games.

Just be sure not to over-train people. Remember, that making games is a hobby to most people and overworking them will make some of them unhappy.