Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

The Technology of Dialogue

Posted by Tue, 12 Sep 2006 18:30:00 GMT

In the essay, Dialogue and Organizational Transformation, Glenna Gerard and Linda Teurfs outline the the building blocks of THE TECHNOLOGY OF DIALOGUE, which they suggests consists of:

  • Suspension of Judgment
  • Identification of Assumptions
  • Listening
  • Inquiry and Reflection

What makes dialogue different than conversation? According to David Gurteen, “dialogue is a disciplined form of conversation.”

Gurteen says that within dialogue1:

  • You prefer a certain position but do not cling to it.
  • You are ready to listen to others.
  • Your mindset is not one of ‘convincing others that your way is right’ but of asking what you can learn from them.
  • It is recognizing that other people’s input will help you refine your own ideas or reveal your misconceptions.
  • It is not argument or debate. It is not win-lose. In dialogue all sides win by coming up with a more appropriate solution than a single person could ever have. It is win-win.

When we first introduced Dialogue-Driven Development, Ryan Allen responded with a brief overview of how you might go about defining a failed project. His first bullet was, “Miscommunication can lead to the implementation of the wrong solutions.”

It is our opinion that many of the problems that lead to failed projects can be solved through consistent and cooperative discourse. Much of this relies on each of us taking ownership of our commitment to encouraging healthy collaboration between developers, clients, and users.

Wikipedia currently describes dialogue as, “a reciprocal conversation between two or more persons.”

Question

What are some of the obstacles that you face when interacting with a diverse set of developers, clients, and users?

1 The Discipline of Dialogue by David Gurteen

Dialogue-Driven Development is about Listening

Posted by Fri, 25 Aug 2006 23:11:00 GMT

3 comments Latest by Stephen Waits Sat, 26 Aug 2006 16:23:04 GMT

I know. I know. I recently wrote that Dialogue-Driven Development was about rounded corners. It just happens that I also think that d3 is more than that. d3 is focuses on the conversations between various stakeholders within a project.

What is dialogue?
an exchange of ideas or opinions on a particular issue, esp. a political or religious issue, with a view to reaching an amicable agreement or settlement1.


What is a conversation?
informal interchange of thoughts, information, etc., by spoken words; oral communication between persons; talk; colloquy2


Let’s focus on a really important side of the conversation, which is the art of listening.

In Information Anxiety 2, Richard Saul Wurman lists five tips for being a better listener.

  1. “Having two ears and one tongue, we should listen twice as much as we speak.”
  2. “Don’t try to formulate your reply when the other person is speaking.”
  3. “The person who starts a sentence should be the one to finish it.”
  4. “Don’t let your fear of silence propel you to fill it with air. A moment of silence can be the most revealing part of a conversation.”
  5. “Remember that listening is not a passive endeavor, but an activity that requires great energy. Try to listen with the same intensity you use to talk.”

The Value in Face to Face

It’s been a while since we at PLANET ARGON have started working on a project that we didn’t get a chance to meet face to face with the client. For projects that we know will involve a lot of dialogue, it’s an absolute must at the beginning of the project. This is exactly why Brian and I fly across the country to meet our clients in person.

Wurman writes, “Time and time again, studies have shown that the best communication occurs face to face.”

“Precision of communication is important, more important than ever, in our era of hair-trigger balances, when a false, or misunderstood word may create as much disaster as a sudden thoughtless act.” – James Thurber

Our team is still shaping how best to encourage and facilitate valuable patterns of dialogue with our clients. One aspect we are certain of is that all interactions should be clearly documented, including the subtleties of body language and how the client’s team works together.

Two Ears, One Mouth

There are many benefits to having two ears. We should all try to listen more. I’ll be the first to admit that this is one of the most difficult things to do, especially when you’re opinionated.

“We have two ears and one mouth so that we can listen twice as much as we speak.” -Epictetus

The next time we find ourselves in the middle of a conversation, let’s try to listen more. :-)

1 http://dictionary.reference.com/search?q=dialogue

2 http://dictionary.reference.com/search?q=conversation

Information Anxiety and Solutions

Posted by Tue, 22 Aug 2006 17:15:00 GMT

1 comment Latest by brasten Tue, 22 Aug 2006 19:10:16 GMT

Last week, Allison brought me in a copy of a book that she owns by Richard Saul Wurman. In 1976, Wurman coined the phrase, information architect. (read more)

In his book, Information Anxiety 2, Wurman discusses how we’re overwhelmed by too much information… amongst other related topics.

Allison bookmarked a page for me that discusses the problem with developing solutions without a good understanding of the problem.

“Before any solutions to any undertaking can be developed, a movement must begin to discover its beginning. Understanding the vein of the problem is the course to solving it. The best way to accomplish any endeavor is to determine its essential purpose, its most basic mission. What is the endeavor supposed to accomplish? What is the reason for embarking upon it? This is where the solution lies.”

- Richard Saul Wurman, Information Anxiety 2

Wurman then goes on to suggest, “There are two parts to solving any problem: What you want to accomplish, and how you want to do it. Even the most creative people attach issues by leaping over what they want to do and going on to how they will do it. There are many how’s but only one what.”

There are many how’s but only one what

“You must always ask the question, “What is?” before you ask the question “How to?”“

When Brian and I began rethinking how we were extracting information from our clients, it was important to understand why we felt it was necessary. We’re convinced that the more we can enhance our patterns of dialogue with our clients, the more confidence we’ll have in our approach to building solutions that provide them with that they need, not just what they think they need (want).

Next time a client brings you a list of features for their product, please be sure to ask yourself and your client, “why” the product needs them. What are these hows providing their business and user goals?

class Goal; has_many :sub_goals; end

Posted by Wed, 16 Aug 2006 16:26:00 GMT

1 comment Latest by Jason Watkins Wed, 16 Aug 2006 22:30:04 GMT

I was up late last night reading, The New Utopians: A study of system design and social change and came across the following quote.

“Problem solving proceeds by erecting goals, detecting differences between present situation and goal, finding in memory or by search tools or processes that are relevant to reducing differences of these particular kinds, and applying these tools or processes. Each problem generates subproblems until we find a subproblem we can solve-for which we already have a program stored in memory. We proceed until, by successive solution of such problems, we eventually achieve our over-all goal-or give up.”[1]

This caught my attention because this presents a very systematic process for achieving goals, but doesn’t clarify how you erect these initial goals in the first place. Our team is putting a lot energy into rethinking how we are requesting information from our clients. Brian Ford has written an article titled, Ethical Software Needs Dialogue, which discusses some of our current approaches to outlining the project goals.

Brian writes, “One approach that we are trying is dialoguing with the client about goals without talking at all about the web site. In other words, for that exploration, the web site doesn’t even exist. Talk about thinking outside the tubes.”

If you have a few minutes… you might read his insightful article.

1 H.A. Simon, The New Science of Management Decision (New York: Harper & Row, Publishers, Inc., 1960), p. 27.

Project Illuminatus, an introduction

Posted by Mon, 14 Aug 2006 23:52:00 GMT

4 comments Latest by Alain Tue, 15 Aug 2006 16:06:46 GMT

Due to an unfortunate event last week, this blog entry is a few days late.

Over the next few weeks and months, the PLANET ARGON team will be blogging about one of our big projects that recently started. We needed to get the client to sign off on the blogging project and got the a-okay from their management early last week.

First, some background.

We were contacted by this rather large (enterprise?) company around the time that we went to RailsConf. When we got back, I began talking with our primary point of contact about their project, which sounded like a fairly big challenge and the sales process took a few weeks to come to an agreement on the next steps. Once they were finished interviewing a few other potential firms, we got the go-ahead that we should proceed with an ITER-ZERO, which I outlined a few months ago in part one of, The Art of Delivery.

ITER-ZERO was essentially a two-day trip for Brian and I to Washington DC (pictures) to interview the client and some of their existing users (domain experts), establish the protocol and channels for communication between them (the client) and our team, and work on identifying the core goals of their product that we’ll be developing with them. They have an existing product that they’ve been selling to customers for over ten years and the product that we’ll be developing will be the next generation of this software. The new product is replacing a desktop application that is only runs on Windows. The application that we’re currently working has a technical requirement that is needs to run on any operating system with a modern web browser, including some of the newer phones that have Opera mini installed! As you can see, we have our work cut out for us… :-)

During our meetings, we agreed that while their final product name is going through their marketing process, that we should have a playful project name to refer to. Our primary contact at the firm suggested, Project Illuminatus[1]. He’s a bit of a conspiracy theory nut… and it sounded fun… so we agreed to that. :-)

If I recall, Brian and I stayed up past 2am (the time zone change does that to you…) working on structuring the project wiki (instiki) to document the dialogue that occurred on our first day in DC. This provided us with a solid plan for how we wanted to focus our attention to identifying the goals that we wanted to collaborate on with the client to build an innovative and simple to define solution. Simple solutions emerge from even complex goals when you can clarify them using simple and intelligible language.

In this great blog interview, Stiff asked several famous developers the following question, “What do you think makes some programmers 10 or 100 times more productive than others?”

David Heinemeir Hannsson responded with, “The ability to restate hard problems as easy ones.”

On day two, we showed their team the wiki and explained how they could collaborate with us there. If they had ideas and new goals identified, they had a place to store those. It’s vital that your attention is on the scope of the work that needs to be investigated. We try not to solve all of the problems too quickly… it’d be naive of us to think that we could. Products evolve and so must their requirements.

I’m not going to go into everything that went on here at the moment, perhaps Brian will fill us in on some of this.

When we got back to Portland, Brian and I began meeting with Allison Beckwith, our Creative Director, to outline one of the most complex pieces of the system. As a team, we decided that this is what we need to focus more of our immediate attention to. In the their previous application, there was approximately five different modules that did something very similar, but just slightly different enough for their original developers to just build separate interfaces, which were not consistent and difficult to use for someone new to the application. We want to consolidate this into one new solution that focuses on how the users will be using the system… not just the tasks that they are fulfilling. This is why we spend so much time thinking about the goals that the users have… not what they have to do.

Oh yeah… one of the non-functional requirements?

“The product shall be easy to use on the first attempt by a member of the general public without training.”[2]

About a week later, we agreed on what work would be performed during ITER-001 (iteration one), which included paper prototyping and a few rounds wireframe mockups for this one major component of the application. I’ll let Allison Beckwith (yes! she started a blog) fill you in on this when she gets some time to outline her process for doing this.

Stay tuned…

1 http://en.wikipedia.org/wiki/Illuminatus

2 copied directly from Mastering the Requirements Process, 2nd edition. It works.. and does it need to be reestated any simpler than that?

d3 not DDD

Posted by Tue, 08 Aug 2006 16:15:00 GMT

6 comments Latest by MSM Thu, 10 Aug 2006 00:40:48 GMT

First, a quick update from our sponsors…

Brian and I talked yesterday and agreed to stop referring to Dialogue-Driven Development as DDD. We’ll leave that for the Domain-Driven Design fans. From now one, the short version for Dialogue-Driven Development will be d3.

MSM posted an email in regards to d3 on a Scrum development mailing list. He writes, “While I believe there’s room for plenty of Agile methodologies in the world and wouldn’t want to discourage the development of DDD if it helps them get their software written, I would hate to see Scrum described inaccurately, especially in a well-oiled meme propagation machine like the Rails community.” (link)

Michael D. Ivey responded with, “That being said…as someone who has gotten 100% into Rails development, I find myself using Scrum less. At least, on the surface, official Scrum. Rails makes meW^WWlets me be so productive that we are basically having 1 day sprints.

What’s interesting here is that we have a someone who is working with Ruby on Rails and finds himself using Scrum less because the environment is much different. This is exactly why Brian and I started seeking out something even more lightweight. We’re not aiming to replace other methodologies, but to structure our own that focuses on dialogue. With Rails, we’re finding that the amount of collaboration and dialogue with clients has both increased and improved tremendously.

Ivey also goes on to say, “I believe, having done Scrum well, and having done the ””Rails experience,”” that what Robby and …. the other guy …. are describing with ””Dialogue Driven Development”” is exactly what happens when you start with Scrum or something Scrummy, add a hyper-productive programming language and framework, mixin a very active and interactive customer, and then just start running at a comfortable pace and see when you get somewhere cool.

Perhaps Michael is right… and of course, this is open for discussion. :-)

Brian and I are spending a good deal of time thinking and talking about this stuff. We want to outline a new pattern that changes how requirements are gathered and documented through dialogue. It’s apparent that as we read different peoples comments on our articles that the general consensus is to interpret the Product Backlog pattern described in the books on Scrum in a way that works best for your team. The approach outlined in Agile Software Development with Scrum doesn’t work for us.

What’s your pattern? Share your story…

Older posts: 1 2 3 4