Organising a Development Team - Posted Monday, 21st August 2006 by Liam

One of my assorted articles on developing, this article is about Development Teams and how to work with one.

I once released this article on nornrock.com, but it has been much revamped!

If you're planning to start a development team/are in a development team which is just starting out, this might be a helpful read.

Written by Liam, edited by malkin.

Step 1: Plan ahead!

One of the most important steps when creating a development team, for any project, is to plan ahead. Decide exactly what you want to do, and which aspects of development you are prepared to help with before advertising for help. In my eyes, it is a bit pointless to go into a project with nothing but an idea. If you arenít much of an artist or a programmer, take a few tutorials and learn the basics! Try drawing a simple machine, or a plant, or try something simple in Photoshop, Paint Shop Pro, The GIMP, or Just MS Paint! Choose which talent you would like to develop and ask around for some tutorials, or just learn as you go along, its up to you. It is best if you can contribute significantly in some way, otherwise you might have a hard time attracting fellow developers to your project.

As I mentioned earlier, you need to decide what you want to do. Have you got an idea for an amazing new norn breed? A new metaroom? A revolutionary new agent, perhaps? Whatever it is, try to keep it as simple as possible to begin with. If it is a metaroom, try to refrain from making it too large. If it is a norn breed, donít get too complicated with ideas for genetics or graphics!

Keep It Simple, Stupid!

K.I.S.S. Is an extremely important concept in development. If you start complicated, youíll never get it done! Begin simply and work your way up.

Remember, HAVE A PLAN!



Step 2: The Team

The only thing you need is a team now, right?

Almost, but not quite.

You have the idea, and you have something you can contribute to the project. Now, you need to decide what other points need covering. If youíre a concept/agent/background artist, youíll possibly need another artist and a programmer, and maybe even beta tester (although unless this is an extremely experienced tester, Iíd recommend doing this part yourself). Iím going to try to give you some idea of who youíll need, and how to distinguish between the people who will be beneficial to the project, and the people who will just slow the work down.


The Concept Artist
The concept artist should be someone who can draw well and come up with innovative new ideas, as well as help move the project along. When advertising for a concept artist, I would ask them to send you some of their work, as well as some ideas they have which they believe could improve the project. This is a very important position in the beginning stages, so make sure you like the person who becomes the conceptual artist.


The Programmer
The programmer should be someone who will code the objects needed, but also suggest improvements such as adding or removing a feature. When advertising for a programmer, as with any other, get them to send in an example of the work that theyíve done in the past. Quite a few programmers I know are not perfect at art, but when they are handed a plant, animal or machine to code, they expand on the original idea and improve it so much that by the end you can barely recognise your idea - but in a good way. This is the kind of person you want to find. Make sure they arenít afraid of telling you what needs to be changed, as well!


The Background/Agent Artist
The artist should be a person willing to work with ideas, and be able to make a beautiful image with what ideas people have for the room/agent(s)/breed. There are many, many different styles of art, and they are all wonderful!
When you are looking for an artist, Iíd suggest showing them a drawing you or someone else has done that relates to your idea so they have some idea of what you would like, and have them show you some of their previous work so you can evaluate them.


Everyone else
Then there are beta testers, and other smaller, less important tasks. Really, you donít need them. The smaller the team, the more efficient it can be. Note the Ďcaní. Some teams just donít seem to work, and if this seems to be the case skip down to Step 4: Problems You Might Encounter.

If one of the members of your team excels at their task, but doesn't get along with the rest of the group, itís not worth having them on the team. Eventually it will just create arguments that will bog the whole project down. Now, onto the next partÖ



Step 3: Getting It Done!

You have the team, and the idea. Now, the only thing to do is the actual project. Thatís right, itís not going to work on itself, you know.

Iíd suggest trying to get the entire group together on some sort of messenger program, like MSN or Yahoo, possibly even JRChat or E-mail. Once you have the group together, whichever way you do it, share the ideas youíve all come up with and ask everyone else for their opinions. Show the work thatís been done so far, and start from there.

Try to have sessions like these once a fortnight, or if you can, once a week. Itís important for everyone to discuss the things that are being worked on, and point out things that could be improved or scaled back. Once again, the K.I.S.S method is essential. Remind everyone of this!

Once you have a rapport established between team members, you can start to correlate your works, and to put them together in a workable format. This is covered in more detail in ĎThe Creation of a Metaroomí and ĎThe Creation of a Breedí.

Remember: YOU MUST HAVE A PLAN! Otherwise, it's like trying to get to someone's house when you know what their house looks like, but you don't know what suburb they live in.



Part 4: Problems You Might Encounter

Often arguments break out, there is a lack in communication or it just doesnít seem to work. Donít panic! This happens all the time. Try to keep communication flowing, and make sure you have a plan. Always ask everyone for their opinion, and whatever you do, donít boss them around! many developers resent being bossed around. Just keep this in mind when coordinating a project.

Every now and again, take a look at whatís being worked on. Is what the artist drawing going to fit with the background? Is what the coder doing going to work with the images? Is there an inconsistency in the idea?

Often people disagree on what the final product should look like, or what it should do. Talk it through with them, and do your best to incorporate their view into the object, room or breed in question. ALWAYS talk over what you are going to do and what needs to be done, and whoís going to be doing it, and get the whole teamís opinions on the subject.

Once again, I must reinforce the fact that you MUST HAVE A PLAN! Itís very important.



Part 5: Troubleshooting

One key member isnít around any more Ė what should I do?
Email them and ask them how lifeís going. Not their part in the project, life. They will appreciate your concern and feel more disposed to work on the project when they have some spare time.

If they can no longer work on the project, discuss getting a new member in to fulfil their previous role in the development team. Always talk to the key member first!


I need some help with a part of the project, but none of the others want to help!
Thereís probably a reason for this - have you been particularly rude to any of them, or perhaps there has been a miscommunication between you and the rest of the team? If there has been a conflict, refer to ĎWeíre all fighting, what should I do?í

Perhaps it is simply that none of the other members have the skills needed, or are too busy- if you think this might be the reason, work on a different part of the project for a while until they can help.


Weíre all fighting! What should I do?
Firstly: calm down! If there is a conflict, in order to solve it everyone needs to be calm and rational. Get everyone to present their point of view in a logical way; support your arguments. If there is one member in particular who is causing trouble, try talking to them alone on IM and finding out what their issue is. Try to help in any way you can.

If you solved the problem (or there was no problem in the first place) and one member is being particularly argumentative, talk to the other team members and get their opinions before Ďkicking them outí of the team. Be as diplomatic as you can and try your best to preserve relations with everyone in the team.



Part 6: Deadlines

Deadlines are an evil, yet necessary thing. Often you have a deadline, and one or more people donít meet it. I know deadlines are stupid and horrible, but they are necessary. If someone fails to meet a deadline, talk to them about it and find out the reason. If there is a problem, attempt to fix it. Sometimes conflict is unavoidable, but donít take the Ďpassive aggressiveí stance - always try to keep a positive outlook at find the best way to work with people, and not against them.

Arguments within teams can often ruin friendships, and bring out the worst in even extremely well-mannered people, so try to keep these to a minimum by promoting a positive working environment.

I hope this article has helped you in some small way - if it has, if you have suggestions, or hate this article - please email me at liam.esler@gmail.com and Iíll respond as soon as I possibly can. Thank you!

[English] [FranÁais] [Deutsch]