How do you build a culture of collaboration in your team?

Question

We've recently moved to using the wiki in our team. Earlier, we thought people couldn't contribute because it was difficult to. However, having a wiki (3 months now) hasn't helped as much as we'd hoped. Most folks still put it off as 'not my job'. How do I encourage my team to contribute to the wiki?

NOTE: One useful resource I found in this regard was wikipatterns.

EDIT: In response to the first answer below, let me modify the requirements somewhat. The solution I am hoping to find must be:

1. Positive
2. Self sustaining - it must not need continuous intervention.

Just thinking out loud: stackoverflow itself is an example of such a system. Systems similar to Badges and Reputations could be adopted within teams as well.

EDIT: In response to the comment to this question. I'd take any kind really. We don't share information. Almost all domain knowledge is available only by consulting a select few.

Also, a note to all the people who've answered: Thank you :). Almost every answer has been useful. One that said we should reevaluate whether the team even had the time caused some introspection. Have requested management to actually allocate effort/time for documentation.

Answer 1

We had a similar issue at my workplace, a small web application development company.

The way around it, as simple as it sounds, is to make it part of the job description. If people are still using the excuse that they "don't have time" then look at what expectations you're setting. Are you adding workload to your staff without reducing it in other areas?

We implemented a policy of writing things that you learn into the wiki, as you learn them. The idea being that once the "company" has learnt something it should be retained even if the staff member leaves. Explaining this to the employee might help them understand your desires.

Answer 2

"Using wiki" is not a goal itself. It's just a fancy technology, so it should have a mind behind. What value does it contribute to your team? Is it some shared knowledge? Or is part of some public relations?

if it's the first one, you know, programmers love to share knowledge (look at this site as an example). But they should know, that there's some guy on the other side who needs their expertise. So, you can consider etablishing some system based on questions and answers.

Answer 3

1 Lead by example, you need to be posting good articles. Your other team members can be horrible critics, and will pick on any spelling or other errors. Handle this by proof reading, and producing many articles.

2 Hire right people, you need a core of two or more, who also post good articles. One others see the core in action, others will follow. Mediocrity needs to see examples. Once ambition to make better articles kicks in your Wiki will bloom.

3 Make sure team members have to produce development plans: a) Plans needs to goto the Wiki b) Part of the plan should detail, what documentation artefacts are to be produced and put on the wiki, and which are in customer readable format e.g. PDF. Them make sure the wiki has an articles that references the PDF. Absence of action becomes clear.

4 You will then see a linkage between those of don't contribute and poor performance. Document your disciplinary procedure on the wiki. Documenting whats expected is an important step, you will need to resort to it less often, and will improve performance.

5 You are now building a library, it will become a muddle unless you enforce good practice. You will get "Oh I posted that on the wiki" and and filed under pizza suppliers. To handle this see item 4!

6 You can use technology to make a wiki, but your staff have to have brains, you give the guidance, encouragement and also supply the discipline.

7 You may also need to review why you want the wiki, and what's its business purpose, this should set your strategy, how much effort you put in and the effort expected from others.

EDIT: Clarification on logic: Build into the development process the need to plan and document as tasks progress, require transparency, prevent code/task hiding. A level of wiki usage will be required from all staff. Then if staff are not collaborating you probably have the wrong staff, the inverse is true with the right staff the wiki really works, and is an impressive resource for all. Without a visible disciplinary procedure average staff find it easy to do what the below average staff try to do: not document and not plan.

Answer 4

If your team is small and you are communicating just inside it, forget the wiki. Try something like coding dojos, lighting talks, some development brainstorms and, more important, get out of the office. Is good when people launch or drink some beers together because they can talk more freely.

If you need to communicate with other teams or areas, or if you are documenting something, try tools where the collaborations starts small, per instance, a blog where they could just share a link to an article or whatever. Give them some positive feedback when talking face to face and, later, give them example writing more elaborated texts.

my two cents.

Answer 5

We chose tools that the developers were comfortable with or worked well with the current environment. We tried using trac (an open source wiki system) and no one ever used it and its because they would have to go to a website, login, find the page to edit, etc...

Since we are a .NET/Microsoft shop we've moved to using Microsoft OneNote and our developers have started to utilize it as just another tool that they utilize on a daily basis.

You could try setting up a private blog and have the developers post to that insead, most likely they use some kind of editor that has a plugin to post blogs.

Another option is to reward them for documentation/wiki updates (opposite of "do it or you're fired"), if they've been keeping the wiki up to date, buy them lunch on Friday?

And the final way is to hire not only by skill but on personality as well... make sure everyone on the team meshes well and you'll be guaranteed great collaboration.

Answer 6

The first question to ask is why people don't use the wiki. For instance if you have consultants working for you, then sharing knowledge with consultants from other companies is against their professional interest. You simply aren't going to get them to do it.

Assuming that that is not the case, I'm going to guess that inertia has a lot to do with it. When you're staring at a blank wiki page, it is kind of daunting. When added to the fact that people don't like writing documentation in general, you're going to have a lot of inertia.

One way to get over that inertia hump is to be really specific on when things must go into the wiki. For instance you might say, "The next time someone has to reinstall our development environment, keep a log of everything you had to do, and all of the questions you had to get answered, in the wiki." Make sure that happens. The time after that, make sure that the person doing the reinstall reads the wiki. Writing stuff in the wiki is not a lot of work for the first person, and what is written will be great for the second.

Another good example is that you could have an incident log in the wiki. Any time there is a problem on production, after it is resolved you need to log that it happened, when it happened, what happened, what the cause was, and what the fix was. After a while that log will prove its worth.

Once these practices are established, they are easy to maintain and people are likely to start finding their own uses for the wiki. But you have to get people using it, and get a critical mass of useful information in there before people start to feel that it is useful.

Answer 7

My experience of introducing a wiki into two different development shops, both with 20+ programmers, is that some - the minority - will take to the wiki like ducks to water, but the majority will ignore it for the most part.

Sad but true.

I speculate that a major factor in the slow/non-existent take up of writing or editing articles is simply that many of these programmers are

• intimidated by their more expressive peers,
• fearful of displaying poor English/writing skills,
• not excited by the idea since their ways are set,
• not motivated by knowledge and,
• see it as extra work.

For the minority it is a godsend, but for the majority it's just another collection of documents and all that entails for them.

@ICW makes some interesting points which I'd like to address;

Leading by example does not help as much as you might expect, especially if the leader writes well. It magnifies the weaknesses of the poorer contributions.

Poor performance might be correlated with reluctance to use the wiki, but in my experience threatening disciplinary action for "lack of enthusiasm" is counter productive. Remember the maxim, "the sackings will continue until morale improves..."

Answer 8

Phase 0 (Start up). Obviously pick the right tool for the job. Key recommendation: Do allow anonymous contribution/creation of content from the start. It's amazing how having to create a login puts people off.

Phase 1 (Evangelise). Encourage 2 or 3 people to be principle contributors and evangelists. Don't worry so much about persuading everyone to the use the resource at first. As a small group of enthusiasts, start populating the Wiki and in email start linking to the Wiki as appropriate. Do not start wholesale migration of legacy information (from old intranet sites) to the Wiki at this point.

Phase 2 (Review). After a few months have a review. I would hope you have a few more contribitors than your 'core' users. Try to openly assess whether the Wiki is better than previous communication mechanisms. Importantly you should encourage non-users to participate in this debate, try to make sure they aren't drowned out by the early adopters.

Phase 3 (Replace). Assuming you did decide to continue with the Wiki after your review, now start to replace legacy websites/content with the Wiki if necessary i.e. change DNS set-ups, move old websites in to a read-only state, ensure backups are in place and the IT department support is in place. The aim here is to migrate the 'I used to do it like this' crowd.

Phase 4 (Culture). At this point you've established the Wiki technically. Anyone who is publishing read-only information should be distributing content using the Wiki rather than email e.g. build/integration/test results or status.

Talk to the people who don't seem to use it as much as others. For some they may have the perspective that they have nothing to add, because some people are voracious publishers. This could be the case!. Try to encourage them to keep theirs notes in a personal area on the Wiki, help them to understand the markup language or demo a WYSIWYG interface. For people who should be publishing more than they are, that's a job for management/personal-development plans.

Answer 9

We introduced a wiki for collaboration in a small team, and it worked well.

The main thing to emphasize is that developers should using the wiki to keep notes as part of their everyday job. Updating the wiki should not be considered a separate task from normal note taking - "oh well, I will update the wiki later". Record information in the wiki NOW, as you work, even if the notes are messy. Once the information is stored, it can always be tidied up later.

When anyone on my team asks for information I just tell them to read my notes in the wiki. If the notes are wrong or incomplete, I tell them to correct it or add their own notes ready for next time.

Answer 10

The question is not quite clear what information is going into the wiki, so I will deal specs, documentation, and everything else. At both the company I work for now and the previous company I worked for we wrote specs and documentation in the wiki, which leds organically to other stuff being put there too. It make take some work by you as a team member to encourage others to use the wiki, but before too long people will use it on their own.

Specs

Not all developers write specs, but almost every company writes specs or something equivalent. So if the person or persons writing specs is asked to put their specs in the wiki, then people will start to use the wiki. Since specs evolve over time, they are a natural fit for wikis, because of the change tracking that is built-in.

Documentation

We all have to write documentation. It isn't always fun but it is something we should do. Documentation doesn't just include documenting code, but things like server deployment information or push logs or anything that needs to be written up. This information isn't hard to get into a wiki either, but it does have to be approached a little differently. One of the best ways to get documentation into the wiki is just to ask.

"Hey Jim, can you write a short article in the wiki about how to use that awesome new logging system you wrote."

The key is to try to get useful information into the wiki. Jim just wrote a logging system and telling people how to use it is useful so he is more likely to see the practicality of writing something up. Other people are going to see the utility too.

Everything else

Don't bother asking programmers to put anything else in the wiki. Documentation and Specs are such wide categories, that if it falls into another category, it probably is not worth the effort.

NOTE: You may want to put in a little effort into which wiki you pick. Some wiki's have great formatting but usually sacrifice editability, others are editible but don't offer much in the way of formatting. Remember that wikis are tools, and you want to choose one that gets in the way as little as possible.

Answer 11

If the knowledge you want to spread is indeed about some code, then face-to-face code reviews may be an option. Each developper, preferably before he commits, should ask for a few minutes of another developper that would come and look at the code.

Answer 12

Hi Vivek, One thing that TeamWIKI lacks is that it looks uninteresting and too Geeky. The content presentation must be improved, also people should be engaged in adding content.

We need to use "Head-Fake" technique to make it more popular. thats why i asked you "What type of content can we add on wiki.."

some more graphics, videos (Even Tech talks) will bring in lot of popularity and input efforts from our team.

Cheers!!