What's your team's truck count? No, not how many SUV's do your people drive... Truck Count refers to how many key team members would need to be hit by a truck before your project fails. Not a very nice thought, but it gets the point across. It means, if a key team member leaves your team (and presumably the company) how would this adversely affect the project? Lower numbers are BAD.

About the best you can do is one less than the team size. The worst you can do is "1." Think about your project, and think about who is keeping the brain-share of knowledge. Are they passing it around the team, or does the knowledge sit under one person's cap? If so, that person makes your truck count lower and your project riskier.

Team knowledge sharing is a fine idea, but it's not always easily accomplished. We use tools discussed below for information sharing and actual knowledge transfer.

Tools
    First of all, let me just start out with: EMAIL IS NOT A TOOL FOR TEAM KNOWLEDGE TRANSFER. "Well, I sent you an email about that last week..." it's just not an effective mechanism. Don't be tempted to use it. Email should be for temporary and archival type information communicaton - NOT knowledge transfer. Here are some things that DO work.

• Wiki
• A Wiki is a good tool for a central information repository, allowing team members to add and update information easily and frequently. There are many wiki tools available, but mediaWiki currently is the leader. The ideal wiki site would allow team members to use it without having to "log in" as this is a barrier to getting the information into the site. Even more ideal would be the ability to have remote access to the site from home (with the proper security of course).
• Online team services like Rally, Scrumworks, and others
• Online team service sites allow individuals to have access to the stories, backlog, burndown, and other communication tools from anywhere. This removes a hurdle to information sharing by not requiring physical access or the hassle of having to fire up a VPN client.
  
• Pair programming, and promiscuous pairing
• Pair programming is probably the most effective way for knowledge sharing and information transfer in a team. Pair programming is an XP concept, but unlike Scrum, tenets of XP can be adopted individually on a team, rather than buying the whole program. Each tenet ads value on its own, even if others aren't adopted. Concepts like test-driven development, continuous integration, shared workspace are all good tools for development, but each ads its own value, and all are good for increasing truck count.
• Arlo Belshee calls it "promiscuous pairing" when a team doing pair programming switches pairing partners regularly, and frequently. He advocates pairing different team members together rather than the same set day after day. I have experimented with this on a highly performing team, and with the size of the team at 5 and the dynamic there, we decided that half-days were a good mix. After lunch we would switch pair partners, and information flow among the team increased without a large adverse affect on performance.
  
• Shared workspace
• Simply co-locating team members is a fine way for information sharing to occur organically. Just simply removing cubicle walls allows sounds and communication to flow freely. Removing physical barriers is an effective way to increase information flow and increase truck count.
  
• TDD game
• The pairing game is where one person writes a test, then the other person writes the code. Then, they switch. This is a very effective way to have both parties fully engaged.
  
• Code Review
• Reviewing code from other team members is a marginally effective way to get information spread across the team. I am not a big fan of code reviews, but I recognize that they are a necessary evil for those teams not actually doing pair programming. The review must be willing to put aside distractions and interruptions to concentrate on not only what changed, but also the whole of the code - making sure to understand it and verifying that it's doing the right thing.

These are just some of the things I have used for information sharing and helped my teams in distributing the brain share for a project. There are probably others as well, feel free to collaborate by adding your comments below.