Obstacles in Dialogue
Robby Russell
Topic?
What are some elements in group interaction (clients, colleagues,
users) that prevent healthy DIalogue from taking place?
David Goodlad
The biggest element that I've seen that harms dialogue is an emotional
attachment to some idea or decision. I'll admit that I'm guilty of
this at times, as are most other people.
When people are emotionally attached to one particular point of view,
they have a difficult time making objective, rational decisions. For
example, developers often get attached to their code, and if any
decision is being discussed that would affect that code in what they
see as a negative way (changing major decisions they made, rewriting
some pieces, etc), they will listen but not hear any of the arguments
for that decision.
How many of you have felt yourself get frustrated when someone seems
to be "attacking" your work?
Dave
--
Dave Goodlad
dgoo...@gmail.com or da...@goodlad.ca
http://david.goodlad.ca/
James Adam
> users) that prevent healthy DIalogue from taking place?
The biggest problem that *we* have is semi-literate users thinking too
soon about implementation details about the solution, rather than
considering the true nature of the problem instead.
Far too often we come across clients who are stuck in one particular
mode of thinking, in that the "know what they want", regardless of the
value that we might be able to give (in many cases, the *true* value
of our work) to rationalise their process and produce a way of working
that genuinely helps their cause, rather than just saving them <x>
minutes each day inputting figures into some Excel spreadsheet...
So, in a nutshell, thinking too early about the
solution/implementation in the dialogue. That's a killer.
--
* J *
~
Robby Russell
On Oct 20, 2006, at 7:11 AM, David Goodlad wrote:
>
> On 10/20/06, Robby Russell <ro...@planetargon.com> wrote:
>>
>> I'd like to open up a brainstorming discussion, feel free to join in.
>>
>> Topic?
>>
>> What are some elements in group interaction (clients, colleagues,
>> users) that prevent healthy DIalogue from taking place?
>
> The biggest element that I've seen that harms dialogue is an emotional
> attachment to some idea or decision. I'll admit that I'm guilty of
> this at times, as are most other people.
I think it's safe that most people are guilty of this. It's no
surprise that Buddhism teaches that elements such as attachment lead
to suffering. I think it's fair enough to say that Dialogue suffers
in the same way that humans suffer whenever attachment is present.
Not only are we responsible for being aware of our own attachments,
but we're also responsible for helping people see their own
attachments. Unfortunately, not everyone is thinking about these
things... so perhaps there is a need for some techniques/patterns for
working with those who are staying attached to their ideas.
This definitely requires a lot of thought to process the various
difficulties in pointing out something like to someone in a mindful
manner.
> When people are emotionally attached to one particular point of view,
> they have a difficult time making objective, rational decisions. For
> example, developers often get attached to their code, and if any
> decision is being discussed that would affect that code in what they
> see as a negative way (changing major decisions they made, rewriting
> some pieces, etc), they will listen but not hear any of the arguments
> for that decision.
I'd guess that when we're seeing things evolve in a project and
things appear to be _stable_ in it's current state... we're very
cautious (with good reason) to want to disrupt anything. However, we
also are supposedly following best-practices and responding to change
is what Agile is all about. ¿Correct?
When you're faced with a situation like this and you're trying to
convince others to change something... then you're already leaving
the realm of Dialogue. Healthy Dialogue requires all parties to leave
their baggage at the door and _Get Real(tm)_. If anything, explore
all possibilities that are being presented and really see what
options exist. Don't worry so much about how to get from x to z, when
you're discussing z. If z is compelling enough of a decision to move
towards... you can then have a Dialogue about how to get there
together. Until then, don't worry about implementation details to get
there. Discuss the problem(s), solutions, and we'll work together to
implement it.
> How many of you have felt yourself get frustrated when someone seems
> to be "attacking" your work?
Me! Just kidding... no seriously... I am guilty of this quite often.
-Robby
--
Robby Russell
Founder and Executive Director
PLANET ARGON, LLC
Ruby on Rails Development, Consulting & Hosting
www.planetargon.com
www.robbyonrails.com
+1 503 445 2457
+1 877 55 ARGON [toll free]
+1 815 642 4068 [fax]
Robby Russell
On Oct 20, 2006, at 7:34 AM, James Adam wrote:
>
> On 10/20/06, Robby Russell <ro...@planetargon.com> wrote:
>> What are some elements in group interaction (clients, colleagues,
>> users) that prevent healthy DIalogue from taking place?
>
> The biggest problem that *we* have is semi-literate users thinking too
> soon about implementation details about the solution, rather than
> considering the true nature of the problem instead.
>
> Far too often we come across clients who are stuck in one particular
> mode of thinking, in that the "know what they want", regardless of the
> value that we might be able to give (in many cases, the *true* value
> of our work) to rationalise their process and produce a way of working
> that genuinely helps their cause, rather than just saving them <x>
> minutes each day inputting figures into some Excel spreadsheet...
We deal with this all the time. Clients do it, users do it, even
developers do it... myself included. We're dealing with this on one
project where the client has an existing application that we're
trying to build a replacement for (not a rewrite in a new language).
When we're trying to identify the problems that software is trying to
solve, they often refer back to their older application as a
reference and explain what it didn't do right, rather than discussing
the problems that even that older application was attempting to
solve. It's difficult at times to work with them to see beyond that
other implementation and in many ways.. we don't want them to think
too much about implementation. That's what we're here for. ;-)
Brian Ford recently wrote an article[1] on his blog and said...
> When it comes to software, I find that the single most difficult
> thing for anyone to do is think outside of the Feature Fantasy.
> This applies to everyone, developers, designers, clients, users,
> people. Everyone. With a breathless hop, skip, and jump, we leap
> right over the problem, the solution, and into some particular
> implementation. It’s so automatic I would have assumed that we’d
> been taught how to do this in specialized classes since grade
> school, with some folks getting advanced university degrees in it.
Trying to find effective ways to communicate with people who are
suffering from what I am now going to call "implementationitus"[2] is
no easy task. We find ourselves relying on analogies, examples of
problem statements from books like About Face and the various
collection of books/articles that focus on gathering requirements.
> So, in a nutshell, thinking too early about the
> solution/implementation in the dialogue. That's a killer.
What techniques does everyone try to work together with the person
suffering from implementationitus to take the next steps of breaking
down the problem?
[1] http://rubyurl.com/JEn
[2] you heard it here first! http://www.google.com/search?
q=implementationitus
I'm really enjoying these discussion!
-Robby
--
Robby Russell
http://www.robbyonrails.com/
http://www.planetargon.com/
Robby Russell
On Oct 20, 2006, at 6:45 AM, Robby Russell wrote:
> What are some elements in group interaction (clients, colleagues,
> users) that prevent healthy DIalogue from taking place?
DiaHogs!
Some people have a habit of talking too much without getting enough
feedback throughout their process of explaining a concept, which can
often come across as a monologue in the middle of a dialogue.
I was reading online about some various techniques for collectively
insuring that everybody has an ~equal amount of participation in
Dialogue. There was one idea that I thought was interesting...
pennies. Give everybody an equal amount of pennies and for every
minute you talk, you pay a penny. The discussion isn't over until all
pennies have been used.
Sounds like something that might fun to explore... but I can't
imagine handing my clients a handful of pennies at the beginning of a
meeting.
So... I see avoiding monologues as an obstacle to healthy Dialogue.
- Robby
Brasten Sager
> users) that prevent healthy DIalogue from taking place?
Fortune-telling the user's reaction.
"The user wouldn't like this."
"This user wants this button there."
"That would confuse the user."
Of course, user opinion should be critically important, but in my
experience it's often used as a veto that doesn't have to be
explained just because someone doesn't like an idea. I've done this,
myself.
This seems to happen most often when the client is not the user. In
this case, it's almost humorous what the client thinks the user has
an opinion on. On one project, the OR/M library, application server
and database server were all chosen exclusively by the client
invoking "user opinion."
Josh Knowles
What are some elements in group interaction (clients, colleagues,
users) that prevent healthy DIalogue from taking place?
One of the biggest problems I'm continuously having to overcome is physical proximity. I'm a firm believer in kicking off a project with a face-to-face meeting, but when working remotely, and not having an on-site customer to easily communicate with your skills has a communicator must be greatly increased.
For those of you in a similar situations, what tips/techniques have you found to enhance and sustain a successful dialogue?
--
Josh Knowles
joshk...@gmail.com
http://joshknowles.com
Robby Russell
On Oct 20, 2006, at 2:40 PM, Josh Knowles wrote:
>
>
> On 10/20/06, Robby Russell <ro...@planetargon.com> wrote:
> What are some elements in group interaction (clients, colleagues,
> users) that prevent healthy DIalogue from taking place?
>
>
> One of the biggest problems I'm continuously having to overcome is
> physical proximity. I'm a firm believer in kicking off a project
> with a face-to-face meeting, but when working remotely, and not
> having an on-site customer to easily communicate with your skills
> has a communicator must be greatly increased.
One way to work with this... is to try to do video conferences. I
haven't done them myself, but some of our developers have worked with
clients this way. I've only used my iSight to destroy my laptop hard
drive and make funny faces at my coworkers.
> For those of you in a similar situations, what tips/techniques have
> you found to enhance and sustain a successful dialogue?
Perhaps we're lucky enough to get to make this part of the contract.
Clients either have us to come visit them for these initial meetings
or they come to Portland and meet with us on-site. It's crucial to
meet the people that you're going to work with. On smaller projects,
it's always not as necessary... but for bigger projects... it's
required.
This is a tough one and without being able to rely on your body
language as part of your communication process, we're definitely
faced with an obstacle.
tac...@gmail.com
keep the meeting down to a set number of minutes too.
I also need to echo the importance of face-to-face meetings. Earlier
this year I had several phone and email conversations with someone we
were thinking of working with. After a while we flew over for a
face-to-face meeting and boy, was it worth it. His body language, voice
nuance, etc. said he was opposed to the deal even if what came out of
his mouth did not. We're still working out the details, and it's up in
the air if we'll go through with it, but without the in-person meeting,
we would have had a completely different level of expectations.
best,
Al Hulaton
Mike Pence
We all jump back and forth between *what* a system is going to do and
*how* it is going to do it -- it is just human nature. It is how we
plan.
"Let's go to the mall!" (what)
"Yeah, we will take Ralf's car." (how)
"I want to see the new stuff at The Conformity Shop." (what)
"Yeah, but first we should swing by the hyper-caloric smoothy stand." (how)
Similarly, it is unrealistic not to expect human beings to frame
future plans in terms of past experiences. So, let them talk about the
systems they have in place, just unpack that into what's and how's.
My most successful requirements gathering sessions have been at a
white board with a couple of simple ground rules. What's go on one
side of the board, how's on the other. Ideas are *all* noted somewhere
and none are to be judged -- that comes later. The goal is dialog and
the fact that something is written on the board does not constitute a
promise that it will be included.
Those kinds of sessions are usually wildly productive. The actual
reduction of all that feedback into requirements happens eventually,
but it is secondary to the immediate goal of making everyone feel like
their ideas are being heard, and -- this is key -- creating a shared
mental context of what the system *is*.
Also, I think that the idea of using a web cam to improve remote
communications is brilliant and right on.
Mike Pence
James Adam
>
> I don't see users starting to talk about implementation as a problem.
> We all jump back and forth between *what* a system is going to do and
> *how* it is going to do it -- it is just human nature. It is how we
> plan.
>
> "Let's go to the mall!" (what)
>
> "Yeah, we will take Ralf's car." (how)
"Shall we take the diesel-powered car, or the hybrid?"
"I don't care, but the mirrors need to be remote-controlled, and I'm
looking for at least 500 horsepower since I've heard that's the best."
... there is a balance, we my point. If uses focus on the minutae too
soon, which can occur, then you lose sight of the goal (going to the
mall). Similarly, relating too strongly to existing systems (say, a
loose collection of Excel documents) can make it difficult for the
users to 'step outside of their own boxes' and re-frame the problem
they are trying to solve anew. It's not to say that there's nothing
useful to be gained from discussion *how* things might work, or
systems which have performed the same role in the past; rather that it
should always be done from a critical, external point of view, rather
than trying to carry over implementational or mechanical details
without considering whether they are really necessary - 'My old car
had dice on the mirror...'
James
Brasten Sager
> It's not to say that there's nothing useful to be gained from
> discussion
> *how* things might work, or systems which have performed the same
> role in the past; rather that it should always be done from a
> critical,
> external point of view, rather than trying to carry over
> implementational
> or mechanical details without considering whether they are really
> necessary - 'My old car had dice on the mirror...'
Ironically, "how" can be useful for encouraging out-of-the-box
thinking if used properly. Customers will inherently think inside
what they believe the realm of possibility to be. A lot of times
their idea of "possibility" is outdated or incorrect. Selectively
discussing some "hows" of past projects or possibilities for the
current one can encourage the customer to truly jump outside of what
they think is realistic.
Of course, as you said, balance....
Mike Pence
the bridges from where they are to where they are going, so there is a
shared vision of a Promised Land.
On the other hand, those fuzzy dice mean *personalization*, so there
are often larger issues hidden in those seemingly minor details.
Mike
Brian Ford
Er, sorry for being so late to the party...
This is a great point you make. I think our objective should be to
create innovative solutions. The biggest problem I've encountered with
folks jumping quickly to implementation details or simple feature lists
is they get soundly stuck "inside the box".
A client recently used TurboTax as an excellent analogy of the approach
we are taking in the project. You can get the forms and manuals from
the post office, spend many hours figuring it all out, fill out the
forms, and from the perspective of the objective to file your taxes
correctly, you've succeeded (you hope anyway). You could translate that
into software by making all sorts of perfect form-filling-out widgets,
and you'd still be solidly stuck in that box. On the other hand, you
can take the TurboTax approach and you don't see anything of the forms
until you hit that print button at the end. You never think about where
to put your SSN or how to format or round your numbers.
I think that highlights my biggest problem with feature lists. They are
highly effective in forcing you to think _inside_ the box because the
underlying goals and assumptions are not explicitly the focus. If we
focus on the goals and motivations, the box is much less defined and
the creative process can come to the fore.
So, yeah, I agree balance is necessary. Trying to understand what the
consequences are for talking about things in a particular way (e.g.
"how" versus "why" or "what", etc.) is challenging. That's why I get
excited thinking and talking about it as a process.
Brian
Bob
the question by turning the it around a bit and then focusing on what
PROMOTES dialogue.
1. Active Listening; It's an important skill. Listen, first, then
speak. Remember, you're there to learn about THEIR problem, not how
good at SOLVING what you think their problem is. Repeat back back what
the other party has said (your words) to reinforce what you've heard.
If you don't demonstrate that you're listening, you're loose their
interest in participating.
2. Agenda Control; Nothing is more counterproductive, especially to
your productivity and credibility than a meeting that spins out of
control. Unless you have a purpose and objectives for any formal
exchange of dialogue (a meeting) it should not occur. I like a focus on
actionable objectives and outcomes. Recap each decision point and move
on to the next.
3. Trust; Allow others to speak honestly and openly. If they don't feel
they can trust you, they won't trust you with their deepest and best
thinking. So you've got to establish high levels of trust to encourage
and support dialogue.
4. Follow-Up/Follow-Through; I call it the First Impressions effect.
When dialogue takes place it presumably does so because there is an
expectation of followthrough, of action that results from such
dialogue. Initially, you have the benefit of the doubt, albeit for a
short period of time. If you don't act quickly, you'll lost an
opportunity to build a strong foundation for a good relationship.
People want more than empathy or a pat on the back. The 'feel good'
stuff only lasts so long until you need to deliver on your promises --
through actions.
5. Don't Over Promise; In business, it seems about half wait until the
last minute and the other half hasn't a clue about what's really
involved in making any sort of quality effort at something (look at the
dismal record on software project performance in the CHAOS report and
others). If you overpromise/underdeliver against expectations; you'll
damage both trust and future dialogue. Don't commit to situations where
there's any doubt in your mind regarding your ability to perform. It
doesn't matter as much about capability (since we all like the
challenge) as much as it does about raw capacity (in terms of time) to
perform within the established timeframe.
So dialogue results from active listening and trust. Don't listen,
don't build, support or sustain trust and dialogue quickly diminishes.
rs