Contents
Working as a Team
If you've managed to get this far you are doing well. You have managed to pull a team of people together to work on a mod. Your biggest problem now, apart from finishing the mod and getting people to play it, is keeping your team enthused and together.
Communicate!
Good communication is absoloutely key. The better you get on as a group of people, the stronger your team will be when things get tough. This is particularly important for mod teams as they are very rarely co-located.
Set up a fixed same time, same place meeting at least once a week, two or three times if you can manage it. These fixed meetings should be used to report progress and discuss the inevitable problems that crop up. Keeping these sorts of meetings short is a good idea, but make sure it's either over IRC or voice over IP. A forum is not a good place for a meeting.
If you have your meetings via IRC, make sure at least one person keeps a log of the meeting. That way agreements, actions, and changes to the mod are recorded. If someone doesn't have the log make sure it gets e-mailed to them.
IRC can be very "spammy". If you are having a meeting then show some restraint. Make sure that someone has finished "typing their piece" before leaping in with comments. While the team is fairly new, never ever insult someone, even if it's in jest. Written text is often mis-interpreted. Equally, if you think someone is having a dig at you, keep your fingers off the keyboard and let it pass. By all means follow up any problems you may have with an e-mail, but be restrained. Your "attacker" was most likely not intending to cause offence. As you get to know each other and develop some "trust" this will become less of an issue.
If you use Voice-over-IP (VoIP) to have your meetings, make sure you keep track of the discussions that occur, and make sure that a written record gets sent to everyone involved in the mod – even if they missed the meeting.
E-mail conversations should be avoided where possible. They are time consuming and very wasteful of resource. You will save yourself much pain and frustration if you simply organise an ad-hoc IRC or VoIP meeting. A discussion on a forum is to be preferred over an e-mail conversation.
Although forums are very poor for meetings they are great for posting meeting records, progress, and non time-critical questions and musings. Forums are well suited to the discussion of a non time-critical feature for the mod. If you do use a forum, make sure everyone on the team uses it. A dead development forum is pointless. If you have a question or idea that doesn't need an immediate answer then a forum is a better medium of communication than a bunch of e-mails flying backwards and forwards.
If you team members are going to be on-line at different times (because of differences in time zones) then a forum is generally a more practical medium for communication than IRC or VoIP. In this case team members that have a question about a specific problem they can post it on the forum in the knowledge that by the time they get back on-line the following day some sort of answer will be waiting for them.
It's well worth the teams effort to post little individual progress updates on how things are going. For example your coder might post an update to say that the primary fire for weapon X is finished. These small updates may seem somewhat pointless, but they indicate that progress is being made on the mod. There's nothing worse than working in a vacuum wondering if anyone else is working on the mod or whether it's just you. Lots of small updates can also provide an element of excitement as well as it indicates that things are being finished. One of the nicest things about the use of a forum is that you have the time and space to frame your thoughts in their entirety.
And finally a warning. If your team fails to communicate, it's already dead.
Some Things to Avoid
Do your level best to avoid adding features to the mod while you are writing it. New features and ideas are bound to occur to you as the mod develops. This is a natural and good thing. However, you should observe the following rules.
- Make sure that any changes to the current mod spec are agreed by all members of the team.
- Only add new features if you cannot defer them to a later release.
Many projects fail simply because the number of excellent features required grow faster than they can be written. When this happens the mod never gets finished.
Respect the other team members responsibilities. In other words, don't do their work for them. At best they'll appreciate the extra help. At worst you will be duplicating work they've already done and create bad feeling. The most likely outcome is that they'll be a bit annoyed that you've taken "some of their turf". There are very few reasons for ever picking up another team member's work and responsibilities.
- They have explicitly requested from help
- They have gone on holiday and know that you may pick up some of their work (because you asked first)
- They have quit the team (hopefully this won't happen).
And never ever tell another member how easy something is unless you know exactly what you're speaking of. And don't overestimate or underestimate someone. I know that's quite difficult but overestimating someone might put too much pressure on him/her and underestimating might give him the feeling of beeing unimportant or worse, he's thinking of you as a know-it-all.
Attitude is Everything
The team's attitude to the mod and each other is fundamental to the success of the mod. It is vitally important to attempt to be positive about the mod at all times. Especially in the later stages of the mod when the team will be sick of the site of it.
Be flexible with each other. Don't get hung up and stressed with a team member who requests a couple of weeks off. Everyone needs time to let their batteries recharge once in a while. Just because you can work non-stop for 20 hours a day every day for seven days a week doesn't mean everyone else can. Allow team members some real life. It will help keep the team healthy.
Don't be possessive about your particular set of responsibilities or deliverables. If you are a week late delivering something, don't get upset if the team asks if you need some help. Before you flatly refuse the offered help consider the offer carefully. It may be that you could actually use the help.
The team should try and share as much information with each other as possible. This provides the team with an excited buzz as all team members can see progress being made, and work happening. It also means that the team has the opportunity to spot problems and hitches in progress as soon as they start to appear. If you have more than one developer working within the team then at the very least the developers should walk each other through their code.
It's well worth putting some time into cross training each other. A team of generalists who have specific areas of expertise is in a much better position to survive the loss of a team member than a team of narrow skilled experts. Having team members cross train each other will not only bring the team closer together but provide an avenue for people to try things outside of their immediate area of expertise. Besides which, everyone likes learning new stuff.
Summary
- Communicate.
- Be flexible.
- Don't get possessive.
- Communicate.
- Respect other people's areas of responsibility.
- Share all information as much as possible.
- Consider cross training.
- Communicate.
Discussion
Mychaeel: I can not understand where that apparent antipathy against using forums for "team meetings" in the first paragraphs comes from. Actually, I'm much more disinclined to use IRC (shortlived, spammy, unstructured, unlinkable) or even Voice-over-IP (not even possible to keep a useful record). Forums, on the other hand, encourage thoughtful posting, structure, allow for posting additional media such as images, are searchable and are kept around for future referencing. – I'd like to have this matter discussed before changing anything about the text itself.
El Muerte TDS: there's also something like a mailig list. It's just not one or the other, using more tha one medium is often better, Forum\Mailing list\NNTP and IRC is a good combination. Sometimes you just fast responses. VoIP is juist chaotic for meetings.
EntropicLqd: If you don't like it change it. The reason I don't see a forum as being a good medium for a "meeting" is because it doesn't fit my concept of a meeting. To me a meeting is a short-lived and immediate discussion between two or more people about a particular subject. It's the word immediate in my definition that precludes the use of a forum for a meeting.
Mychaeel: EntropicLqd, I like to make changes an educated decision, so I like to have a discussion about what I feel needs a change. Otherwise I'd just change it. :-) – Why is "immediate" such an important thing? I don't see a mention of that term in the text above either; just a direct transition from "you must communicate" (which without any doubt is true) to "meeting" to "forums bad, IRC good." If that's not what the text means to express, it's at the very least misleading.
EntropicLqd: Immediacy is the very core of a meeting to my mind. That immediacy and "real time" response is what separates a "discussion" via a forum or e-mail (or whatever) from a "meeting". I'm treating them as two distinct concepts. So, because of my requirement on immediacy for a "meeting" it cannot take place effectively in a forum. Also, surely part of the requirement of a meeting is that all of the meeting members have to be present and able to communicate at the same time. Would you call our comments a meeting? No - because it's not. We are not "meeting" as such. We in a discussion with each point occuring at a distinct point in space. The text above starts with a discussion about meetings. You can't have a meeting in a forum - but you can have a discussion. The text certainly doesn't preclude the use of forums - and even encourages it in some cases. All it really says is that a forum is a bad place for a meeting - which to my mind is a true and valid statement.
- To be fair, when I wrote the page I simply threw down a bunch of stuff that seemed sensible based on experience gained in the work place. I've never been part of a mod team (there is no requirement for someone who can't even guarantee an hour a night) so my musings above could be complete rubbish. Looking at the page now it could probably do with some sub-headings splitting out the various forms of communication and discussing the things they are good for.
Mychaeel: In that case, I argue the importance of having a meeting to discuss things. The emphasis is on discussing things, and I think that forums are by far better suited for that than IRC or VoIP. Granted, it's a different matter if you actually can meet physically in real life – but meeting in person also opens the opportunity of using many more communication channels than just speech.
In conclusion, I'd like to have emphasis put on the important of discussing and communicating in a team by whichever means is best suited for it, but not necessarily of conducting meetings for that purpose. Different communication channels such as forums, IRC, VoIP can be mentioned with their respective advantages and disadvantages.
RegularX: On the FH Team we use group emails about 90% of the time, with emails usually 2-3 times a week. We catch up personally on AIM and IRC from time to time but with people across huge time differences and two continents, it's not really feasible (or necessary) to get everyone talking at once. Communication is key for both keeping everyone up to date with progress and also push the development along, but how that communication takes place is probably up to the team.
LegalAssassin: All of this text is good, and I think it's something all mods should follow (unless they do already). However, what happens when these basic "rules" are broken by a team member? IMO, the leader, if there's one, should make sure that the rulebreaker either sticks to th plan or is removed from the team. But what do you do when the leader refuses to do this, and, in example, makes drastic changes in the plan because one guy demands it and others already working by the basic plan? And what should you do if you love the mod and the plan, but the lead allows one member of the team call other members "cunt, dick, moron" etc? Also, if you are hired as a mapper, and instead you're doing something else full time in order to help the modellers make the models more accurate (per their request) - should you be considered useless/disposable?
These are rather tough questions, and to be honest I have tried to sort them out for months without getting it quite right (if the general opinion is what can be called "right"). Ideas? Thoughts?
EntropicLqd: Every book I've ever read on team-structure in IT states pretty much categroically that as soon as you get someone from the "dark-side" in a team you need to lose them fast unless you want the team to pretty much self-destruct - or at the very best their morale sucked out of them.
My own experience bears this reccomendation out. As soon as you get someone who thinks they are "God's gift", or someone who is just plain abusive - the team dynamic becomes very defensive. If that person is not removed then the team over time will become non-productive - spending more time putting defensive barriers in place than actually producing anything. If that person is not removed then you either live with the misery or leave. Once one or two people quit it normally opens the floodgates and the innefective leader is left with the prima-donna wondering where the hwll his team went.
In the "business world" it's a little easier to simply get up and go - the very nature of the IT business means that you don't have as much of yourself invested in the work. I turned down a job (along with a 20% pay-rise) once because I found out I was going to be working with someone I knew to be a member of the "dark-side" (having worked with them at a different job). It cost me money in the short-term but I'm 100% convinced that I was happier for it.
In the mod world you are creating something because its fun, using your own time. And that means that you have a lot of yourself invested in it. Walking out on that is very hard. If you can still offset the misery against the satisfaction of producing the mod then good luck. Its probably easier (and maybe more effective) to organise a mass "strike" until the offender is removed.
In my opinion abuse should not be tolerated. And if someone is that good then they should be trying to help out and pass on some knowledge. Not abusing the troops.
Legal: Yeah, what strikes me as odd is that this person is actually tolerated by other members of the team. In example, he's a mapper, and as he didn't like the skin of a weapon (which was superb) he decided he could do it better and sent the modeller a "corrected version", editing 50% of the weapon. The skinner "went back to work on it" (made the original version even a bit better) and put a FINAL-tag on it. The mapper sees it and goes on about what a useless skinner he is, as soon as he's not in the room that is. Once the lead is notified, he gets away with "don't do that". Still, from what I've heard, the team is supposed to be stable now. I have a rather high tolerance, but the way this person acts and talk shit about people once they leave the room, pretty much remakes the entire mod and makes sure members get fired/quit, I can't really take that. Several people left due to this situation, yet the lead considers this team member invaluable.
What's strange is that he's pretty average, not very good, though very fast. Of course, he's fast as he's allowed to do whatever unlike the other mappers, but still, he's really fast. Now, I don't see why a mapper would be so impossible to replace, but that's not to be discussed here.
The question is, what should I have done different? As you said, I put a lot of time into it, over 100 hours over the past six months doing careful research out of which around what I did in 4 hours was used since the plan was changed. So leaving wasn't much of an option. Any ideas would be nice...
Also, look at my personal page, I'll post something there too (unrelated, sort of).
Lilguy: What we've used for Apprehension (pretty effectively) is a combination of just about all these different forms of communications. We use Ventrilo (voip) when a few of us are working on a specific coding project or something, or we're testing the game and want to be able to talk about gamplay as we go. We use a mailing list (which I see as another form of forum) for discussing the major issues and answering questions. And on a personal level, we use instant messenger programs to discuss things one-on one, and when people are getting signed up initially.
One other form of communication that we've found critical is the versioning system (we use subversion, but cvs works too). This is sort of implicit communication, since you immediately see exactly what each member is contributing as he checks it in, and also the logs are a sort of progress update that can be searched at any time.
Lei-Get: Hello. I'm Lei-Get. I have to say that the best rule to follow is actually one that the Bible says to follow: "Treat other people the same way you want them to treat you." I think this is the most important rule in making a mod. The second being that, "all the team members should work for the same goal". And the third being, "stay as simple as possible." -June 9, 2007-