On the HyperScope mailing list, Jeff Conklin 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 Dialogue Mapping 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)
- Avoid Yes No Questions (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 Dialogue Mapping 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 Dialogue Mapping 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 Shared Display 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 Visual Modeling 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. Michelle Bachler 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)