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?

  • Mission for the project

  • 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 Team Wiki 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.)

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:

What would the goals of such a group be?

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.


Edited: |

blog comments powered by Disqus