How do you communicate effectively in a small development team? [closed]

Question

I work in a small team (4-5 developers) on a single project. Every member of our team is developing a different functionality from our project and they are highly independent. In fact, some members use technologies that other member doesn't know about. It's still a single project and there a lot of common business logic in it.

In addition, most of the members are completely unaware what and how the others are doing. Somehow, we manage to avoid code replication (credits for our team-leader, but even he is not completely aware what is happening). I wonder, what is a good practice to keep the whole team on the track what is going on. For example if some one from the team quits or is missing when an important fix should be made - it's difficult for the others to handle.

We have a policy, for conducting code-reviews, but only the team-leaders and one member of the team participates in it. The other "regular" members do not take part, there.

Also, we have a "newslist" for checkin-s committed in the source control by our members, but this seems too boring to deal with and it looks like nobody is taking time to read what others have just committed (and it's not effective, to be fair).

So, I wonder what is a good practice in this matter. What experience do you have? Is there a solution at all ?

EDIT: Let me clarify a bit. Our team is working for more than 2 years and the project is almost 5 years old. So, we can't start agile development, although we could you some agile practices (like stand-up meeting, I find it very useful indeed).

Also, our team is a part of a bigger company, so we have established a team-building practices. And we don't hate each other :) - we are friends, talking about social life and activities. The professional talks is what we are missing.

Answer 1

• Standup meetings each day (keep them short) with everyone present help everyone understand what each other is doing. This also helps the manager get some management out of the way, helps prevents thrashing, and puts a little pressure on each individual without the manager having to do it. (You want to have something done so you'll look good in front of your peers tomorrow morning). Some methodologies like Scrum formalize this.

• Have code review with different team members. Is one of the non-manager team members more experienced? Having this person do code review with others would be good; he/she would share their experience and be someone else (besides the manager) who knows most of what's going on. There's no law that says in a peer review one person must be more senior than the other and be the one who declares code right or wrong. I think though that if two "peers" are doing code review, they should just pair-program to begin with.

• if your are trying to write some quality code, certain bits of code might lend themselves to pair-programming. XP people say you should do this all the time, but I believe it's more helpful sometimes and other times. For example, when one developer is more experienced than the other, this helps with mentoring. Also, when there is a specific area where you want knowledge to be spread. (Only one guy understands a part of the system; next time that needs revising, have that guy do it with the other person typing.) Also, sometimes a part of the system is really important, and having it crafted correctly is far more important than lines-of-code per minute. This is a great place to have two heads on the problem, and in the end two people have intimate knowledge of this key code instead of one.

• Something like once a week, have someone present a short talk during lunch on something interesting they're doing. This can generate great discussion, promote confidence and mutual respect, but what we're interested in here is that it promotes awareness.

• Value, support and believe in good code. Some shops (the managers mainly) don't really believe in good code, and this leads to people just busting out (crappy) code, even if the developers could make great code. Communication about code happens a lot easier if developers are happy with the code they're making, if you're implementing some new technology now and then, and if quality work helps your career.

And more about pair programming. The key part of pair programming for this discussion is that pair-progrmaming promotes shared code and cross-knowledge. The reason I mention the specific places where pair programming is particularly helpful is because the policy "we're going to do pair programming" succeeds about 10% of the time. The other 90%, the proponents of the practice can't give a good enough answer when a big manager asks, "why are all these people sitting at the same desks?" The advantages of pair programming have to be 200%+ than just one programmer doing it, because you're using two people. Done at the right time, pair programming can increase your solution/buck ratio; at the wrong time it can decrease it.