The Blue Oxen Way

Posted on Published by Eugene Eric Kim

Back when Chris Dent and I started Blue Oxen Associates, we often referred to something called the The Blue Oxen Way. It was something that we both understood and recognized, but that we never actually articulated. Over the years, I tried to rectify this, and I generated pages and pages of notes (including three years worth of rambling blog posts) in the process, to no avail.    (LVU)

Recently, Chris articulated his visions for “Wiki Everywhere,” where he referenced some of our early conversations. As I read it, I relived many of these discussions, and suddenly, it all clicked for me.    (LVV)

The essence of The Blue Oxen Way can be boiled down into three ideas, each of which form the framework for our entire philosophy about collaboration:    (LVW)

The Squirm Test    (LW0)

The Squirm Test is a thought experiment for measuring the amount of Shared Understanding in a group by observing the amount of squirming in a room. Shared Understanding (which is not the same as “same understanding”) manifests itself in the formation of Shared Language. Shared Language is a prerequisite for collaboration.    (LW1)

Much of the messiness of the collaborative process can actually be attributed to lack of Shared Language. Great collaborative design accounts for this rather than wishing it away, which is how most of us deal with it.    (LW2)

Shared Language is The Red Thread that binds all of the crazy things I’m involved with, from Pattern Languages to Wikis, from face-to-face facilitation to organizational strategy. The Squirm Test is a wonderful embodiment of Shared Language.    (LW3)

Be Less Dumb    (LW4)

If Shared Language is the tie that binds, then being Less Dumb is the state that we are all striving to reach. Why are we playing this game in the first place? To be Less Dumb, of course! As you go to bed every night, if you can’t look in the mirror and say, “Today, I became Less Dumb,” then you’re not doing your job.    (LW5)

Less Dumb is the negative framing of “augmentation,” but it sounds a heckuva lot better, and it embodies the same philosophy. Tools should make people Less Dumb. Processes should make people Less Dumb. How do we measure collaboration? One way is to see if we’re Less Dumb in the process.    (LW6)

That’s obvious, you say? If it’s so obvious, why do most tools and processes make us More Dumb rather than Less Dumb? And why are we so often willing to live with that? It may sound obvious, but are we really paying enough attention to this?    (LW7)

Bootstrapping    (LW8)

With Less Dumb and Shared Language (as embodied by the Squirm Test), we have our target and the glue that keeps us together. Our process — the way we get to our target — is bootstrapping. Bootstrapping is building on top of things that already exist, then building on top of that. (The notion of bootstrapping is also the reason why we called ourselves Blue Oxen Associates.)    (LW9)

The most vivid images of my best experiences collaborating have to do with movement — my actions resulting in other people’s actions, which result in even more actions, which inspire me to act further. This is bootstrapping at its best.    (LWA)

Purple Numbers are ultimately about building ideas on top of pre-existing ideas — knowledge synthesis (i.e. becoming Less Dumb) by reusing existing ideas. Also known as bootstrapping.    (LWB)

Visual Thinking and Shared Understanding

Posted on Published by Eugene Eric Kim

One of my favorite conference moments occured at the Computers and Philosophy 2002 conference, where both Bob Horn and I spoke. I sat next to Bob during the other talks and peeked over his shoulder as he took notes. That man is insane. My notes are barely legible scribbles; his are pristine visual diagrams.    (LEX)

A few years later, I got to work with Bryan Coffman at the MGTaylor 7-Domains Workshop. As with Bob, I got to see Bryan’s notebook and concluded that he also was insane.    (LEY)

Visual languages are extremely powerful and totally underutilized in collaboration today. Part of the reason for this is that the techniques seem inaccessible. If you can’t draw a straight line, you’re probably not going to be doodling your notes, much less doing it live on a whiteboard in front of a crowd of people. Tools like Compendium and Mind Mapping are great in this regard, but they represent only a fraction of what’s possible. (In the case of Compendium, I think it’s question-orientation is as important, if not moreso, as its visualization capabilities.)    (LEZ)

When I found out earlier this month that one of Dave Gray‘s mentors was Bob Horn, I told him I had to peek at his notebook. No problem, said Dave. He posts many of his sketches on Flickr.    (LF0)

Dave also told me about an exercise he likes to do at his workshops, which is to ask participants to draw a diagram of a toaster. You can see the results from a workshop he recently did in Toronto. I like this exercise a lot, because it shows the very different ways that people think about a relatively mundane device in a very concrete way. Each of those pictures are clearly different, but they are all also accurate.    (LF1)

This technique is great for building Shared Understanding, and there are all sorts of great variations. You can have people draw, build things, and so forth. Luke Hohmann had us design cereal boxes at DCamp last May that would make people say, “DCamp — gotta buy that conference!”    (LF2)

Michael Eakes recently blogged about a sixth grade exercise, where the teacher asked her students to draw Mickey Mouse from memory.    (LF3)

https://i0.wp.com/www.eakes.org/blog/images/mickeyposter-small.jpg?w=700    (LF4)

Read Michael’s analysis of the variation; it’s fascinating.    (LF5)

Developing Shared Language

Posted on Published by Eugene Eric Kim

Drummond Reed recently wrote about the Identity Rights Agreements session at last month’s Internet Identity Workshop. While the outcome was fruitful, Drummond wrote, “The biggest frustration was that after an hour and fifteen minutes we were just really getting started – we needed a good half-day on the subject.”    (KNJ)

Jamie Dinkelacker told me a similar story last year in describing a SOA gathering of gurus. The goal was to share knowledge and to advance the state of the art, but the participants spent most of their time arguing over the definition of “services.”    (KNK)

The problem in the first case was with expectations. The participants should have expected some ramp-up time would be necessary to get started, because they needed to establish some Shared Language. The problem in the second case was with process. The participants did not have an effective strategy for developing Shared Language, and thus, the latter ended up monopolizing the whole workshop.    (KNL)

Shared Language is a prerequisite to collaboration. Without Shared Language, we can’t collaborate. It’s as simple as that. When a group tries to collaborate without having Shared Language, the group will try to create it, whether it’s aware of it or not. This creation process is often frustrating and painful, and as a result, people sometimes try to skip this step or belittle the process. This is a problem. You can’t skip this step.    (KNM)

When designing collaborative spaces — both online and face-to-face — you have to build in time and space for developing Shared Language.    (KNN)

If you examine every good collaborative, face-to-face process for large groups, you will find that all of them generally recommend a minimum of three days. I haven’t found a rigorous explanation for why three days work so well, but the pattern is consistent, and we can certainly speculate. Much of it has to do with building in enough time to develop Shared Language. (Michael Herman, Open Space facilitator extraordinaire, has suggested that it’s less about the three days and more about the two nights — having our minds go through two natural work-process-rest cycles. I think he’s onto something.)    (KNO)

The first day is always about developing Shared Language. MGTaylor calls it the “Scan” day. Phil Windley calls it the “butt-sniffing” day. Regardless of what you call it, you need to design for it. It’s going to happen whether you like it or not. The question is whether or not it will happen effectively while leaving time for action.    (KNP)

There are two myths regarding how you create Shared Language. The first is that “shared” is equivalent to “same.” They’re not. Shared Language means that you understand how others around you are using terminology. Some level of sameness is obviously useful, but when you’re dealing with something relatively complex, sameness is both impossible and undesirable.    (KNQ)

I devised a metric several years ago called the Squirm Test that’s similar in concept to Wikipedia‘s Neutral Point Of View. The test is simple. Sit your team around the table. Have each person stand up and give a brief project description and status report. During the pitch, no one is allowed to talk, other than to ask clarifying questions. You have a perfect level of Shared Understanding and Shared Language if you make it around the room without anyone squirming.    (KNR)

The second myth is that creating Shared Language consists of creating a dictionary. That’s certainly one way to approach it, but it’s not the only way, and often times, it’s not the best nor the fastest way.    (KNS)

There are three elements to creating Shared Language:    (KNT)

  • Share individual contexts    (KNU)
  • Encourage namespace clash    (KNV)
  • Leave enough time and space to work things out    (KNW)

Sharing individual contexts is a fancy way of saying, “Know your audience.” Or, more accurately, know who you’re working with — their world view, their values, etc. You don’t have to use the same terminology the same way; you just have to understand what people mean and where they’re coming from. For some techniques on how to do this, see Collab:KnowTheParticipants.    (KNX)

I’ve written many times about how Wikis and tagging encourage namespace clash, which in turn encourages Shared Language. From a facilitation standpoint (both face-to-face and online), if you pose questions that stretch the mind, you also draw out namespace clash. MGTaylor is especially good at doing this with its Design Shops. Allen Gunn uses a technique called a spectrogram where you stretch a piece of masking tape across the room, ask a controversial question, then tell people to go to the place on the tape that represents their position on the question. You then ask people along the spectrum why they’re standing where they’re standing, and you give people the chance to move around based on other people’s answers. If you ask the right question, you’ll not only quickly get a great sense of your audience, but you’ll also draw out different interpretations of language.    (KNY)

Finally, simply scheduling time and space where Shared Language is the primary goal is useful. People are good at figuring out how to communicate with each other if you give them the space to do it. If you set unrealistic expectations on the first day of a three day event, then you just stress out your participants. If you spend the first day exploring broader questions, your participants may feel flustered or frustrated, but they will find that the work goes much more smoothly in the ensuing days.    (KNZ)

Developing Shared Language is an ongoing process. Doing actual work is one of the best ways to build shared context, which in turn builds Shared Language. The trick is to have stagger your work goals based on the Shared Language that already exists. The exercises you go through can become more and more focused over time, as the amount of Shared Language increases.    (KO0)

At the Blue Oxen Associates Tools for Catalyzing Collaboration workshops — one-day workshops with about 25 participants — we don’t do participant introductions. We assign teams and have people go straight into their exercises. However, we pay careful attention to how we assign the initial teams, and we structure the exercises accordingly. For example, at our January workshop, we started by pairing people who either already knew each other or were in similar fields, and we had them start their exercises immediately. We then grouped pairs and had them present their work to each other. Finally, we had a plenary session where each group reported on their work, followed by a plenary discussion. Our participants were engaged right away, and the shared experiences acted as an icebreaker, which made it easier to meet new people and to talk in our designated networking times (e.g. lunch). We also had online profiles up on our Wiki, so that people could find out more about the other participants before, during, and after the workshop. Several people commented afterwards about the lack of group introductions. All of them liked it.    (KO1)

Why I Love Compendium And You Should Too

Posted on Published by Eugene Eric Kim

I just spent two outstanding days at the Compendium Institute workshop in Washington, D.C. Folks, if you are interested in collaboration, you must learn about Compendium.    (JZU)

Compendium is a conversation mapping (or Dialogue Mapping) tool that, simply put, makes meetings better. When paired with a relatively straightforward methodology, Compendium can make a huge difference on the quality of your meetings.    (JZV)

But Compendium is about much, much more than meeting facilitation. If you scratch below the surface, you’ll discover deep thinking about collaboration, hypertext modeling, visual languages, Collective Memory, Shared Understanding, and the art of listening.    (JZW)

Simon Buckingham Shum had a great line at the workshop: “Compendium is like Excel for knowledge.” He’s absolutely right. Just as mortals can build sohisticated number crunching applications with spreadsheets, mortals can easily build useful knowledge applications with Compendium.    (JZX)

But Compendium is about even more than that! Compendium, to me, represents an incredibly rich community of practitioners, deep thinkers, and overall good people. I talk a lot about the importance of bridges — folks who speak the languages of multiple cultures or disciplines. Almost everyone in the Compendium community is a bridge of some sort. To be a Compendium guru, you need to have a knack for facilitation, a brain for visual modeling, and comfort with computers. Everyone in the community has at least two of these traits, and some folks even have all three.    (JZY)

Of course, the best measure of the quality of this community is that several members of the extended Blue Oxen family — Simon, Jeff Conklin, Al Selvin, Mark Aakhus, and Karl Hebenstreit — were at the workshop, and I fully expect others who attended to become part of the family.    (JZZ)

I first learned about all this at a two-day workshop on Dialogue Mapping in 2001 from the supreme guru himself, Jeff Conklin. Since then, I’ve blogged a bit and written a few papers about Dialogue Mapping and Compendium. The workshop this past week has motivated me to dump even more thoughts into the blogosphere. But my writing hasn’t and won’t do proper justice to the topic.    (K00)

The best way to learn about Compendium is to experience it for yourself, and then just do it. Fortunately, there are easy ways you can do this:    (K01)

Al Selvin, who along with Maarten Sierhuis, is responsible for Compendium, likens the art of facilitating with Compendium to playing jazz. A great way to learn how to play is to jam with others. How do you find folks to jam with? There are practitioners all over the world. In the Bay Area, there are lots of practitioners (of course) — myself, Jeff, Maarten (who’s doing crazy stuff with Compendium and the Mars project at NASA), Nick Papadopoulos, and others. In D.C., the good folks at Touchstone Consulting use Compendium every day with their clients, and they’ve built an active Community of Practice there.    (K05)

The best way to find folks is to join the mailing list and ask questions there. One outcome of the workshop is that we will probably convene an online jam session, so that folks anywhere can participate. I’m happy to jam with anyone who wants to learn — either face-to-face in the Bay Area or online. Contact me if interested.    (K06)

Finally, if you’re in the Bay Area, you should register for Jeff Conklin‘s upcoming workshop in Redwood City, November 29-30. If you’re a project manager, facilitator, or consultant, or if you deal with groups regularly (who doesn’t?), don’t wait. Sign up and go.    (K07)

Extreme Usability Redux

Posted on Published by Eugene Eric Kim

Another great FLOSS Usability Sprint is in the books. As usual, great people make for great gatherings, and this event was no exception. But we did have a new goal for this event, and it resulted in some different outcomes, many of which were related to this new notion of Extreme Usability.    (JOS)

I have three overarching goals with all of these sprints:    (JOT)

  1. Improve the usability of the participating projects.    (JOU)
  2. Build greater Shared Understanding between the usability and Open Source communities.    (JOV)
  3. Catalyze community collaboration.    (JOW)

Additionally, as an organizer, you also want to “hit a home run,” as Jeff Shults likes to say. You want people to walk away feeling wonderful about themselves and about the group at large. As with baseball, you’re not going to hit a home run with every event, but you’re constantly hoping for it.    (JOX)

I think we hit a triple with our first sprint. We had great camaraderie and positive energy, everyone learned tons, and all of the participating projects made tangible progress. In fact, in the past few weeks, I learned that we made even greater progress with “catalyzing community collaboration” than even I had realized. Kieran Lal, Jan Muehlig, and Rashmi Sinha have all been developing tools for remote usability testing, a critical prerequisite for Open Source usability, where projects are usually distributed. (Our next sprint will most likely be a Remote Usability Sprint, tentatively scheduled for late Fall.) Mimi Yin‘s experiences at the first sprint helped form the seed for her most recent thinking for Chandler. Mimi’s informal discussions with Dave Greenberg at the first sprint influenced the most recent release of CiviCRM, and they worked together more closely this week. Most importantly, the many report-backs generated buzz in the community and helped bring in new talent, like Tony Chang and Jing Wu. There was also room to improve, though, and we incorporated some of that learning into this past sprint. All in all, people walked away feeling good.    (JOY)

This week’s sprint felt like a double. Once again, our projects made progress, people were buzzing and learning, and I think people had fun overall. Nevertheless, there was a cloud hanging over everybody’s head, one that made folks a bit more uncomfortable and the process as a whole more challenging. The cloud was the result of a special goal for this particular event — defining Extreme Usability.    (JOZ)

An Aside on Event Design    (JP0)

We did not define Extreme Usability prior to the event, largely because none of us knew exactly what it was. I had opinions, based on feedback from the first sprint and my own personal experiences, but I didn’t want to dictate the design of the event based on my own biases. One reason for this stemmed from my growing faith in the power of collective wisdom. Another reason was that I didn’t want people worrying too much about whether they were “doing it right.” My main concern was for the projects to get better.    (JP1)

Gathering a large group of folks with diverse backgrounds isn’t the most efficient way to develop a methodology. The vast majority of developers knew very little about usability, and only a handful had ever practiced Extreme Programming. We had 25 people attend, including users. In contrast, two people — Kent Beck and Ward Cunningham — co-conceived Extreme Programming, and they had many years of software development experience between them.    (JP2)

The other complication, which we downplayed, was that this was not simply an experiment in software development methodology. It was an experiment in Open Source software development methodology, which introduced its own constraints. Extreme Programming isn’t rampant in the Open Source community, primarily because its tenets are difficult to practice in this environment. Who is the customer? How do you pair program? What does a 40-hour work week mean, when you’re writing code on the side?    (JP3)

Given all of these factors, it seems unrealistic to have expected our participants to have contributed consciously to the creation of a new methodology. Why, then, did we try? Why this format?    (JP4)

My framing of Extreme Usability to the participants provides some insight as to why we chose this event format:    (JP5)

  • Agile Programming is an acknowledgement that software development is a collaborative process, and collaboration is hard. Agile methodologies offer a framework for alleviating these difficulties. Iteration and validation, for example, is a way to build Shared Understanding.    (JP6)
  • Methodologies like Extreme Programming lack an explicit role for usability practitioners. Extreme Programming provides rudimentary methods for developers to collaborate directly with customers, emphasizing “soft” forms of communication rather than requiring rigorous structure. User-Centered Design, on the other hand, incorporates into the process a usability specialist who has a range of methods for understanding user behavior.    (JP7)
  • The theory behind Extreme Usability is that usability practitioners should be co-collaborators with programmers for the entire lifecycle of the development process.    (JP8)
  • The biggest roadblocks for developers in this process would be to open up their minds, willingly and sincerely embracing the usability practitioners as codesigners, and accepting the possibility that their assumptions about the users and the design might be wrong.    (JP9)

The challenge is developing the framework in which usability practitioners and developers collaborate. This sprint was a laboratory in which we could experiment with this framework.    (JPA)

Rather than impose a more rigid process up-front, I wanted to test a general premise about collaboration: Eliminating barriers is generally more empowering than problematic. Pair Programming is a perfect example of this. A lot of programmers (and managers) react negatively to Pair Programming the first time they hear about it, because they assume that programmers need to be isolated to work effectively, and that they will be unable to collaborate effectively without this separate space. Experience has raised serious doubts about that assumption. We see a similar phenomenon with Wikis. Most people still assume that we have to impose structure and authority or our information spaces will devolve into chaos. Wikis obviously challenge this premise.    (JPB)

I wanted to watch how developers would work with usability practitioners with no preimposed constraints, hoping that our collective observations and experiences would result in a more useful framework than I could have come up with on my own.    (JPC)

The event was successful in this regard, but it came at a cost. We placed a heavy burden on our participants by making this goal collective and explicit. It’s hard, even debilitating, to be self-reflexive about process while you’re working. This was most evident on our second day. Frustration was palpable among our participants, as they struggled to both work on their projects and think about process. That everybody stayed positive and productive was a testament to everybody’s great attitudes, and for that I am grateful.    (JPD)

What Is Extreme Usability?    (JPE)

The conclusion among most of our participants, in the end, was that what most of us practiced was not Extreme Usability. I concur. Nevertheless, it offered some clues as to what Extreme Usability might be.    (JPF)

It may be a misnomer, for one. Rashmi Sinha suggested that what we were aiming for was actually “Collaborative Usability.” I would go further and say that it was “Extreme Design,” centering attention on the design rather than the overall development methodology.    (JPG)

Other thoughts:    (JPH)

  • “Customers” are not “users.” Once a customer becomes a codesigner, he or she loses value as a user, because he or she becomes subject to major bias from the design process itself. We attempted to include “users” as codesigners, which was wrong. You’re either one or the other (and it’s okay for a “customer” to be a codesigner), but you can’t be both.    (JPI)
  • Pairing is good. We required each project to bring two developers, and we assigned two usability specialists to each projects. However, we did not mandate pairing, and there were also other people working with each project. By the middle of the second day, each of the projects had figured this out on their own. If we do a second Extreme Usability sprint, pairing will play a central role in the process.    (JPJ)
  • Extreme Usability is not about taking shortcuts. Sprints are. The two should not be conflated. Many participants from our first sprint said that their biggest takeaway was that informal usability was valuable. You don’t need to have a high-overhead (i.e. expensive) usability process to develop usable software. I think this week’s sprint reinforced that. At the same time, I think it’s important not to conflate the sprint format with Extreme Usability.    (JPK)

Usability-Driven Projects    (JPL)

We intentionally chose early stage Open Source projects to participate in this sprint, but in doing so, we were still propagating what seems to be a given with all Open Source projects: they are started by developers. That naturally tips the power balance towards developers. I would love to do a sprint where the roles were reversed. Usability practitioners could bring project ideas — perhaps with wireframes or workflows — and developers would come to help with the design and implementation.    (JPM)

In a similar vein, Mimi Yin had a great idea. There should be an “inverted Sourceforge,” a place where usability practitioners — not developers — could start Open Source projects.    (JPN)