Ok, i'm putting together a team of some local geeks. So I was wondering what steps we should take towards our game after we get the team assembled. I already have some ideas but it's always good to keep an open mind.

One thing Ive learned is that you need to PLAN. With capitals that is. If it isnt written in stone somewhere, someone is going to missunderstand the plan and write some different code in his/her class other than that was intended. Which renders that class useless and in need of a rewrite. Its not fun at all to rewrite working code just because you've missunderstodd the point of the class.

Do the planning, write design docs.

good idea thanks man

I think making a time plan is a really good idea too. It might seem useless for a small project but without it it's easy to lose the big picture.

Off the top of my head....

Start small. Pick a small project that is easily within the skills the team posesses and can be accomplished is a relatively short space of time. This gives you the opportunity to see how well the team works together, who are the over-achievers, and of course, who are the slackers. It also gives you the chance to see if the tasks are aligned to the individuals skills properly, whether you have the right mix of skills in the team (not too programmer heavy for example).

Pick a project that makes use of all teams members skills of course, so everyone has something to give and not more of one skill than the other. Give the team members the chance to pick the area they want to contribute in so everyone is also doing something they want and enjoy. This will help morale a great deal.

Most importantly, before any coding starts do as the other posters suggest and PLAN. Every contributing member should present their plans for their part of the project - how they are approaching it, techniques used, etc etc. This way you can see the project as a whole and whether everything is in sync in order to achieve the end goal.

You will also need a project coordinator. This might or might not be someone involved in producing parts of the project. Be aware of the compromises that have to be made when people have to plan, coordinate, and also produce.

Some of the things you need to clear up first in the planning discussions are things like the consistency in the tools used, the programming language, IDE for the coding etc. If everyone uses something different, then the project is not coming together. Look around for deals on software bundles etc so the team can contribute to buy packages, or decide on a freely downloadable toolkit that everyone agrees to use. There might be a learning curve involved for people switching IDE's for example.

Set expectations. Be clear up front that this is serious and everyone has to contribute - maybe even financially, and that you are in this for the long haul. Nothing worse than people being enthusiastic about something verbally, then that enthusiasm dropping off as they really have to commit to doing something. Again, keep it enjoyable and FUN!

Good luck! Post us some updates on your journey, and of course, things your team produces.

hth
F451

[Edited by - Fahrenheit451 on January 4, 2006 12:11:15 PM]