I need a methodology to organize my team for a university assignment.
I am a university student and already have some programming experience. My experience of working in teams of more then 2 people on a relatively large project is that everything usually gets done very quickly and badly in last week or so because of planning, organization and communication issues. In January I will have to do a (quite challenging for my skill) programming project (Java application on Oracle) in a team of 6. I already know my team members and was elected the project leader. It won't be realistic to expect people to get together for any meaningful-sized amount of time - everyone is free at different time and probably nothing more then weekly 1-hour meetings is realistic. People are hard-working and devoted to success, but everyone has their own circumstances. Mostly distributed work is the likely way to go.
I've looked through XP, Scrum, but they all require to sit together (unlikely), aimed at full-time development of a project (people have other assignments and part-time jobs) and customer involvement (we will have written specs and as far as experience goes, emails from tutor will be answered at best in 2-3 days).
Any suggestions how to organize people and divide the work? I am serious on researching this topic, because there will be much more of this kind of works later on.
Any help appreciated.
I was one of the leaders of a team project (6 people) last year at university. Based on my experience, I have a couple of key points.
While forums, online chat, email, SVN commit messages etc. are all very good communication mechanisms (and I do recommend them), nothing is more important than weekly meetings. These should involve delegating/discussing/monitoring tasks, talking about general issues and the bigger picture, making group decisions, and simply using your app and identifying issues with it as a group. By doing this, it becomes instantly obvious where people are at with their tasks, where they might be confused, and whether they understand what needs to be done. This is crucial because the feeling of being 'lost' and having no idea where to start is often the biggest obstacle to making progress, rather than laziness. And besides, group decisions are best made in person where you can bounce ideas off each other... and this all helps to establish a sense of shared ownership.
There is no one best way to formulate, delegate and monitor tasks. But it is important that you can divide and parallelise (as much as possible) the workload into sensibly sized tasks and identify dependencies between them. Our group maintained a TODO file in our repository which consisted of a list of tasks, dates, and bugs. We prioritised tasks according to factors such as whether they were mandatory requirements or optional niceties (think MoSCoW), whether they were on the critical path, how much risk/uncertainty was attached to them etc. We allocated one or two people to most tasks based on their strengths and whether they actually wanted to do the task, but we also left some tasks open to whoever wanted them (this is potentially dangerous too). A couple of us stronger programmers also played 'floating roles' meaning we could help out with any task. A key point is that the task descriptions should contain anything discussed in the meeting... the what, the why and a couple of 'how' sentences as a kickstart (i.e. "to accomplish this, you might want to read up on blablabla")... anything which makes it easy for your teammates to slip into a task.