Fri, Jun 09, 2006
Developing Shared Language
#
DrummondReed recently wrote
about the IdentityRightsAgreements?
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)
JamieDinkelacker 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 SharedLanguage. The
problem in the second case was with process. The participants did not
have an effective strategy for developing SharedLanguage, and thus,
the latter ended up monopolizing the whole workshop. (KNL)
SharedLanguage is a prerequisite to collaboration. Without
SharedLanguage, we can't collaborate. It's as simple as that. When a
group tries to collaborate without having SharedLanguage, 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 SharedLanguage. (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 SharedLanguage. (MichaelHerman, OpenSpace 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 SharedLanguage. MGTaylor
calls it the "Scan" day. PhilWindley 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 SharedLanguage. The
first is that "shared" is equivalent to "same." They're not.
SharedLanguage 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 SquirmTest that's
similar in concept to Wikipedia's
NeutralPointOfView?. 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
SharedUnderstanding and SharedLanguage if you make it around the room
without anyone squirming. (KNR)
The second myth is that creating SharedLanguage 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 SharedLanguage: (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 SharedLanguage. 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 DesignShops?.
AllenGunn 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 SharedLanguage 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 SharedLanguage is an ongoing process. Doing actual work is
one of the best ways to build shared context, which in turn builds
SharedLanguage. The trick is to have stagger your work goals based on
the SharedLanguage that already exists. The exercises you go through
can become more and more focused over time, as the amount of
SharedLanguage increases. (KO0)
At the BlueOxenAssociates 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)
/collaboration |
Posted at 1:06am
Comments
Comments disabled until future notice. If you'd like to contact me, use my i-name (=eekim).