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:
- The Sprint Retrospective is a defined meeting for sharing knowledge about the team's process.
- The Daily Stand-Up is a defined meeting for coordinating knowledge about the team's progress.
- User stories provide a starting point for communications between team members who must share knowledge to achieve a team objective.
- Pair-programming (or just pairing, if you aren't a software shop) is a practice designed to spread knowledge and experience throughout a team.
- Code reviews (or their non-programming equivalents) that focus on how and why things were done a certain way, rather than what was done.
- 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.