Best way to run a small programming team?

Question

I'm in an interesting situation at the moment, I managed to convince a few people from university to spend the summer holiday building a game with me - leaving me mostly in charge of a team of people, all of whom are fairly good programmers but none of whom have any experience working in a programming team (this includes myself). Even better, all the programmers have moved out of uni accommodation over the summer, so we're spread across the country with only online communication!

At the moment the team is using a very much "cowboy coding" approach, I hand out a specification for a part of the game, they go off and develop it, we all review the code in our own time (everyone reads every line of source code of the game, which works well since it's a small team), rinse and repeat.

Does anyone have experience with starting a small team? Does this kind of coding approach work? What problems am I likely to encounter and what are the solutions? Is there any free/cheap software which can help us?

Answer 1

Srum works well for small teams, helps to keep people focused on what is to be delivered and identify any problems.

http://en.wikipedia.org/wiki/Scrum_%28development%29

EDIT From the comments below, there is a discussion about is a scrum master also a project manager. These are two roles, but in a small team we normally use one person to cover these roles.

Answer 2

The first thing I would do is ensure good testing of the software. Since you are not at the same spot breaking code through a checkin in your versioning system is very annoying and can cost you a lot of time.
I made very good experience with Hudson as an continuous integration server checking the svn every 10 minutes building the program running the tests and in the moment the tests fail or the build is broken sending out mails to the person in charge and the persons that contributed to this version since the last good run. If you add the continuous integration game to hudson you can make your programmers earn points for making tests run and using checkstyle or something similar together with it will ensure a overall code style for the whole source.
For information gathering and ticketing I like to use a trac because it gives you an overview over the svn. You can store information close to your source and you can give out tickets to your team members.

Answer 3

One of the biggest problems is going to be in delegating mundane programming tasks. Nobody wants to do the boring stuff. So you'll probably have to figure out a way to split that stuff up equally among everybody, so nobody feels like they're getting shafted.

Second, if this is, or has the potential to become, a commercial venture, you'll need to clearly define your relationship and any equity each member has in it.

I highly recommend reading Jeff Tunnel's Make It Big In Games blog, and in particular One Way To Divide Your Company Equity At Start Up

Very good reading, and anecdotes from a guy what has been there and done that.

Answer 4

Set weekly goals.

At the end of each week, have a team meeting (on IRC or skype or something--whatever works for you) and see which goals were met, which weren't, and why. At the end of the meeting set goals for the next week. This doesn't take very much time and helps make sure everyone is on the same page and everyone has an idea of where the application development as a whole is going.

Answer 5

• Do an on-line daily standup.
• Do a planning game once a week plus a retrospective.
• Keep a calendar of who is going to be available when.

• Use a distributed version control system and an automated build system.

• You might want to try mingle.

• Web cams help for the meetings.
• Use an irc channel/instant messaging.

[automated build] The reason to want an automated build and regression tests environment is fear of change. You want to be sure that you can change the system without breaking existing functionality.

Answer 6

There are three things that are, in my opinion, worth concentrating on from the managerial point of view that are less related to code and hence are easier to overlook:

1. Try to avoid scope creep (uncontrolled growth of game's functionality). Consider delivering a complete game which includes things beyond the game code itself (installation script, community web site and so on) and try to use the available time and resource wisely. Calculate the amount of time your team has got till the end of summer holidays, add up the amount of days each team member is likely to put in and aim to deliver version one given the timeframe (i.e. 40 working days times 4 members = ca. 160 days). Have a conservative roadmap everyone agrees to with dates and stick to it, this will keep things real and focused.

   If at some point you feel the team is slipping from the original plan it might be worth repeating the exercise.

2. Give some thought to the way you're communicating and coordinating the efforts: daily updates (Skype or e-mail is a good idea, plus some kind of screen sharing software). Weekly summaries (a brief e-mail summarising design decisions for the week and outlining work that needs to be done during the next week). It may be worth setting up a wiki or community web site and creating a dev area as part of the site forum (with some areas restricted for dev access only). This way you'll start building up external communication whilst as well providing internal forum.

3. Motivation is all about feelings: does everyone feel the goal is achievable? Is it fun? Keep your hand on the motivational pulse by trying to continually gauge how people feel about the project and the possibility of success.

   If you don’t live too far apart it might be worth getting together for a weekend midway through the summer and discussing the project in person whilst having fun. What does unite you as a group? Does the game contain some internal joke which is understood well only by a smaller community? Do make it personal; as a summer project its best if the effort doesn’t look too much like work for someone else. Its better be something for the team and their friends. Build up the suspense on the community site, send some screenshots. External interest will help the team’s motivation.

   There is little reason for you guys to stick together and keep putting your efforts in at this stage (no money, no community recognition, no existing game just a bunch of ideas) unless it feels really well and you all support each other.

Answer 7

Crystal Clear