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