How have I used WiKi as Collaboration Ware? What other things are possible? (How does it compare to using Weblog For Collaboration Ware? Wiki Beats Weblog)

Context: TeamfluxCom:ProblemsWithTraditionalCommunications

Summary: TeamfluxCom:WaysToUseThis

I discovered wiki during my last days at Med Scape (fall'99). I had my own notebook where I made notes concerning ideas and issues relating to picking an Application Server, Programming Language, Content Management System, etc. I pointed a couple people at these notes for their comment. But it was mostly under-cover.

When I was planning to launch a Project Flux (early2000), I was writing elements of the Business Plan and product plan in wiki. I only had a single partner, and I did all the writing.

At Axiom Legal we use wiki as a key part of our Intra Net. (I'm no longer there, but they're still using it.)

(Other technologies: Ms Exchange, Ms Outlook (EMail, Group Calendaring, Public Folders), file server with too many Ms Office files (though many of those are correspondence and other "formal" documents, so it's really [OK]). We have a Web Crossing Group Discussion server we run for other reasons, and considered it for internal discussion, but decided against it.)

We document our technical and administrative procedures in it (Producing Pretty Html Documents, Quick Books, Adding To Standard Forms, future Meeting Agendas, etc.).

We document process reminders to support our selling and service activites (Correspondence Library, Pitch Meeting Checklist, Client Service).

We record results of Brain Storming for our marketing communications (Axiom Taglines, One Sentence). That way new ideas can be dribbled in afterwards. And old ideas can be rediscovered much later.

We document alternatives and decisions as we tweak our strategic direction and manage our relationships (Our Strategic Choices, Work We Do, Referral Fees, etc.).

Many projects get their own pages, where we note planned tasks, issues and decisions, and WebLog our progress (here's a sanitized sample I've made public).

Each staff member has his own page. We define our general roles there, which helps when new people come in. We also note big things on our To Do List. This is particularly helpful for people who handle requests from multiple people, so they can juggle priorities.

Initially I wrote/edited all pages. Then I got the other techies using it for their tasks. Then a key salesman, for the Correspondence Library. Then the other admin folks, for their procedures.

Recent Changes helps see where there's been some action.

We still use Email Discussion Beside Wiki a great deal. Often I'll kick something off by writing a wiki page, then emailing around the [URL] with a request for comments. Sometimes I'll include some or all of the wiki page's contents in the message (drag and drop from a browser view into an Ms Outlook HTML message). Then, when an issue is resolved, I'll document that back in the wiki page. This seems inefficient, but my experience with other media for discussion (EMail, Group Discussion software) leads me to conclude that Summarizing Is Necessary: if nobody "sums up" a conclusion, then (a) there are often different conclusions in different people's heads, and (b) it's really messy to come back later and review/restate a conclusion. So I think this human overhead is unavoidable.

I haven't found Group Discussion within wiki pages to work very well. It's hard to keep threads moving, because it's hard to track changes, esp within a page. Ward Cunningham agrees - I have done my best to discourage dialog WikiWikiWeb:InFavorOfDissertation which offers a better fit to this medium. I've been overruled.

Task and project management is a bit of a hassle, to the extent that some key people still don't use wiki to track their progress. I'd like to build Project Flux, but don't have time. May just come up with some wiki practices to nudge things forward...

• make [Current Activities] page

• make individual pages for appropriate projects, list them on [Current Activites] page

• list "non-page-worthy" tasks directly on [Current Activites]

• ideas for more granular tracking:

  • opposite extreme: write separate WebLog entries, referring to associated project page. Then project log can be re-created using Back Links. At the moment I think that's too "choppy". If you're seeing blogbits flow by in an RSS reader, each piece could be too granular to have good context (unless you're keeping everything in your head). Likewise, starting from a single blogbit which you might hit from an internal search engine, it's hard to recreate the context around that bit.

  • compromise: for any sizable project, spin off separate pages for individual phases, tasks, or issues. Each of those becomes its own page where log notes can be entered (and discussions held). A more detailed way of describing that, using Extreme Programming vocabulary:

    • I have a [Tech Project Queue] page where I list all projects in order of attack.

    • Each ProJect gets a page.

    • On a Project page I list each User Story. This might start out being ordered on the basis of workflow, or by user, or something else that helps give context. Then further down the page I'll have a section for each Iterat Ion where I re-list the User Stories planned for that iteration.

    • Then each User Story page includes its description/spec, and a log of progress toward its completion, issues that arise, etc.

    • I might spin off an Issue Tracker page for each Engineering Task, but often I don't bother (and just use the issue-tracker for non-project tasks, work orders).

I recommend you continue to use EMail as a notification mechanism for initiating discussions. Write a good Subject and include the wiki page [URL] in the body. This has the advantage of allowing for urgency to be communicated.

• But what about back-and-forth during the discussion?

  • does it really need to be near-real-time, like with Instant Outlining?

    • hmmm, you could switch to Instant Messaging, and have the habit of typing in Structured Text, then "owner" of issue copies/pastes into the wiki page when done...

    • You could probably do some sort of "subscribe to this page via JabBer" model, where when turned on for you, Instant Messaging signals would be sent by the wiki server to subscribed parties whenever someone (a) began editing a page (so nobody else would) or (b) saved their edit (so others could reload to read). Also note that many wikis (including a newer version of ZWiki expose version-diffs, so you could find differences more easily, if that wasn't obvious)

  • it shouldn't be too hard to set up a page-reload header. I wonder whether there's a Java Script hack that could be used, so you could only turn it on for a given page when you wanted to?

  • but note above where I argue that disposable interactions probably need to be summarized to be worth saving. So doing the back-and-forth via EMail, with the appropriate party summarizing in a WiKi page at the conclusion, may still make sense...

• Ken Mac Leod suggests, in Instant Outlining, using flagging keywords. I want your input, so in that wiki page I include "[Attention Bob]". You keep the "[Attention Bob]" page open, and periodically hit the Back Links button to see a list of any pages including that word. When you reply in a page, you take out the "[Attention Bob]" and write "[Attention Bill]", so I will see the page on my list.

In terms of Overlapping Scopes Of Collaboration, one obvious model might be to have a separate wiki for each "team", or maybe "project" (depending on which entity was bigger).

• this can be messy when adding a peripheral participant. Right now we have a single wiki for the company and all its projects, since we're small and cross paths on everything. But if I have some contractor involved, do I want that person going through my entire wiki? I guess if I don't trust them (and have appropriate confidentiality agreements), then I shouldn't be working with them at all...

• for an organization with multiple wikis, cross-referencing is assisted via Remote Wiki U R L support. One could also support Sister Sites (maybe that's the wiki equivalent of Radio Community Server).

The above focuses mainly on shared document editing, which covers a lot of ground. But all unstructured data. For handling structured data (e.g. Sales Force Automation/SFA), see Wiki For Group Ware.

Ken Mac Leod says (Apr2'02):

For task and project management, I felt a wiki to be a natural fit for several of the Extreme Programming practices, and in particular the Planning Game tied with [Small Releases]. We had one page for roughly sorted tasks/stories, another page for a summary list of major stories for the next major release, and we put a list of iteration pages on the front page. The iteration list is basically "one current" iteration, and the history of iterations. On the front page, the iteration list was the iteration number and one line of the major stories to be completed in that iteration. The iteration page then held admin metadata for the iteration, the full story list with final iteration estimates of time, and a link to the acceptance tests page.

The real trick, which meshes with Extreme Programming anyway, is that one has to get out of the project management mindset that 1000 things need to be tracked at once.

The only thing that gets tracked with any real detail is what occurs in "this" iteration (past iterations maintain that level of detail as history). Future tasks are just labels, no metainformation, no assignment. Bugs are attacked with extreme prejudice.

I'd post the link, but it seems to be down right now :(

On Instant Messaging -> WiKi, there's a quickly growing utility called [Daily Chump] http://usefulinc.com/chump which is an IRC bot that takes messages in a chat and creates a weblog out of it (original idea by [Bijan Parsia]). Current work is on integrating it with RDF, but integration with WiKi is also a common idea. --Ken Mac Leod

Bill,

Thanks for the resources. I apologize for dropping the ball on Outlining months ago.

Now the ZWiki has page acquisition and multiple ZWiki's can be nested, I'm feeling that localizing projects to many Wikis will be easier than all on one.

Looking forward to hearing your comments on this, and [Z Wiki Tracker] .

Off to read the Group Discussion page.

• ZWiki:DeanGoodmanson

User Options Recent Changes Help Page