Of DIalogue
Robby Russell
I'm not sure if you all had a chance to reads Brasten's article[1]
about d3, but I highly encourage you to.
From his article... "d3 is uniquely positioned to alter the way
developers and customers interact in an Agile environment. It is my
opinion that d3 should take advantage of it’s core principle –
dialogue – in two ways: firstly, d3 should redefine how customers
interact with the Agile development process; and secondly, d3 should
encourage the creation of dialogue patterns, specifically those
regarding requirements gathering and customer feedback."
He's absolutely right about this. We also want to take this several
steps further and create patterns of dialogue amongst ourselves
(development teams) and how we engage in dialogue with the users of
the products we develop.
I would really like to get the mailing list sparked... so I'll ask
some questions and hope some of you respond. ;-)
* What is the difference between dialogue and conversation?
* How do you go about gathering user and business goals from clients?
* Do your customers _really_ understand Agile? Do they want to?
One thing that I have been thinking a lot about is Interaction
Design, which encourages you to focus on the experience of using the
product... not how it is going to be developed. Users think very
little about the architecture... they are only concerned with their
interaction, which is often surface level. Everything behind that _is
magic_.
Perhaps this pattern would work well with client interaction?
...just some thoughts. :-)
[1] http://www.ibrasten.com/articles/2006/10/02/of-dialogue-and-
development
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]
tac...@gmail.com
difference. From a marketing standpoint, I prefer 'conversation' since
it gives the impression of informality. And the fewer formal borders in
the way of communication, the better.
> * How do you go about gathering user and business goals from clients?
"What's the end result you desire, increased customer satisfaction
surveys? more sales? better event attendance? lower costs?"
"Walk me through your process right now: what happens at the start of
[whatever]?"
Best,
Al Hulaton
Robby Russell
On Oct 6, 2006, at 10:43 AM, tac...@gmail.com wrote:
>
>> * What is the difference between dialogue and conversation?
>> From a definition standpoint (both mine and Webster's) there is no
> difference. From a marketing standpoint, I prefer 'conversation' since
> it gives the impression of informality. And the fewer formal
> borders in
> the way of communication, the better.
Yes, the words dialogue and conversation and been merged together
over the eons, but it's time to really start pushing them away from
one another. In it's simplest form, dialogue is a form of conversation.
Here is a good summary of David Bohm's approach to Dialogue.
http://www.infed.org/biblio/b-dialog.htm
>
>> * How do you go about gathering user and business goals from clients?
> "What's the end result you desire, increased customer satisfaction
> surveys? more sales? better event attendance? lower costs?"
In our environment, we can make fairly safe assumptions that there
are business goals that our clients are focused on. Often times, it's
these goals that prevent them from thinking about their customers...
so we try to pull them away from business goals and focus on user
goals. Without users... their business goals aren't going to be met.
Oddly enough, our interaction with our clients is our own way of
doing the same thing. Sure, we can build just about anything you want
us to build... but if we're building you the wrong thing... then
we've taken your money , without really thinking about your best
interests.
David Goodlad
I'm pushing the same philosophy at work right now. We're building
some software for which we have only a few users at the moment. Our
decisions are mainly motivated by my boss, but I've started to
challenge him on these decisions, forcing us to think about the
_users'_ business needs. Just because we want to provide some feature
doesn't mean anybody wants to use it.
Dave
--
Dave Goodlad
dgoo...@gmail.com or da...@goodlad.ca
http://david.goodlad.ca/
Robby Russell
On Oct 6, 2006, at 11:34 AM, David Goodlad wrote:
>> In our environment, we can make fairly safe assumptions that there
>> are business goals that our clients are focused on. Often times, it's
>> these goals that prevent them from thinking about their customers...
>> so we try to pull them away from business goals and focus on user
>> goals. Without users... their business goals aren't going to be met.
>> Oddly enough, our interaction with our clients is our own way of
>> doing the same thing. Sure, we can build just about anything you want
>> us to build... but if we're building you the wrong thing... then
>> we've taken your money , without really thinking about your best
>> interests.
>
> I'm pushing the same philosophy at work right now. We're building
> some software for which we have only a few users at the moment. Our
> decisions are mainly motivated by my boss, but I've started to
> challenge him on these decisions, forcing us to think about the
> _users'_ business needs. Just because we want to provide some feature
> doesn't mean anybody wants to use it.
I think it was Alan Cooper that said that people wouldn't use your
software if they didn't have to. So, the less crap that we put in
front of the user... the less time they have to spend in front of
it. ;-)
What are your users goals? No... really... what are they? :-)
brixen
That's an excellent point. Often, the client is not the user of the
software but has pet ideas about how things should be done or what
would be valuable to users. This has been one of the most challenging
things to deal with.
There is the saying that the customer is always right. I take issue
with that. I think we need some conception of ethics in the sense that
if we *know* what we are building is crap, we should not just build it
because someone is paying for it. There is a common stance between
developers and clients that I like to call "ultimatum-driven
development". It takes many forms but pretty much comes down to this,
"build it this way because I'm paying for it". The "I'm paying for it"
should not trump the necessity to build good, or even excellent,
software.
And of course, this is especially true in terms of interaction design.
My experience is that everyday I interact with by far mostly software,
desktop and web, that fails to implement good interaction design.
That's a big issue, in my opinion.
So, when I say, I take issue with a client telling us *how* to build
software, I'm not saying we flip the birdie and walk away in a huff.
I'm saying we need some pattern of interaction to address this. It's
some sort of negotiation. Learning that has to occur on both sides.
This is tough. That's why we're insisting this dialogue thing needs
some attention.
Cheers,
Brian
On Oct 6, 11:34 am, "David Goodlad" <dgood...@gmail.com> wrote:
> On 10/6/06, Robby Russell <r...@planetargon.com> wrote:
>
>
>
>
>
> > On Oct 6, 2006, at 10:43 AM, taco...@gmail.com wrote:
>
> > >> * What is the difference between dialogue and conversation?
> > >> From a definition standpoint (both mine and Webster's) there is no
> > > difference. From a marketing standpoint, I prefer 'conversation' since
> > > it gives the impression of informality. And the fewer formal
> > > borders in
> > > the way of communication, the better.
>
> > Yes, the words dialogue and conversation and been merged together
> > over the eons, but it's time to really start pushing them away from
> > one another. In it's simplest form, dialogue is a form of conversation.
>
> > Here is a good summary of David Bohm's approach to Dialogue.
>
> >http://www.infed.org/biblio/b-dialog.htm
>
> > >> * How do you go about gathering user and business goals from clients?
> > > "What's the end result you desire, increased customer satisfaction
> > > surveys? more sales? better event attendance? lower costs?"
>
> > In our environment, we can make fairly safe assumptions that there
> > are business goals that our clients are focused on. Often times, it's
> > these goals that prevent them from thinking about their customers...
> > so we try to pull them away from business goals and focus on user
> > goals. Without users... their business goals aren't going to be met.
> > Oddly enough, our interaction with our clients is our own way of
> > doing the same thing. Sure, we can build just about anything you want
> > us to build... but if we're building you the wrong thing... then
> > we've taken your money , without really thinking about your best
> > interests.I'm pushing the same philosophy at work right now. We're building
> some software for which we have only a few users at the moment. Our
> decisions are mainly motivated by my boss, but I've started to
> challenge him on these decisions, forcing us to think about the
> _users'_ business needs. Just because we want to provide some feature
> doesn't mean anybody wants to use it.
>
> Dave
>
> --
> Dave Goodlad
> dgood...@gmail.com or d...@goodlad.cahttp://david.goodlad.ca/
brixen
The interesting thing to me about the definition of dialogue versus
conversation is the preceived difference in formality. From my
dashboard dictionary: "dialogue: a discussion between two or more
people or groups, esp. one directed toward exploration of a particular
subject or resolution of a problem."
On the one hand, I think informality is an important function of
keeping the pressure of social interaction lower, which is desirable if
we are interacting a lot. On the other hand, one reason we have chosen
"dialogue" is to try to emphasize the aspect of working out a problem
where we may very well be head to head. We find that there is a lot of
negotation, mostly implicit, when trying to get requirements nailed
down. People have emotional attachments, pet ideas, favorite ways of
doing things, and they are quick to impose those, under the guise of
"business requirments".
Cheers,
Brian
On Oct 6, 10:43 am, "taco...@gmail.com" <taco...@gmail.com> wrote:
> > * What is the difference between dialogue and conversation?
> >From a definition standpoint (both mine and Webster's) there is nodifference. From a marketing standpoint, I prefer 'conversation' since
David Goodlad
>
> David,
>
> That's an excellent point. Often, the client is not the user of the
> software but has pet ideas about how things should be done or what
> would be valuable to users. This has been one of the most challenging
> things to deal with.
Right; I treat my boss as the 'customer' even though he's not the
end-user of the product. Through him, we have to determine the needs
of the real users. It's yet another layer of communication to break
through!.
> There is the saying that the customer is always right. I take issue
> with that. I think we need some conception of ethics in the sense that
> if we *know* what we are building is crap, we should not just build it
> because someone is paying for it. There is a common stance between
> developers and clients that I like to call "ultimatum-driven
> development". It takes many forms but pretty much comes down to this,
> "build it this way because I'm paying for it". The "I'm paying for it"
> should not trump the necessity to build good, or even excellent,
> software.
Right, just because they're paying for the software doesn't make them
all-knowing in terms of what the users of that software _need_ (I
don't care what they want, I care about delivering what they need).
> And of course, this is especially true in terms of interaction design.
> My experience is that everyday I interact with by far mostly software,
> desktop and web, that fails to implement good interaction design.
> That's a big issue, in my opinion.
>
> So, when I say, I take issue with a client telling us *how* to build
> software, I'm not saying we flip the birdie and walk away in a huff.
> I'm saying we need some pattern of interaction to address this. It's
> some sort of negotiation. Learning that has to occur on both sides.
> This is tough. That's why we're insisting this dialogue thing needs
> some attention.
My strategy so far is to unemotionally ask them to step back for a
minute from the "I want this feature" phrase. Start thinking about
value delivered to the user; start thinking about HOW the user is
going to use whatever information or functionality you're delivering
to them. I ask open-ended questions to get interesting answers that
help build the bigger picture. In the end, we all end up
understanding the motivation behind a given feature, and as a
developer I can help build that feature to better suit the needs of
the users.
brixen
> My strategy so far is to unemotionally ask them to step back for a
> minute from the "I want this feature" phrase. Start thinking about
> value delivered to the user; start thinking about HOW the user is
> going to use whatever information or functionality you're delivering
> to them. I ask open-ended questions to get interesting answers that
> help build the bigger picture. In the end, we all end up
> understanding the motivation behind a given feature, and as a
> developer I can help build that feature to better suit the needs of
> the users.
This sounds good. We have tried two things: restate things in terms of
problems, and at times, specifically limit the discussion so we do not
talk about the software at all.
The first really helps think about what the issues are. The second has
a caveat. We don't want to end up implementing things the way they
might be done without technology, similar to Alan Cooper's criticism of
the first digital calendars that looked like paper calendars. But it
really helps to focus on the problems we are trying to solve.
There's the YAGNI idea related to simplicity. But I think that comes
too late in the process, or potentially does. I think you need the
critical YAGNI bat if you're dealing mostly with features. If you can
pull back and look at the problems, create a solution, and then an
implementation of that solution, you can avoid a lot of the discussion
about features. Also, having a clear statement of the problem with the
rationale for the solution provides a focal point for feedback from
usability testing.
But again, talking about the problems is really challenging.
Brian
tac...@gmail.com
>
> In our environment, we can make fairly safe assumptions that there
> are business goals that our clients are focused on. Often times, it's
> these goals that prevent them from thinking about their customers...
This is good discipline to ask that for sure, but I figure if the
business ain't keeping track of their customer goals and molding that
into their goals then they ain't gonna be in business for long. Not
enough businesses take feedback from their customers seriously.
Perhaps one of the first things to do, if met with a blank stare by the
client when asking about the users' goals, is to get a few of their
users in the same room with you. Start up a focus group. If that's not
possible, then get the people in the organization closest to the
end-user into the same room and role-play.
Best,
Al Hulaton
PS For those of you who don't know, I'm not a programmer by any stretch
of the imagination but am a marketer and salesguy by trade. Current gig
is running sales and marketing for a manufacturing company though I've
spent the majority of my career in software and services. Still, I'm
intrigued by this process because software, manufacturing, legal
negotiations, whatever the application, the one commonality is
effective methods of communication.
ro...@planetargon.com
On Oct 6, 3:31 pm, "taco...@gmail.com" <taco...@gmail.com> wrote:
>
> Perhaps one of the first things to do, if met with a blank stare by the
> client when asking about the users' goals, is to get a few of their
> users in the same room with you. Start up a focus group. If that's not
> possible, then get the people in the organization closest to the
> end-user into the same room and role-play.
>
This is actually part of our process at PLANET ARGON. During the
initial iterations, we work with our clients to find the right people
to interview, which we call Domain Experts. For example, these people
might be real users (should the client have access to ttheir existing
client base...) or targeted users.
We then schedule an initial interview with those people, where we talk
about the problem that the client hopes to build a solution for... and
we extract possible requirements out of those discussions. It's also
important to know that users don't always know what they _need_
either... so it's important to discuss things without falling into a
state where you're only compiling a wishlist.
> PS For those of you who don't know, I'm not a programmer by any stretch
> of the imagination but am a marketer and salesguy by trade. Current gig
> is running sales and marketing for a manufacturing company though I've
> spent the majority of my career in software and services. Still, I'm
> intrigued by this process because software, manufacturing, legal
> negotiations, whatever the application, the one commonality is
> effective methods of communication.
The more the better... in fact, I think it'll do us developers
_wonders_ if we can interact with people like you. Often times, it's
ambitious business people like yourself that we're dealing with each
day... under the title... "client"... :-)
Robby
Brasten Sager
conversation (the tool/activity) + ??? (the result) == dialogue
Dialogue is what happens when a conversation produces The Result.
Dialogue is retroactive, then; you may not be sure you're having a
dialogue until it's finished. This is why dialogue patterns are so
critical -- we must be able to reliably provoke dialogue in a variety
of circumstances.
The Result is part of what we have to define. "Shared knowledge" --
while vague -- is probably an acceptable placeholder for now. Like
all good things, The Result will be extracted over time from the
experiences of d3 teams.
> * How do you go about gathering user and business goals from clients?
I usually spend time building an understanding of the user/client's
world, both inside and outside the scope of the project. Sometimes
this involves on-site meetings, sometimes it involves researching and
writing a detailed report on the industry involved... but the point
is, I want to feel the user's pain before we start trying to solve
it. THEN, we'll talk about the specifics of the project.
Having that understanding and frame of reference prior to the project-
specific discussions often improves the effectiveness of the
requirements gathering process.
> One thing that I have been thinking a lot about is Interaction
> Design, which encourages you to focus on the experience of using the
> product... not how it is going to be developed.
Beyond the user-experience benefits to this, I think there are
architectural benefits too. If the developers don't have a pretty
comfortable idea of how the user will interact with the system, they
will tend over-architect and preemptively abstract the code to death
-- anticipating all the ways the user might end up interacting with
the system. You end up building 5 solutions because you didn't know
which ONE was necessary.
Brian Ford
> This is good discipline to ask that for sure, but I figure if the
> business ain't keeping track of their customer goals and molding that
> into their goals then they ain't gonna be in business for long. Not
> enough businesses take feedback from their customers seriously.
I wish I could agree with this. But as a counterpoint: Microsoft. Not
to inflame any folks who use or like MS products, but they have
successfully married incredible market clout with doltishness, and in
many ways are still doing business as usual. On OS security, they have
been a laughing stock. IE is far too often painful when it comes to
trying to make simple, standards-compliant web pages with CSS and Ajax.
When I started at PLANET ARGON and received this shiny new MacBook to
work on, I started up the included demo MS Word to open a client's xls
file. Ugh! Confronted with this huge app that took a long time to start
and had some of the worst use of semi-transparent alpha blended
control, I exited it and promptly uninstalled it.
Alan Cooper wrote About Face (first edition) over a decade ago. On the
back cover is a letter about how user's should not settle for software
that sucks, to paraphrase. Ten years is a long time and I wish we could
point to all the failures of long ago and be glad we're in such a
better place now. But we can't. Cooper's book is every bit as relevant
over 10 years later. We too often have to use software that is crappy.
Obviously, this isn't just MS's fault. There are a lot of things that
contribute to this. I don't think that the solution is merely better
programming tools, better development methodologies, better testing, or
better requirements gathering. I think "simplicity" and "less software"
are important as concepts, but those can't be pasted over the sort of
misunderstandings that create something like MSWord. Bohm talks about
shared meaning, which is more than just better ways to convey
information. In the context of our discussion, that's really nebulous
at this point. But trying to understand this is what we're focused on.
>From programming languages, as well as from many other arenas, we know
that building a better mouse trap doesn't guarantee success. So, while
I wish producing crappy products would cost companies something, it
often doesn't. For every piece of crappy software, there are
developers, designers, managers, etc. somewhere that produced it. Which
doesn't mean I think those folks do crappy work or are stupid, etc.!
For the most part, I'm sure they're not. And if the software is sold,
there's probably someone who paid to have it built.
Brian
tac...@gmail.com
You know, I agree with you completely so to clarify my poorly worded
"won't be in business for long," I don't mean that any business who
ignores users' feedback is gonna be filing for Chapter 11 in a month,
but that they're in a vulnerable spot.
The Microsoft example is a fine one, but they've repeatedly been caught
flat footed by the internet while gazing at their shrink-wrapped
software in a box navel. Google, yahoo, myspace, et al have filled in
the users' desire to--oddly enough--converse.
I'd put telcos in this mess as well. They thought they were selling
telephone service. Cable internet, wireless, regular ol' pay cable
showed 'em that a wire from the street to the house could be used just
for phones. Same goes with railroads--they were moving boxcars around
so much that they forgot they were in the transportation business, not
the railroad business. FedEx and UPS set 'em straight.
Anyway, sorry for the derail (yuk yuk).
Robby Russell
On Oct 6, 2006, at 5:36 PM, Brasten Sager wrote:
> The Result is part of what we have to define. "Shared knowledge" --
> while vague -- is probably an acceptable placeholder for now. Like
> all good things, The Result will be extracted over time from the
> experiences of d3 teams.
I've been thinking about this and I keep finding that fundamentally,
we're aiming to achieve "shared understanding." Perhaps
"understanding" and "knowledge" are similar enough... but I feel more
attached to "understanding."
If the Client feels confident that we _share an understanding_ about
a given topic... than we can effectively collaborate together.
However, I don't have enough historical data to fully support this
statement. However, common sense leads me to believe that this is
_fairly_ true.
What good is shared understanding or knowledge? How are our
interactions enhanced?
--
Robby Russell
http://www.robbyonrails.com/
http://www.planetargon.com/