How to motivate team members to share knowledge

Question

I am working in a small team. On the individual level we have well-set knowledge related to our day-to-day activities. Nevertheless I am thinking that if we could share our best practices successfully and train each other, we could save time and resources as well.

We started short joint meetings and other proposals in order to encourage the team to share their daily problems and solutions with each other, but I'd like to increase the speed of this activity. How can I convince the team members to be to take more initiative in knowledge sharing? Can I use more tools to facilitate the process?

Answer 1

I have always found it quite useful to have everyone physically close, ideally in an open floor-plan. That is, no closed offices, low cubical walls.

This kind of proximity gives rise, assuming the people are so inclined, of everyone seeing and hearing what is going on with every other member at all times. The moment someone encounters a new (for that person) situation, others become aware and can give input without delay.

Care needs to be taken. This kind of floor plan does increase noise which can be distracting. Again, the team needs to learn to adjust to it.

The goal is to increase awareness and increase communication. This kind of layout does both.

Answer 2

TL;DR

Motivation is a separate problem, and is largely about making the process appeal to team members' enlightened self-interest. The process, on the other hand, is definitely something you can improve.

Knowledge-Sharing as Process

The Scrum framework encourages knowledge-sharing and cross-functional teaming through a number of practices and framework-defined meetings. For example:

1. The Sprint Retrospective is a defined meeting for sharing knowledge about the team's process.
2. The Daily Stand-Up is a defined meeting for coordinating knowledge about the team's progress.
3. User stories provide a starting point for communications between team members who must share knowledge to achieve a team objective.
4. Pair-programming (or just pairing, if you aren't a software shop) is a practice designed to spread knowledge and experience throughout a team.
5. Code reviews (or their non-programming equivalents) that focus on how and why things were done a certain way, rather than what was done.
6. Adding team training as a defined deliverable to the schedule or Product Backlog to ensure that project resources are allocated for it.

Tools to Facilitate Process

Always define your process first, rather than build your process around tools. However, there are some general classes of knowledge management tools that you may want to evaluate. For example:

• Wikis to collectively edit and maintain knowledge.
• Centralized document repositories for manuals and how-to guides.
• Screen-sharing tools for pairing.
• Formal "lessons learned" documents and reports.
• Informal team demos of new or improved techniques.
• Code- or document-review tools for interactive feedback.

The important thing here is that your team and budget must support these things, whether or not you choose to automate them. For example, if your management team won't allocate time for knowledge-sharing, it won't matter if you have a wiki because no one will have any billable time to add or update its content.