Wiki For CollaborationWare
How have I used Wiki as Collaboration Ware? What other things are possible? (How does it compare to using WeblogForCollaborationWare? Wiki Beats Weblog)
Context: TeamfluxCom notes on Problems With Traditional Communications
Summary: TeamfluxCom notes on way to use a TeamWiki.
I discovered wiki during my last days at MedScape (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.
We used TracWiki at Living Independently and DailyLit.
At Axiom Legal we used a TeamWiki as a key part of our Intranet. (I'm no longer there, but they're still using it.)
(Other technologies: MsExchange, MsOutlook (EMail, Group Calendaring, Public Folders), file server with too many MsOffice files (though many of those are correspondence and other "formal" documents, so it's really OK). We have a WebCrossing 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 Note-s (here's a sanitized [sample](/articles/Python Via IIS) 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.
RecentChanges 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 MsOutlook 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 Wiki Wiki Web: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 CurrentActivities page
-
make individual pages for appropriate projects, list them on CurrentActivites page
-
list "non-page-worthy" tasks directly on CurrentActivites
-
ideas for more granular tracking:
-
opposite extreme: write separate WebLog entries, referring to associated project page. Then project log can be re-created using BackLinks. 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 Development 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 Iteration 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 JavaScript 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 "AttentionBob". You keep the "AttentionBob" page open, and periodically hit the BackLinks button to see a list of any pages including that word. When you reply in a page, you take out the "AttentionBob" and write "AttentionBill", 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 RemoteWikiURL 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 GroupWare.
Ken MacLeod 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 SmallReleases. 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 MacLeod
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 ZwikiTracker.
Off to read the Group Discussion page.
Edited: | Tweet this! | Search Twitter for discussion
Made with flux.garden