Wed, Apr 19, 2006
Recent Dialog Mapping Lessons
#
On the HyperScope mailing list, JeffConklin recently
asked how we were using Compendium for the project. We've been
using it for the design phase of the project, walking through
scenarios, capturing requirements, and developing specifications. I
started the process by developing a template for the project --
loosely based on previous projects -- and by seeding the map with
content from asynchronous sources. (KFU)
I first presented the map at our weekly face-to-face meeting
two weeks ago, and
it's continued to be the centerpiece for our discussions ever since.
Other than the initial seeding and nightly refactoring, all of the
content was generated during these group meetings. After each
refactoring, I would post new versions of the map to the
web. (KFV)
Now that we've basically completed the scoping process, I'm going to
convert the map into a design document (on Augment!).
Compendium isn't scheduled to make a reappearance at our meetings
anytime soon, but you can be sure that if the need arises, I won't
hesitate to break it out. (KFW)
A few years ago, I published a
case study on
DialogMapping that described my early work in this area. I've
continued to apply a lot of the lessons learned from those very early
experiences. Here are some standbyes: (KFX)
- Take breaks (KFY)
- AvoidYesNoQuestions (KFZ)
- Multiple maps are your friend. When a map grows too large, (take a
break and) make a new one. (KG0)
- The map should be another participant in the meeting. The physical
location of the map is critical to its success. (KG1)
Here are some new and old thoughts on DialogMapping based on my most
recent experience: (KG2)
- The fact that so many early lessons are still relevant should be
further encouragement for people to give DialogMapping a try. The
first few times I did it, it was hard. Once I took those first
lumps, however, I shifted into an expert usage very quickly. Once
you've gained this experience, the tool is invaluable. (KG3)
- In that early paper, an observation I made without comment was that
I rarely used Argument nodes (Pros and Cons) in my early maps. Over
the past five years of using Compendium, that pattern has held
true. However, when I have used Arguments, they tend to be Pros
rather than Cons. With the HyperScope map, I used Cons much more
frequently. This reflects the circumstances of the project. We're
replicating an existing implementation that all of us agree is
fantastic. We also have a very tight schedule. Most of our
discussions have centered around implementation difficulty and
desired constraints, and so naturally, things tend to be framed as
Cons. (KG4)
- I think that a low percentage of Argument nodes in a map indicates
expert usage. In meetings, Arguments are often a reflection of
group politics rather than of logic. Reframing Arguments as
Questions and Ideas depoliticizes the discussion. (KG5)
- When I first start using Compendium with a group, I never
explain the tool. I just use it. People find it very natural to
follow (assuming you've positioned your SharedDisplay properly), and
they often take ownership of the map very quickly. The one thing I
do find myself explaining on occasion is that an Idea is just an
Idea. It is not a decision, and its presence indicates no value
other than that someone in the group proposed it (which is not to be
underestimated). (KG6)
- You know the process and tool are working when participants start
saying, "Make sure you capture that," or, "Can you put that there?"
It's a sign that they consider the map a participant and that they
are taking ownership over its content. It also makes the
facilitator's job easier. (KG7)
- The resulting map is an artifact of the discussion, and as such,
it's more useful for participants than it is for nonparticipants.
Folks like the fact that the maps are available, but they don't
recognize the value until I walk through the map with them. More
importantly, those who have participated in the meetings (and hence,
the map's development) have found it extremely useful. (KG8)
Here are some new and old thoughts on Compendium, the tool: (KG9)
- Compendium calls Idea nodes "Answers." I understand the logic
behind this, but I think "Idea" is a superior framing. This is
partially captured by the fact that the node is represented by a
light bulb, but I'd still like to see the name changed back to
"Ideas." (KGA)
- I used Decision nodes a lot for this project, which was natural,
since this was a scoping exercise. I also made a big show every
time I created a Decision node. This shifted us away from
discussion mode, which may sound obvious, but it had a powerful
effect on group participation. It was a group acknowledgement that
we had captured the relevant issues and that we were ready to move
on. (KGB)
- After the last
Compendium workshop, I resolved to add some VisualModeling?
techniques to my Compendium usage. I've managed to incorporate
it a bit in other projects, but it hasn't been useful at all for
this project. I love the idea, but Compendium isn't optimized
enough for this kind of usage for me. (KGC)
- Compendium still has some subtle but annoying bugs, mostly
related to layout. MichelleBachler? has done a great job of
stabilizing and improving the code, but the project could definitely
use more development resources. (KGD)
- My number one most desired feature: A slider bar that cycles through
previous versions of your map. It should work with exported maps too. (KGE)
- Speaking of exports, using Compendium to work on the HyperScope
really emphasizes the utility of things like granular addressability
and applying viewspecs on a single document, features that don't
currently exist in exported maps. (KGF)
/collaboration/tools |
Posted at 4:37pm
EEK Speaks
A blog about collaboration, community-building, and the various
goings-on at Blue Oxen
Associates, with occasional digressions on food and other vital
matters.
Subscribe
Comments
Comments disabled until future notice. If you'd like to contact me, use my i-name (=eekim).