Ways to improve communication between members on a software team.

Question

As the team I am on works to formalize and establish more development practices, I find that communication seems to fail at the following points:

1. During an informal conversation about a project a brain spark moment becomes a new feature/requirement. These "add-ons" seem to fail through the cracks or the detail become fuzzy after some time has passed.

2. In meetings where objectives or tasks aren't clearly delegated, the members involved in the meeting have different accounts of what was actually discussed.

3. As a team we are constantly challenged(more so now that we actually are aspiring to write them) to generate quality specs and technical documents that detail exactly what features need to be in projects.

My question is: What are some suggestions and approaches to addressing these communication bottlenecks and inefficiencies? No programmer likes writing documentation but there hopefully is a way that we can centralize understanding and keep that information more visible and available during the life-cycle of a project...

Thanks for your help!

Answer 1

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.

Answer 2

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 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

As for #1: How about a new ideas post-it board? Create an area that is highly visible in the work environment. As ideas are discussed slap a reminder note on a sticky and put on the board. Keep the board partitioned into categories (ie UI, performance improvement, etc.). A responsible member can take charge to transcribe these to a full wiki, when detail needs adding or the idea is good enough that it deserves some true effort spent in design.

As for #2: If your team has trouble staying on target, then definitely the mtg organizer must take the time to prepare an agenda and adjudicate conversations stay on topic and insist that meeting ends on time. Leave the meeting knowing who must do what.

As for #3: Someone must lead the charge, find examples of the kinds of documentation and specs that you like to see and schedule some time with the team to review and discuss.

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

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 7

I think that a wiki or a internal blog could be excellent to document useful procedures for all team members.

But another interesting point is the communication between programmers when some programmer has a implementation doubt. For example: a programmer doesn't know how to implement some functionality. So, it could post your doubt in a "short messages application", like a twitter (but with more than 140 chars). Then, some developer that knows how to solve her doubt could post the solution. All the messages will be stored until the solution was found. So, all the other members of the team will look to this solution in future.

I think that this schema is nice, because sometimes the developer doesn't like to "waste a lot of time" writing a post on blog or something on wiki.

Answer 8

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