Ways to improve communication between members on a software team [closed]

Answer 1

I use BaseCamp to manage my projects. Meetings become fun brainstorming sessions, the work is then delegated on the site.

Answer 2

Document everything, and not in email!

Use something with a history. I've been tempted to use Google Wave for tracking a project's "Development" (changing requirements, interpretations, etc). A wiki will work too but has a higher barrier to editing and may be updated by fewer people. Campfire is also a good methodology.

The new methodologies (Campfire/Wave) are essentially recorded chat logs that you leave open all the time. Campfire has no way to "Promote" important decisions, I think they'd get lost in the general conversation--but with Google Wave and Wikis, you can continually trim out the irrelevant or old information. Wikis will give you more ability to reformat the new.

Actually a combination of Wave/Wiki might be best. Just use the wave for daily IM type talk, and pull important threads/decisions onto the Wiki.

Some of the practices in XP (Agile) help here as well. If you go FULL ON xp (not just calling your daily meetings "Scrums") you will find some important help such as tracking requirements on cards that are constantly updated or having a customer on site to answer important questions. The whole idea of XP/Agile is based around the fact that requirements change and those changes need to be tracked and that they effect the release schedule.

Answer 3

Before closing a meeting, the person who's leading it should state the action items and of course, who is going to perform them, and get agreement from the assigned person or people. Someone should be assigned to create meeting notes, and post them. You could try taking turns on the notes so that everyone has to do it sometimes. You could try a scrum master (if you're doing scrum).

Try a wiki for the notes. The meeting notes should include the action items. All action items should have a date associated with them.

If you can't get anyone to recognize that a record of what you're doing is important, you have a serious problem with your developers. Of course you can take a picture of the whiteboard and its notes, but that won't help the reading and maintenance problems.

Many programmers (myself included) like writing documentation quite a lot.

Answer 4

Stick to the agenda. Stay on target. When things begin to veer off course, either schedule another meeting or take it to email after the meeting.

End each meeting with action items - a written list of who's going to do what and when it's expected. Yes, this means someone needs to write/type something during the meeting.

If documentation is becoming important and needed, then I strongly suggest you come up with simple standards and then stick to them.

Wiki. Wiki. Wiki. All "tribal knowledge" information useful for the team needs to go into a wiki. How to set up dev environments, common debugging tips, etc etc.

Answer 5

I find it is important to record the reason for a decision on a Wiki or post-it board. Without it, on critical items where two options can be implemented, you will see one developer reversing some code of another developer. Both may have valid reasons, but it is a clear indication of lack of communication.

To avoid issues like this, key decisions from meetings need to be repeated, even up to a month afterward.

Answer 6

Why not just have notes kept on these meetings, in a wiki, so that others can see it, and people can modify it to clarify ambiguities, and then you have a reminder of what was agreed upon.

You can then take the features, and put them in your bug tracking software, so that you don't lose track of the fact that there are features waiting to be implemented.