What is the best way to encourage communication in a team?

Question

I work in a medium sized team (20+ developers) where I believe communication amongst team members is not as good as it could be.

Like most teams, I suppose, we have several systems that we build and maintain. We also use dozens of varied tools in our work such as Visual Studio 2008, Subversion, Resharper, Tibco, TeamCity etc.

We also develop using an "Agile" methodology...and I put that in quotes since it seems more like "Rush to get this feature in asap...we'll have the spec for you in about a week...just start working on it now but be sure to unit test it and have it code reviewed by someone".

Because of this, we have systems that are poorly designed and thus become difficult to maintain....so we end up with a handful of people as "gurus" who are intimately familiar with the systems they created.

Additionally, because of the pace of the IT industry in general we are often required to use new technologies and the latest versions of the tools we develop in.

My point is not to complain and say "oh woe is me things are difficult"....rather my concern is that unless our team starts communicating better we're going to stay stuck in this rut.

Let me try to explain what I mean by communicating a little better....

Recently we just upgraded from VS2005 to VS2008...which is awesome in my eyes cause I like working with the latest technology. And we also moved from CruiseControl.Net to TeamCity...which is all well and good.

...but....we never really got any training on VS2008 or the new features of C# 3.0...and not even a memo about TeamCity... As IT people we seem to be expected to adapt and learn as we go.

Now obviously I can find that info out myself by reading blogs and following the latest news about the tools I use...which I do....but the practice of continuous learning isn't really practiced by everyone on the team so you end up with people using new features without really understanding them...

Additionally, our team has recently been instructed to start conducting code reviews...but without any guidance as to what that really means....at the moment it just means give your code to someone..anyone...on the team and have them look at your code...whether for two seconds or two hours its not really well established or uniform across the team....if they are even being done at all...

The same is true for writing Unit Tests...we've been encouraged to write them...but its not really been communicated team wide what the best way to write them is...so some developers try to write them, find it difficult, and either write poor unit tests or give up and decide unit testing is a bad idea...

The idea I've come up with to help improve the situation is to organize a series of meetings as a Developer's Forum...in these meetings a different topic would be presented by a team member with the remaining time being devoted to discussion amongst the developers.

One week the topic might be an advanced new feature of C# and the recommended best practices around it....and the next might be about Code Reviews and what to look for...while the next could be an introduction to an obscure legacy system.....the discussions could then be used by the developers to share their experiences and problems. Ultimately the aim would be to have a place where ideas and information can be freely shared amongst the developers.

I have got the buy-in from my managers and several of my fellow developers to get something going...but I have been told that such an idea has been tried before and eventually died out.

I want this idea to succeed and not be something that I'll push all by myself only to have it die when I eventually move on from this company.

How then can I encourage my team to communicate better? Does my idea of a developer's forum sound like a good idea? What can I do to prevent it from dieing out?

Is there something better that I can do instead that I'm not thinking about?

More than just starting a series of meetings....How do I encourage and influence my team to start performing as a team? I really enjoy my job and believe I'm working with an excellent group of developers...but I also really want to add value to the team in an area that I see is a bit lacking at the moment. How do I do this effectively?

Answer 1

Team spirit is hard to force. Most attempts to get people to work together better backfire. It needs to be nurtured and grown.

Rather than a series of meetings, how about a team lunch (on the company) once a month or so. Something informal which won't impinge on none work time. Nothing formal but a chance for people to talk to one another and 'bond'. If people are able to, a few drinks or a game of cards in the evening can help. It is important that it is voluntary and non formal.

Pair programming can help transfer knowledge, and help people to know and understand each other, so may be worth thinking about.

However the management style at your company seems to work against things.

"Rush to get this feature in asap...we'll have the spec for you in about a week...just start working on it now but be sure to unit test it and have it code reviewed by someone".

This leaves things very much up in the air. Someone has read about things that dev teams should do but is not willing to put the time (aka money) into doing things properly. This will leave developers disenfranchised and de motivated, which harms a team.

Answer 2

Its hard to give a definitive answer.. apart from trying out somethings and hope that some of them stick

Avoid local islands of knowledge - PairProgramming might work. If A signs up for a Task in an area where X has some expertise or clock-time, he could ask X to pair with him. The process of implementing the task spreads things in X's head, is a real-time code review and helps raise average team skill/expertise/code familiarity. It also encourages people to talk to each other instead of holing up..

Dynamic pace of tech evolution - Fact of Life... need to get used to it. Using Developer Forums, Lunchbox forums, Brown Bag Sessions, Wikis, Book Clubs, Online forums, etc could work. Depends on what the individuals in your team pick as their preferred means of ingestion. Work on feedback... if the team feels that they are benefiting from the developer forums, they will sustain it. If it dies out, think about why it didn't stick.. try something else with lessons learned..

Slack - an often missed aspect. Ensure that people have time to help someone out.. not perenially running behind a deadline.

Create an environment that encourages and facilitates people speaking out.. helping out others.. and then leave it to the individuals to gel together. Good Luck.

Answer 3

Perhaps your concern is a bit less about communication and more about the level of motivation in your team-mates and their willingness to learn. If so, I think you are right on track with the Developers' Forum idea. However, be reminded that motivation, especially in a intellectual field like programming, has to come from within the practitioner; the programmer has to innately enjoy using and engineering technological artifacts. Without such self-actuation, I do believe, it is a a huge challenge to get anyone interested in learning the latest toolset, the desiring the fanciest language and participating in most novel ways of creating software.

Go ahead with your planned meetings. See how they respond. If it still seems they are in it merely for the money, extract yourself from that place and seek an outfit where the sheer joy of programming is the engine that propels everyone (oh, and money should be good too).

Answer 4

The first thing is to break down all physical walls by moving the team to the same location, prefable seating everyone in the same room.

Second, start using release planning meetings. That is, your team in concert with the customer, estimates each story that needs to be developed for the coming release. I will improve communication between team members because they are discussion technical issues and problem solving together. They are estimating and, if done correctly, leads to consensus regarding estimates and design approach. Follow up the release planning with kicking of each iteration (one-week iteration is best) with an iteration planning meeting. This is where the team breaks down each story into a number of small tasks scheduled for implementation this iteration.

Third, start using pair programming. Dont force it, but encourage it strongly. Also, make sure that pairs are only pairing for a day or so. Ie rotate pairs. This builds collective code ownership and team spirit since it is "our code" not "his code".

Oh, and finally: Learn to always talk about "us" and the "team". Never point fingers.

Answer 5

How can you encourage your colleagues to communicate better? Lead by example.

In my company we often you the term 'to drive something'. Somebody needs to drive a project, needs to drive the testing etc. That means to take on the responsibility for this task and persue it actively. Do not just expect your colleagues to share information, show them what to do and how to do it.

When you find out some nice new detail about VS2008, share it with them. But be professional about it. Do not just tell it to the two guys you are having a coffee with later today, prepare a small presentation or word document describing your findings and communicate it to all team members. I definitely would prefer to give a short presentation instead of just sending them an email, but that may not be possible.

You can fit this in to regular informatione exchange meetings, but I think it is vital that you keep the same attitude in your day to day work. Don't just do it, live it.

(Oh my, I sound like one of those stupidly overpayed motivation coaches! Well, maybe they are right and deserve all the money ;-)

Answer 6

It sounds to me like your team is missing a technical lead.

This person would take guidance from management, and convert it into practical steps that the rest of the team can use.

For example:

1. You mention you use numerous products in your team, and sometimes update these with no notes or training being given to the team.
   The technical lead would document the products and how to use them, ideally on a wiki, so others can contribute, and would have experience in the new product, so they can help anyone as and when they need to.
   The technical lead would also provide guidance, be it an email, document, wiki article etc, on how to use the new product.

2. This person would produce guidance on how to do code reviews, after meeting with management, senior developers etc.

3. For any new developments, or major feature requests the technical lead would be involved with designing it, thus a peer review would take place, and knowledge would be spread amongst the team.

The key to all of this, is making everyone's job easier, and more productive. It's probably quite clear who this person is, as they'll be the most respected member, who everyone goes when they hit a wall. That person needs to be given some time to perform this role.

Unfortunately if that isn't you, then you probably won't have much luck in convincing people to change the way they work.

In addition it helps enormously to have a informal lunch once a month, football, or whatever where team members can bond informally.

Answer 7

• Colocate. Everybody in the same room encourages self-organization (via overheard conversation. You will have to factor the disturbance into your estimates however.
• Ban Instant Messaging/IRC for anything but the smallest thing. Or all together. You're not going to be popular (I don't like it either), but it will force people to start communicating in the open, and breaking up cliques.
• Have regular, quick, focussed, technical meetings. The daily standup is a good example of this.

Answer 8

There will always be people who will share your passion and join you. There will also always be developers who are the 9 to 5'ers. Nothing can be done about it.

If you have managment buy in, then run with it. Management buy in is what I would have figured to be the hardest. Hopefully as other come on board with you, the rest will fall into line. Good luck!