Information/knowledge flow within the team

Question

I want to avoid the situations when my developers do not share the common knowledge (solutions for the problems they encountered, cool tips, common mistakes, shortcuts for achieving particular goal, configuration issues, partial requirements, etc.) with each others. I'm taking about the situation when such lack of communication is accidental (a result of the misunderstanding or improper management) - I'm not thinking about the situations when developers deliberately keep the knowledge for themselves.

I believe that the following techniques are extremely useful to improve the information flow within the developers team:

• XP pair programming - due to the knowledge exchange within the pair (and due to the regular pair mixing).
• stand-up meetings - due to the occasion to tell the others on what you're working on and what problems you encountered.
• trainings/presentations/coaching prepared by the lead-developers to the rest of the team/department.
• "web 2.0 tools" - techie blogs for the company/department, dedicated twitter account of team leader, wiki's and stuff like that.

Any further ideas? What techniques do you use (or did you) in your company? How would you encourage developers to share the knowledge between themselves?

Answer 1

Trust.

You are allowed to 'seem stupid', but please ask if you don't know, or don't fully understand what I'm saying. And please tell me if I'm wrong (I didn't realize it because I'm equally stupid.)

Answer 2

I'm a big proponent of working in pairs. It is a good way to transfer knowledge and keep communication lines open. Try mixing up the pairs for each project as well.

Answer 3

I worked at one company where every Friday we had lunch meetings for developers. Management would provide food while developers had to share their knowledge; present some tool or technique one learned recently, or give a demo of a project you are working on, etc. It wasn't restricted to the technologies that were being used by the team at that time, developers were encourage to learn new technologies and give a demo to the team.

And at my current job we have monthly IT group meeting, where sometimes developers from different teams demo off the projects they've been working on.

Answer 4

I've tried many approaches, and am a big fan of working in pairs on projects, as well as doing regular discussions or meetings with the team.

However, I've also found that the single best thing I can do is foster a culture of constant communication between the developers. I try to have all of my developers communicate with each other as they work - not even necessarily waiting until a weekly or monthly meeting.

For me, this is a little trickier as most of my developers are not in the same location, so we have a single XMPP chat room setup, and all of us are always logged in when we're working on the project. Some of the developers (including myself) will login during our off hours, as well.

I do the same with the people in my office - we tend to be a fairly quiet bunch, but I'm very open to having people interrupt each other with questions, or grab a chair and sit down to brainstorm at any time.

Part of why this works, though, is I try not to restrict the communication to the work at hand, or any specific project. My feeling is that people are going to talk about other, non-work related things, whether or not I foster that. I'd rather have the "water cooler" talk in an official channel, though, than outside.

This makes everybody feel more at ease to ask the questions that "seem obvious". Also, people ask questions continually, since they're right there, and used to talking to everybody. It's easy to ignore if needed, but also much easier to just throw out a general question and see if anybody has ideas without feeling like a pain, etc.

My experience is that the time lost due to interruption is much smaller than the time saved due to having a group that is always eager to help solve a problem at hand.

Answer 5

1. An internal twitter-esque utility. Maybe a wiki if you can get it to work, I personally find it a little too much. But twitter is different. "just added an extention method to escape a like clause in a rowfilter" and stuff like that.

2. Some people may find it a little overbearing, but a common location for utilities so you know where to look and string.CountOccurrences isn't scattered throughout the codebase.

Answer 6

If you have a small enough team, using adequately SVN commit comments, and exploit them a tool that generates an RSS feed (like Trac for instance) can be an easy and efficient way to promote communication.

There are several requirements for this to work, which are quite easy to attain: - commit frequently (that is good in itself, as it allows everybody to benefit from each programmer's local changes, and to identify problems early); - use verbose comments (which is good to, as it allows to trace more easily what was changed, in case anything breaks down); - ensure everybody actually reads (better even, keeps posted to, through an RSS reader) the feeds.

Of course, there is no way to "reply" to such comments, but if someone really needs to reply, it's probably between that person and the committer, so mail is usually enough.

An other useful tool is to ask each developer to, let's say, once a week, write a 10 or so bullet point list of recommendations for fellow coders, on a topic he/she is really familiar with.

Answer 7

I'll add a few more

• Hire the right people - This is essential if you want to create a great dynamic (asocial people require a lot more effort)
• Pre-mortem and post-mortem. We use the wiki for this, create a page for each of your projects, split it into section of recurring things (both goods and bad). At the end of each milestone, have the team meet to do a post-mortem. At the end of the project (or after a fix lenght of time), have project coordinator compile this into something easy to read for posterity (and put it on your wiki)
• Daily stand-up are a must! You already said it, but I find it so helpful!
• If you have multiple teams in the company, organize conference about one of their greatest achievements. If possible on a regular basis, even accros department, you would be surprised how artists can be interested into programmers work.
• Lunch is a good time to share, in our company we have the president breakfast, project leads lunch, end of projects supper. I love them all, mix and match for greater results.
• Offsite meeting with the whole company is great, we do it at least once a year (morning we present what's coming up in the futur, afternoon, is activities to learn about the projects)
• Wikis are great, but beware of informations that can become false over time (this is a reccuring problem with any written informations)

Answer 8

A few more things to my mind:

• Patterns & Practices meetings - These don't have to be every week but there should be some time devoted to where the team can discuss various outstanding questions and have concensus for things that may save a lot of people headaches.

• Culture factor - Does the work place provide enough socializing to help the team gel or could some team-building exercises, e.g. an obstacle course or cooking together, be useful in getting some dynamics established. Is there a humility among developers so that there aren't big egos that can be a problem. Another factor here is to think about how you'd answer this: Would you go to a local pub and have a drink with your fellow teammates? If yes, then you have some good points here while if not, then there may be some investigation to do here.

• Retrospective follow-up - How are ideas presented during retrospectives considered and implemented? How are meetings handled in general?

• Demos within the team - If some story got finished and involved some big code points, then perhaps there should be a little demonstration of this for the team to see what was done and allow others to see what was done so that the knowledge does get spread around. This can dovetail with my first point in terms of being something that helps to further communication.

Answer 9

Time.

Official

Getting out of your dusty office to clear your mind, really taking the time to go to a lecture or training, it all helps to spread knowledge.

It's also easy to budget: N developers go to meeting for T hours.

Unofficial

"On the job" training... The things you need for your specific job can only be taught by someone who knows the job.

In the current climate, under the current pressure (must ship now), no-one takes time to fully explain something. Only when people are relaxed, they are readyfor information sharing. People are relaxed when they have enough time.

Apart from that, you need to bump into some specific linker error before you really start thinking about it. Without the time to think, ask, read, you won't be able to get the knowledge. You can't postpone it to an official linker-training.

Way harder to budget: developer Mary asked developer Sophie about dynamic linkage for an hour and a half. The day after, she went back with some questions. Experienced developers will spend more time distributing, while younger will need more time learning.

Answer 10

• no walls - Have all of your developers in one large, non-walled room - where everyone can see and talk with each other.
• common goals - ensuring your team has a good understanding of goals INCLUDING the goal of self-improvement
• rewarding - rewarding - even if nothing more then communication - reinforces what you are looking to accomplish

Socialization and common goal always encourages exchanege of information.