Alex Rivera | Logout

Ways to improve communication between members on a software team

Asked 2010-01-29T19:28:42.893
11

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!

communication methodology
Edit
Report

2 Answers

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.

answered 2010-01-29T20:10:48.807
0

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.

answered 2010-01-29T19:45:18.360

Your Answer