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:

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.

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

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

Voting to close... this isn't a programming related question, it's team management related and the same question could apply to almost any business.
–
Andy EJan 29 '10 at 19:38

Not sure if I agree. Programmers, especially younger guys are notorious for not wanting to document anything, more so in my experience than other business folks.
–
Tad DonagheJan 29 '10 at 19:47

1

Very programming related! Very few businesses have the same design problems as programmers have, and even if it was relative to all businesses, it happens to be a problem EVERY programmer has to deal with eventually.
–
Bill KJan 29 '10 at 20:04

@Andy E:"programming related" is not the same as "programming specific"
–
JavierJan 29 '10 at 20:08

@Javier: Say that to all the users who have their programming career related questions closed. This is essentially the same thing.
–
Andy EJan 30 '10 at 11:40

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.

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.

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.

That was my first thought, but as a general rule NO ONE wants to take time to write and maintain documentation. Capturing the information in a highly visible format is what I'm looking for a clever way to do...
–
AchillesJan 29 '10 at 19:35

Our team has tried this: The problem is that many programmers won't make an effort to document ideas and meetings and prefer to just write code... now what?
–
harschwareJan 29 '10 at 19:37

Have someone volunteer to help put the information into a wiki, or, when you are done, take pictures of the whiteboard and have that start as a capturing of data in the wiki. You can write to the wiki during the meeting, and later people can clean it up. If programmers don't care to communicate well, then that is a cultural problem you will need to resolve.
–
James BlackJan 29 '10 at 19:42

2

People will usually do what they're rewarded for, and refrain from what they're punished for. Institute documentation reviews.
–
Liz AlbinJan 29 '10 at 19:43

Time to grow up if no one wants to take notes. Keeping good meeting notes, wiki, etc is part of professional programming. It's one of our tools and just one of those things you have to do. Writing a 30 page tech spec is something to avoid, but keeping an up-to-date wiki of tribal knowledge is critical.
–
Tad DonagheJan 29 '10 at 19:44

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.

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.