I've been on a communications kick recently, looking for ways to help improve my teams communication.

The team communicates well currently, but it's all verbal, email or IM communications. How do we retain knowledge, how to we make information searchable, and how do we get the information we need when we need it without flooding each other with communications spam. You know, the type of email that is cc'ed to every man, woman and child on the face of the planet just in case we think someone might want to know something.

I don't know about you, but this sort of communication gets a bit overwhelming and turns into just so much background noise. Emails get ignored, deleted unread or filed in the "action required" folder and then never see the light of day again.

For instant one-to-one communications we can walk over to someone and talk, or use the phone (no really!, it's true), or we can use skype or messenger. Any of these are viable options and work well and are currently used by the team. Of course nothing that transpires in these conversations is recorded or kept for historical purposes, but that's fine.

Then there's the delayed form of one-to-one communications we all know and love - email. Obviously email can also used for the one-to-many form of communications as well. Internally we log all the emails for security purposes, but we don't make them publicly searchable or retrievable for privacy reasons. Obviously this means that any knowledge transfer that occurs in email occurs with the participants of the email conversation alone and that's kind of OK but doesn't lead to long term knowledge retention for the team.

We also have file shares - the usual suspects where we store documents, specifications, user guides, use cases, design ideas, project documents and a whole bunch of other rubbish we just don't know what to do with. This is OK for knowledge retention and is most organisations one and only form of semi-permanent knowledge that isn't residing in the heads of their employees. The problem with this is that the knowledge is disorganised - sure people put documents in folders like \\server\share\myprojects\project1\March\2006\specs, but there's all sorts of problems with this. What happens if I can't remember when I did something? What happens if someone else organises their folder structure by subject matter instead of project? What happens when the person who put something in those folders leaves? Who really knows what information is walking out the door between that persons ears, where they kept things and how often they updated their information (if ever), and if we don't know what they did or didn't know then how would we ever know to look for it and where would we find it. Intranet search engines like the Google mini or nutch (which uses the lucene search engine) can really help in this matter, but your mileage may vary and you are dependant on permissions to folders being appropriate.

So we've got a few bases covered, but we're still missing a few pieces to the puzzle.

How do we do non-directed, non-real time communications?

How do we do non-structured information storage (especially for specs, etc)?

Wiki's answer the second question. And Blogging answers the first.

Wiki's help with non-structured storage for the team. Why? Because they are HTML based. You can write a spec, like a use case for instance, and link to actor definitions, other use cases, tech specs, or whatever else, all without caring about where exactly the pages for those other items live. In a file share system you need to put a reference to other documents in the main document, and hope that none of those other documents ever gets moved.

Wiki's also help with information currency. When something changes, it's easy to find the information in the Wiki (just search) and then edit and change it. File share based information is a lot harder to do because finding the information in the first place is difficult and that alone prevents most people keeping information current. The barrier is too high.

Wiki's like MoinMoin also feature historical tracking and a diff tool. Someone changes something, then you can not only see who changed it, but what the change was. When updating software to match and updated design, this is a boon. Trying to do it with file shares pretty much means relying on the "track changes" feature in MS-Word, and people will forget to turn that on, or will merge the changes before someone else can see them.

Blogs help with the non-directed communication for the team. I don't think I need to explain the benefits of blogging and there are enough other articles on the web for that. I had a bit of a look around for decent team blogging systems and saw things from the main blogging people but none of them really seemed to work well for team blogging - where each member of the team gets their own blog and can so what they like within that space. Then I ran across Community Server. What a pleasant surprise that was.

Community Server features include blogging and personalisation, but they also include forums. Now I have a mechanism for not only supporting the non-directed communications and keeping the information searchable and retrievable, but also keeping the "how do I" type of questions in an area where others can search for and find information much later (which I can't do with email).

I put community server into the team last week, and the initial take up has been positive. Like all things though, the hard part is now encouraging those that don't naturally put their knowledge down on keyboard, to start doing so.

By the way, in case you're wondering, do I think this solves all of the communications issues, or the knowledge retention or search problems I have? Not likely, but it's a few more tools to help and enable communications and in agile environments communication and openness are a few of the keys to success.