Team Wiki

A WikiWiki being used by a team to keep up with what is going on. Not as useful in a WarRoom setting, but very useful when forced to do RemoteDevelopmentTeams?. -- BrianMcCallister

Compare/contrast ProjectWiki. I have set up about a dozen focused Wiki sites where I work, about equally divided between the TeamWiki and ProjectWiki variants. The TeamWiki sites (when successful) have a "long-term" view, and are used to capture "lore and oral tradition" that might otherwise be lost as long-time members leave a team to go on to other projects and are replaced by newcomers. This is typically information of lasting value, but not widely held. For example, documentation of a maintenance procedure that only has to be performed quarterly, but has to continue for the lifetime of a system. That kind of thing tends to become the "property" of a single team member, who performs it until s/he leaves the team. At that point, it gets turned over if s/he thinks of it, or it gets forgotten. By putting the information about how and why to do the procedure into the team's reference Wiki, the knowledge becomes the team's property (even if the assignment to do it remains with one person), and won't be lost even if the "owner" disappears without warning. (Granted, there are design flaws in a system that needs this kind of human process to support it, but we all know that such systems exist, and this can help deal with them.)

On a team that lasts over a period of years, with members rotating in and out, the TeamWiki can also be a repository of training material, and it can be useful to have a new team member spend a few days just browsing the TeamWiki and following the links.

In contrast, ProjectWiki sites tend (in my experience) to have more rapid updates than TeamWiki sites, with more attention to currency of information. They tend to swell quickly, and change rapidly at first, but usage dies out as the project moves to completion. The two most successful ProjectWiki sites I launched were major factors in the success of the projects they supported, and were retained for reference as archives of their projects. (Logs indicate that they do get consulted from time to time, even now, although nothing new has been written in them for ages.)

To the point about using a TeamWiki to stay in touch with remote teammates: I have direct experience with using a Wiki as a vehicle for communication/synchronization when teams are geographically distributed. A combination of email (for quick discussions with rapid turnover) Wiki (to capture the outcome of such discussions, and to keep track of various slow-changing items such as lists of milestones), and (occasionally) IRC kept our team (spread across three cities in two time zones) on track and informed about what each of us was doing. (Generally our conference calls were the least productive means of communication; I speculate that when it took the least effort to say anything, there was less pressure to say only useful things.) However, this was in a project setting, where the team was tightly focused on a near-term goal. I don't know whether it would have been as effective for this purpose (keeping people in different locations informed and in contact) over a long term.

See also PersonalWiki. In fact, two of my TeamWiki sites started out as (essentially) PersonalWiki projects: they were set up as team resources, but on each one I was the only user for the first six to nine months. It was only after I had accumulated a sufficient mass of useful lore and reference links that my teammates started to see the potential of the Wiki. Once I had demonstrated the effectiveness of the concept (by using the Wiki to document procedures and release plans, and by accumulating a great many useful links from our Wiki to other region's of our rich but sprawling and unorganized corporate intranet), others joined in, first to read what I had placed there, and then to contribute their own material.

The experience (with both TeamWiki and ProjectWiki variants) has made me think a lot about the value of having an EarlyAdopter or technology pioneer here and there throughout a company. You don't want everyone off chasing fads (many of which will never pan out), but it's a good idea to have a few people around who are willing to latch on to a new technology, accept the pain of getting it set up and working, take responsibility for keeping it available, smooth out the rough edges, spend time getting to know it and figuring out how to use it effectively, and gradually introduce it to others. The lost productivity of a few is paid for by the increased productivity for many, when those fads that do have some merit evolve into accepted and improved practices.

-- CameronSmith

CategoryWikiImplementation