TeamWiki

one of the WikiTypes; see WikiWikiWeb:TeamWiki

Update: see Hack Your Project Team With An Issue Tracker Wiki

Using Wiki For CollaborationWare, I usually start off with a TeamWiki, which might have info about multiple projects in it.

• In theory, if there's are some projects where I write in enough detail that Wiki Name-s will collide (e.g. lists of User Stories), I spin off a Project Wiki for each.
• In reality, this hasn't happened to me. I see a Project Wiki as more likely to be appropriate when it involves subsets of the members of multiple teams coming together.

I ran a hosting service TeamfluxCom at http://www.teamflux.com/

Hmm, what are the differences between running a TeamWiki for a Creative Network vs a Social Network?

What should be in a TeamWiki? See Org Writing Practices

• Strategic Context
• page for each project/initiative: goal/outcome (one-pager), progress notes, meeting notes, etc.
• page for each bit of the Shared Language that helps members communicate
• To-Do List, or at least a couple levels of deliverables - each item should be a Wiki Name to spin off a new page. I actually like an Issue Tracker Wiki that gives some structure to those nodes.
• Operations Manual documenting every job (that gets done more than once)
• page for each team member
  • which should be named to match their username id/cookie (so that RecentChanges links to them)
  • all members should use that naming when referring to that person (in wiki and in email)
  • each page often becomes a prioritized task list for that person, again spinning off individual pages
  • plus those pages act like a Scratch Pad where wiki-newbies feel more comfortable writing and spinning off new pages.
• I've dumped a Sample TeamWiki Page List

More details on how to use one

Identifying/resolving an issue/decision:

• when someone identifies an issue or needed deliverable, they document it in a page
• they initiate discussion by emailing the page to the appropriate people.
• discussion continues (via email, meetings, etc.) until someone thinks the matter is closed.
• the original page is updated to reflect the agreement. By rewriting a coherent document, logic gaps and inconsistencies become more apparent, so that they can be handled.
• that document lives on for easy future reference, and uses Wiki Name linking to connect it to related ideas.

Document standard procedures and checklists. This system makes it easy to update/refine them, as changes become necessary or new staff discover things that don't make sense.

Record brainstorming sessions. Regardless of how the original session is run, there's value in recording even the rejected ideas online because

• it encourages people to come up with more ideas shortly after the meeting (or for people who couldn't attend the original meeting)
• re-visiting those notes months and years later can help when a change seems appropriate.

Recording each team member's primary roles/responsibilities and current priorities. (Make a page for each team member, matching their ID. Whenever mentioning a person in a document, use the Wiki Name, so it links to that page.) This is helpful when new people join the team, or when identifying multi-tasking problems (when a person feels pulled in many directions).

Business planning. Start with high-level pages like Our Business Strategy, then break each down into narrow pages that are components of the high-level concepts. (The Demo Space shows this a bit.)

• For instance, if following a model like that provided in Geoffrey Moore's Crossing The Chasm, you might have:
  • a page for each Target Customer type
  • a page summarizing the selection process for a primary Target Customer
  • the Positioning Statement for that Target Customer. Potential pithy taglines for promotional communications aimed at that Target Customer.
• The same thing can then be done for various aspects of Our Product Strategy, Our Marketing Plan, etc.

Project planning and tracking.

• Each project gets a page defining its mission and other high-level info
• Each deliverable in the project gets its own page, and people journal their progress in achieving that deliverable.
• More detailed approaches are also possible
  • each project could get its own space
  • each task could get its own page

Technography: management of f2f meetings:

• page for the meeting listing its agenda
  • but the meat is in the individual pages connected to it

I'm wondering whether there's a need for a Virtual Community of the developers, admins, evangelists, and plain old users of TeamWiki spaces.

A lot of meta-WiKi sites focus on the mode of having a wiki which is open to editing by everyone. Meatball Wiki, etc.

I'm more interested in the use of wiki by a Telic collection of people. This doesn't have to be a business team, but I think the membership Membrane needs to be only semi-porous, if there's going to be any progress, Coherence.

Other groups that are close but different in focus:

• Social Software Alliance
• Blue Oxen

What would the goals of such a group be?

• To evangelize the use of TeamWiki spaces, so that there are more effective and enjoyable teams to join.
• To push developers and users toward a set of Best Practices:
  • what to do in the wiki and how
  • when to set up multiple wikis, and how to relate the two (WikiWeb, Overlapping Scopes Of Collaboration, SubWiki, Sister Sites)
  • how to work integrate with other media (Email Discussion Beside Wiki, AppWiki)
  • WikiEngine features needed to support such practices: Wiki Standards, etc.

Would this interest anyone?

Very much Interested --2003/11/21 03:46 GMT
There is a significant set of wiki users / evangelists that live behind corporate firewalls. There doesn't seem to be enough thinking about how to do this well. Would be nice to think through how to get a wiki started for teams too. There are a whole host of management objections I typically run into that we could address as a community a lot more effectively. --Ed Taekema - http://www.pycs.net/users/0000177/2003/11/19.html#P93

see Community Wiki:MailingListThenWiki --2004/02/05 22:57 GMT
for idea on starting out by doing most discussion via Email List.