December 13, 2008

Collaboration Advice For Distributed Teams

I got in a discussion the other day about the challenges of being a modder and working on a distributed team. Here are a few collaboration tips that have worked well for me, both on small mod teams and on large professional teams.

Synchronize your schedules

If you're having trouble getting a joint project done, schedule some time every night when everyone will try and meet up in person or virtually to work on the day's tasks. The amount you can get done when the other people are devoting their attention to the same problem is considerable.

I've been doing this a lot at work lately. Setting aside an afternoon to work alongside another designer, engineer, or artist means we can easily shoot files back and forth and iterate much more quickly and aren't blocking each other's progress. We've solved some very stubborn problems by getting an engineer, designer, and artist in front of the same machine for an hour, each making small tweaks until it works, then checking in all the files at once.

In an office, it can be very productive to get several people around one computer. Obviously you can't share the same computer with a remote team, but screen sharing and other tools can closely simulate that experience.

Know when you need to actually talk

There are some problems that take days to work out over email that could be solved in 5 minutes of face to face discussion, or over the phone. Learning to recognize these moments is an important skill.

Again, meeting up in person at a coffee shop or someone's place is a great way to make people accountable and get a lot done, as well as encourage much more bonding in the process. If you can't do that, try setting up everyone on a ventrillo server or at the very least a common chat room so you can all hear each other easily and not feel so isolated.

Working from home without a schedule takes a lot more discipline than showing up to work every morning and having a boss to tell you what to do, so team morale counts for a lot. This is also a great side effect of strategy #1: "It works! We did it!" is a great feeling that keeps you motivated to get even more work done.

Build a trusted team

Working together with the same person or people on several games or features is really valuable. You'll build team spirit, develop mutual respect, become very efficient, and develop a cohesive style. Collaborators who respect and trust each other are able to make up for each other's weaknesses, do better work faster, and ultimately enjoy their work more. This is very important for colocated teams, but possibly even more for distributed efforts.

But don't fear change

A good team may thrive on stability, but change promotes agility and individual growth. Since games, genres, teams, companies, and your abilities are constantly morphing, no two development environments are exactly the same.

There's a lot to learn about bringing new people onto an established team, coming onto an established team as the new person, working with different kinds of team structures, making games on different platforms, being a good boss, having a bad boss, having 10 bosses, etc.

Become comfortable in your situation, but don't cling to any situation. The game industry is a dynamic machine, and people who try to slow down the gears usually end up getting squashed between them instead.

Work on small, quick projects

You'll learn much more making 5 very fast games than half-finishing one slow one, and be more motivated. I designed 7 Sims 2 expansion packs in 3.5 years, and while those games weren't masterpieces, I went through every stage of development 7 times, while friends of mine shipped one game.

On such short cycles, I was forced to develop great instincts and learn to do things right the first time, and I became really efficient at preproduction, design docs, etc. Now I feel completely confident taking sinking my teeth into large MMO projects with much longer timelines. It's much easier to trust your decisions when you've seen them pay off several times in the past.

No comments: