Programming with a group of people I've never met

Question

I've been assigned a group project from my AP computer science class, and I am required to work with three other people. I've never talked to them before, I have no idea their skill level, and all I have is their email address. The assignment, summed up, is this:

"As a team you will complete a minimum of three Modules to a Class...."

I going to try and become "Team captain" because none of them have attempted to contact each other but I am curious: how to go about this? I've emailed them and asked them if there are any methods of communication they prefer over emailing each other, but once we actually start the project I'll have to figure out who is doing what.

What should I do? How do I "take charge" and lead three people that I've never met?

Here is an excerpt of the actual assignment:

Therefore you will need to discuss the various roles each team member will take in this project early in the week. You can communicate via Pronto (or Blackboard IM), email, a wiki, a google group, blog or any other method that you see fit. If a group member does not engage the group by the end of week let your instructor know and they will provide additional guidance.
...
Also due at the end of a project will be a team evaluation in which you will rate each team members contribution to the completion of this project along with a suggested grade.

Edit: Many people suggested that I meet them in a coffee shop, or something like that. Only problem is, all of us are in different states. I also figured out one of them isn't allowed to use Facebook/Skype/twitter, so I have to resort to messaging them over yahoo messenger and emails.

Answer 1

The leader of this project will be the person who steps up and takes charge at the beginning.

This applies to most things in life - not just software development. When everybody else is running around like chickens with no heads, the person who thinks things through, steps forward and says, "This is what we're going to do and this how we're going to do it." is usually the person looked to as the leader for the rest of the project. Bear in mind that by doing this you are taking responsibility for the ultimate success or failure of the project.

You want to lead this project? Here's a couple of things you can start doing right away to make a big impact.

1. Use a project management tool like Trello and send invites to everybody and start assigning parts of the project out to people.
2. Generate a bug database and start adding tasks and bugs - again, just start assigning.
3. Set up a version control repository and check in a good initial chunk of code that everyone can work from. Refuse to deal with any other form of code control.
4. Offer to help people get going with development by showing them how to use the version control system and bug database.
5. Send out weekly emails detailing the status of the project and the progress of the previous week.

None of these steps are particularly hard, or time consuming, but they will be huge time savers down the road. Furthermore, it will get your team talking to each other, and get them used to seeing you in charge.

Answer 2

Jarrod Nettles' answer pretty much summarises a lot what I was going to suggest, so I'll throw in some of what worked in my recent experiences in a similar situation.

I would suggest finding some way to talk with them vocally, rather than by email. If you're not in the same area, get them all on Skype. If you're in the area, meet them at a coffee shop or something. Speaking in person in initial meetings will lead to you actually making decisions and getting work done then and there; email threads allow those who're shy or often not at their computer to hold up the process - we all know how lazy students can be!

In your first meeting, I would try to get to know your group over trying to get on with the project - but don't ignore the project! 10 or 20 minutes spent ice breaking is probably enough amongst 4 people.

When it comes to talking about the project, I would suggest running through what you think the project involves. I think it's important you make it clear this is your understanding, and not a case of you telling them exactly what to do. Everybody should be able to throw their thoughts and ideas in to the ring if they have any, and you should come away from that initial meeting with a decent enough understanding of what you, as a group, feel the project entails.

In future (regular) meetings, you can start to look at different bits of the project in more detail; look at what needs doing exactly, what resources and how much time will be needed and who can do what. Split the piece up further if necessary. Perhaps try set some soft deadlines?

Answer 3

Do any of you have experience with working with a group of people you've never met online, and you don't get to meet them in person but must complete a project together?

Add in underbudgeting, ridiculous deadlines and getting sold down the river by marketing and this sounds like roughly 65% of software development projects in the real world.

You'd probably be best served by getting folks to volunteer for parts they would be interested in doing rather than taking charge unilaterally and assigning tasks. They are all probably sitting there thinking about how they should take charge. Or how they can get some poor sod who cares too much to do all the group work so they can ride on his grade.

Answer 4

First thing to do in cases like this is to establish an issue tracker and learn how to use it.

For a more fundamental introduction on how to handle development like you describe, my favorite reference goes for Martin Fowler's article Using an Agile Software Process with Offshore Development. This article outlines basics and advanced concepts of setting up distributed team communication:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

For your project you sure won't be able to follow all the tips and tricks mentioned there (eg there likely be no Ambassadors nor Contact Visits for you :) but it is worth studying anyway.

• For many teams having all of above would be an overkill for sure. Still, I find it really helpful to have a comprehensive checklist like that - so that even skipped items are checked and have clearly documented reasons for rejection - just to make sure nothing important was missed.

Answer 5

You haven't told us how much time you have for this, or the language you're working in (I would say a single class is very small, but perhaps in your language it's a good deal more).

First of all, have a working product at any cost.

If the project lasts two weeks or less, assume you will be the only one doing anything and be very happy about any help you get. Try to schedule things for everyone, but make sure that if nobody does anything, you'll still have a working product. Even if someone does something, don't rely on them continuing: be prepared for anyone to drop out at any point.

If you have more than one week, consider scheduling a day of the week when the product should be marked as a milestone and stick to that as much as possible. Make sure you have something you can kick around and check the deficiencies of: if worst comes to worst, this will be what you hand in. Each one you create, you will see how much you could improve things, which will motivate you to go on. Don't plan too far forwards: sure, you need to have an idea of what you'll end up with, but keep your most specific plans short-term.

Notice that those two overlap a little: this is intentional, as two weeks is in my opinion a bit of a grey area where getting two iterations done is hard, but only working in one iteration is risky.

I'm assuming the worst case, where you'll be working with people very new to programming. My general advice would be:

• Keep a list of features you want to implement soon, and who will work on them. Jarrod suggested Trello, and I entirely support that: if your teammates aren't very experienced, it'll help a lot. You could try keeping the bugs there, too.
• In a team of four, you need version control. It may make others more reluctant to contribute if they don't know how to work it, but it's worth it.
• Any external dependencies may scare away newbies. If you write unit tests, tell people that they shouldn't worry about breaking them. Tell people that they shouldn't worry about breaking the build, especially at first. It's much harder to correct people who don't commit any code than those who commit buggy code.
• Check whether things suggested here really apply to you. "Continuous integration" is a fancy term -- for a small program, that might mean "this program runs and all features can be used". Do you even have sites? Does splitting into teams help you?
• YAGNI, a hundred times over. If you really have to, write things in advance for features you'll be making yourself. Make it work, then refactor, or you won't get around to making it work.
• Refactor. Once it's working, spend some time fixing it. Don't forget your teammates will have to read your code, too: a day spent fixing ugly pieces and replacing simple solutions with better-performing ones is not a day wasted.
• Keep an eye on all parts. Skimming changelogs and occasionally reading others' code helps make sure that everything is up to the quality standards you feel you should enforce and makes sure it isn't as hard to dive in if the person drops out.
• Don't hesitate to work on the most important thing, as opposed to your designated thing. If someone is falling behind schedule, make a written note of that somewhere and do it yourself. Ask them first, but go ahead if they don't answer, or if you ask once or twice and then feel like they still won't do it.
• Focus on making something you're proud of. Even if it deviates from the assignment. Even if you have to cut big features in favour of making what you have more smooth. Every iteration think "Am I proud of this?", and in the next iteration, try to fix those things.

I had a project that failed horribly recently; you can read my thoughts on why it failed if you want to, but this summarises how I'd do something like this if I had another chance to.

Answer 6

Jarrod Nettles's answer is good. I would add this:

1. Expect that at least one of the other three people will be completely useless.
2. Just accept that you will feel like you are doing most (or all) of the work, but everyone will get equal credit. Any attempt at trying to make things "fair" will only cause unnecessary conflict and slow you down.
3. Stay in contact with any team members who are good. Such people are hard to find, and you will want to work with them again.

Answer 7

I have been in a similar position a few times as I am sure have a lot of people. The main thing though is to do your best to keep everyone content and happy, so I think it is good that you want to take on the task of team leader, however like someone mentioned above - this does need to be approached carefully as someone else may feel they should do the job instead.

I know you said that no one has taken it upon themselves to contact each other but sometimes these situations can be difficult for people, like you said you are working with people you have never met and it can be difficult to communicate etc.

I would begin with an email just addressing everyone and letting them know who you are how you feel the project should be addressed and make it known that you want to lead the project taking responsibility for setting roles, goal, deadlines, communication time, meetups (if wanted/desired) and project updates.

Although you can not completely influence other people you can keep track of who is doing what and who is not. Delegating jobs allows the work to be split up evenly or appropriately to people with different skill sets or levels.

This way if certain work is not being done you can take it upon yourself to divide the work between the people who are actually keen to work on it. This way you wont end up with a failed project at the end and you will have records of trying to communicate dates, times and all the relevant information you can show at the end if things go wrong. ALl things which keep you in the right if some people dont pull their weight.

In terms of tips:

I personally love a collaborative working environment found here: https://docs.google.com/

This allows you to share word documents, spreadsheets etc. It is a great way of collaboratively working. I cant stress how useful this is sometimes. I use it with some people I work with who aren't in the country at the moment.

Hope this helped someone, there are so many aspects of leading a project we could go on forever but it just depends on so many things. At least this is a tiny bit to help.