Robby on Rails: Tag dialogue

Ruby on Rails meets the Business World

Robby Russell — Mon, 21 May 2007 19:36:00 -0500

On Saturday, I had the great pleasure of being up in front of several hundred people with the following individuals on the the Business of Rails panel at RailsConf.

Photo by James Duncan Davidson

Moderated by:

Nathaniel Talbott, President, Terralien, Inc.

The Victims:

Justin Gehtland, Founding Partner, Relevance
Geoffrey Grosenbach, Topfunky
Andre Lewis, Earthcode Studios
Joe O’Brien, artisan, EdgeCase, LLC
Robby Russell, Director, PLANET ARGON

Overall, the experience was fantastic. I really enjoyed the questions that Nathaniel and the audience threw our direction, both during and after the session. Throughout the remainder of the conference, people would catch me and present complicated business questions to me and ask for my input. I think that I even helped one guy make his final decision about which job offer he was going to accept (btw, did you decide yet?). It’s always great to share my experiences of leaving my last full-time job (3+ years ago), moving to Rails exclusively (2+ years ago), how Allison and I went from two people in an attic to seven people in an attic in about a month... to having an office in downtown Portland and clients around the globe. I’m also always happy to share my not-so-happy experiences throughout the past few years as well. Running a business is hard stuff as it comes with a whole lot of responsibility, which can lead to stress. It was great to know that the rest of the panel has had their difficult experiences. While Rails makes everything feel easy… running a business is a whole different spectrum of challenges. ;-)

At one point during the session the audience was asked, “How many of you are considering starting your own business based on Ruby on Rails?”

The response?

Based off of my extremely scientific calculations (looking around the room), I’d estimate that around 30-40% of the audience raised their hands! Wow. It was fantastic to see that there was that much interest in people starting venturing off onto their own. Imagine… a flood of new companies, competing directly with us… and guess what? I think that’s awesome! Awesome for Rails. Awesome for future startups. Awesome for everyone!

Let’s face it. Rails isn’t going anywhere for a long time.

So, now that the conference is over, questions have begun to appear in my email box. Thank you all for writing. What if you could have a sounding board to throw questions to on a regular basis? Unfortunately, our session only lasted a hour at RailsConf and too many questions weren’t gotten to. Well, I’ve asked the rest of those on the Business of Rails panel to join me on a google group, titled, Ruby on Rails meets the Business World.

If you’re looking to (A) start your own Rails-based business, (B) already run your own Rails-based business, or ((C)) have business experience that you’d like to share with those in camp A and B… then join the community and start some conversations.

Personally, I’m really looking forward to learning from you all and hope that my experience of co-founding and leading PLANET ARGON can be of benefit to all of you.

Photo by James Duncan Davidson

Review: Highrise, part 1

Robby Russell — Thu, 15 Mar 2007 18:45:00 -0500

So, today I got what I’ll call a platinum ticket from one of our pals at 37signals for their upcoming new application, Highrise, which is what they’d call a “shared contact manager.” The rest of you can keep hoping that you’ll win a golden ticket this weekend. ;-)

For the past year and a half, I’ve been wanting to build some sort of contact and task management tool for organizing all of the contact requests that PLANET ARGON receives about our Design and Development and Rails Hosting services. If I go away for a week, I come back to a huge backlog of people who may be waiting a response from me. Having a tool to allow others at PA to see what is in my queue and in some cases, respond on my behalf… has been needed. When I first heard about Highrise long ago, I got excited and have tried several different tools and each of those tools has left me feeling uneasy. Perhaps I’ll post some reviews of the other tools one day.

First Impressions

The signup process looks familiar… :-)

Look and Feel

Well, it definitely looks and feels like a 37signals application. There might have been a time when I thought that would be silly… but really, when you look at other product suites, consistency is extremely important to the user experience. While they are definitely going to attract people to Highrise who have never used any of their other products, I’d also expect a huge majority of their initial customers will be users of their other products. It’s obvious that Highrise was in response to a void in the market that people (likely customers) were asking for in other products like Basecamp.

Highrise has all the Ajaxy goodness that you’d expect in a brand new modern web application. Most of it seems very intuitive, but I found myself getting caught up on the extra tabs across the top of the screen. When new tabs appear, my natural response was to try to close them when I was finished looking at the page. Perhaps this is just a design decision that I’ll learn to really like. At the moment, I’m still not quite sure because I expect the tabs to change quite frequently.

(few minutes later)

Actually… I wonder if the interface designers at 37signals did this to help their users avoid having several tabs open in their web browser. I use Safari for Basecamp and generally have 5-8 tabs open throughout the day for different projects that our team is working on because the Dashboard view doesn’t really give me a good feel for what is happening throughout the day on our various internal and client projects. I’ll try to pay attention to my usage habits to see if I’m opening less browser tabs in Highrise.

So far, this is the one thing that I’m not quite sure about (yet).

Highrise meets Act-On

Once I saw that you could forward emails to Highrise and it’d auto-magically create a contact and store it, I jumped for joy (not literally… but I got an evil grin). I have been using (more like heavily relying on) Mail Act-On for what seems a really long time. I’m constantly forwarding emails off to my colleagues to keep things from sitting stagnant for too long. So, guess what I did?

This is working beautifully and allowed me to move about 20 contact requests to Highrise in just a few minutes.

With this new ability, I can remove that one project in Basecamp that I was using to collect contact request information. That information now has a proper home!

Manage your Peeps

I’m taking more screenshots and going to continue putting more of our contacts into Highrise… so… consider this part one of a short series of posts.

To be continued…

Poor Communication and IT Projects

Robby Russell — Mon, 12 Mar 2007 17:25:00 -0500

InformationWeek has a short story titled, Poor Communications, Unrealistic Scheduling Lead To IT Project Failure.

“Communications failures top the list of reasons IT projects fail, according to poll results from the Computing Technology Industry Association.

About 28% of 1,000 respondents identified poor communications as the main cause of project failure, according to CompTIA, which offers project management training.”

So, while we’re all spending so much of our time focused on improving our technical skills, are we also investing our time into becoming communication superstars?

If you look back at the following posts, you’ll see some links to some excellent books on this topic.

Seth Godin on Dialogue

Robby Russell — Fri, 09 Mar 2007 11:37:00 -0600

It appears that Seth Godin is catching on to the concept of Dialogue.

Seth writes, “Some organizations are good at listening. Some are good at talking. A few are even good at both.”

I’ve been spending a lot of time thinking about how I listen to clients, employees, friends, and family. All of our relationships are a series of conversations. Sometimes we can have healthy dialogue, sometimes we just fall victim to debate. (see Dialogue vs Debate)

If you’re really interested in Dialogue, I’d encourage you to review the technology of Dialogue... and check out the Dialogue-Driven Development project and introduce yourself.

Please Make Fun of the Boss

Robby Russell — Fri, 02 Mar 2007 00:26:00 -0600

While reviewing some articles related to small business management, I came across the following post… titled, Note From Boss to Employees, by Michael Wade. As a young business owner, who only 16 months ago was working in his attic… to now trying to figure out how to run a company with over ten employees (and growing), posts like this remind me that we all have so much to learn. :-)

Here are a few that I appreciated…

“I may not have been given a huge amount of training before being named to a supervisory position. As a result, I’ve had to learn through trial and error. That’s not always bad. Many of my responsibilities can only be learned through practice.”

Yep… that’s me! The only difference is that I promoted myself instead of being promoted by someone else. I’m still not sure what I got myself into sometimes. ;-)

“I will make mistakes. Please give me the same understanding that you’d like me to give you when you blunder.”

This reminded me of a blog post from last year, titled, Avoiding the most common software development goofs, which points out that things like ignorance and stress are often to blame for mistakes in development. I feel like these are reasons for goofs in just about any environment, especially business. Let’s face it. We’re not perfect and we’re going to make a lot of mistakes. Once we’ve agreed on this, let’s take the next step and see what happens.

“If I do something dumb or am on the verge of doing so, please tell me. Don’t hint. Tell me.”

Perhaps this is a common problem for most small business owners. Are employees afraid to tell me that I’m doing something dumb?

“If either of us has a problem with the other’s performance, let’s talk about it.”

As they say, real friends will be honest with you about your faults. Not because they want to make you look bad, but because they care.

Each of the points that I have listed here are pointing to is… healthier Dialogue, which is always a challenge to accomplish… in any relationship… whether with clients, coworkers, bosses, or employees.

I’d like to add a few to this list.

It’s easier to ask for forgiveness, than to ask for permission.
I’m still trying to get the hang of this GTD stuff, so.. you might remind me if I forgot something.
Ask yourself on a regular basis, “Am I having fun?” If not, make time for some.
Please make fun of the boss! :-)

Seattle in late March

Robby Russell — Tue, 20 Feb 2007 18:35:00 -0600

I’m going to be hanging out in Redmond, WA. late next month… why? That… I’ll explain at a later date. ;-)

What I can say is that I’ll be available on a few evenings if anybody is interested in meeting up to talk shop, which can include anything from d3, ruby on rails, bdd, agile interaction design... to BBC comedy shows. :-)

I’ll be flying up from Portland to Seattle on Saturday, March 24th. I’m going to try and stay downtown for that night… and then will be staying at Sheraton Bellevue until Tuesday night. So… Saturday-Monday nights are currently open.

I’m also planning to head to the monthly Seattle.rb meeting on Tuesday, March 27th.

If you’re interested in meeting up, drop me a line.

UPDATE If you’re taking the kinky aspect of BDD too serious... please don’t email me. ;-)

On Apologies

Robby Russell — Thu, 15 Feb 2007 16:01:00 -0600

Recently, Seth Godin posted a short blog post, titled, Apologies, ranked, which points out several ways of apologizing. When you work in a service industry, it becomes very important to develop good apology skills. Let’s be honest for a moment. Not everything works out for the best in every customer experience. Sometimes it’s their fault and many times… it’s our fault.

In response to Seth’s post, Marc Chung has written up a similar post that adapts this to software bugs, titled, Seth on Fixing Bugs.

It’s worth a read and definitely relates to the communication issues that we keep talking about within the Dialogue-Driven Development community and how that can translate to a healthy testing process with BDD.

Thoughts?

Those that Tend the Store need Dialogue

Robby Russell — Thu, 04 Jan 2007 17:18:00 -0600

I’ve been keeping my eye on a series of blog posts by Chad Fowler, which he calls The Big Rewrite.

Today, Chad posted an entry titled, Who’s Tending the Store? He writes…

“the experts keep the old system running while the new system is being built. So, who builds the new system? Not the experts, that’s who. Usually, it’s people like me: technology experts. And while we’re banging away at the existing system’s UI, trying to figure out what needs to be coded, the domain experts are doing their jobs. Unfortunately, this means the domain experts aren’t watching the Big Rewrite very closely. Regardless of how good the team, if communication is impaired between the domain experts and the technology experts, things are going to move slowly, and wrong software is going to be created.”

I wanted to follow up on this issue as it’s an area of great interest to me.

I feel like this issue runs deeper and while it’s important to be mindful of the communication between domain and technology experts, it’s a good idea for each of us to take a break every few days (or everyday) to assess our perceptions in all areas of the project. More specifically, I’m suggesting that in order for us to be effective in our communication, we must make time to refactor our perceptions about the state of a project. From the design, to the development, to team communication, to the schedule, and all the way to customer satisfaction… or what Martin Fowler calls, Customer Affinity. These things are not static and we must see them as extremely dynamic variables… much more dynamic than our wonderful language of choice.

When Brian Ford and I started discussing Dialogue-Driven Development (d3), we were initially focused on an area that always seems to come up in projects. Client communication. From managing expectations to delivering the right product, d3 has become an essential tool in our team’s tool belt. We refactored our entire Design and Development process (and it’s always evolving) to focus on the things that we felt were the most important to a successful project. Clients come to us in search of expertise and guidance so that we can build them innovative solutions. When it comes to this process, clients deserve simplicity.

For starters, we’re misguided

If there is one thing that I have learned, it is that our initial perceptions are often misguided. We have to work really hard to think critically, not only of the problem we’re trying to build a solution for, but also of how we, ourselves, are actually looking at the problem. It’s easy to fall victim to tunnel vision. I often find myself having to take a step back from problems on a very regular basis. While I have no scientific proof to back this, it seems to feels natural for us to keep firing once we pull the trigger. It’s important to re-aim.

Chad raises a very important topic and leaves readers to think about the problem. After thinking about this, it’s my opinion that in order for the domain and technology experts to be effective, they need healthy collaboration. But, I feel like this applies to many other areas of our process as well.

Is there even a problem?

So, what is the solution? Better yet, what is the problem? Is there even a problem?

How can we avoid situations where communication becomes impaired? We’ve all been there. We know how to spot impaired communication, but how can we spot it… before we perceive it as too late? How can we recover from it? What causes the communication to break down? What if… it were possible to repair the situation?

These questions don’t have easy answers. These are complicated problems that reach far beyond the development community. These are the same problems that all members of organizations, communities, countries, and planets all face, each and every day.

Take action!

While it’s important to make sure we’re engaging in healthy dialogue through a project, bad things will happen. They are inevitable. As Agilists, we’re accepting this as a fact of (project) life and should be prepared to take action. If you see communication being impaired, it’s time to step up and help the team out. Otherwise, you’re only hurting yourself… and your colleagues.

“Be the change you wish to see in the world.”—Mahatma Gandhi

If these sorts of topics are of interest to you, I encourage you to join the Dialogue-Driven community and help us figure this stuff out!

Don't Over Promise

Robby Russell — Sat, 18 Nov 2006 21:02:00 -0600

This was from a discussion a few weeks ago on the Dialogue-Driven Development mailing list.

Bob listed five things that promotes dialogue.

Active Listening
Agenda Control
Trust
Follow-Up/Follow-Through
Don’t Over Promise

“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.”

The list has been about as dormant as my blog has the past several weeks. I’m currently reading through King Arthur’s Round Table, by David Perkins, which focuses on different conversation styles and Dialogue: The Art of Thinking Together, by William Isaacs. I hope to share some of what I learn on my blog and with the list. :-)

This Week in d3: 2

Robby Russell — Fri, 20 Oct 2006 17:53:00 -0500

I missed a week… but last week, Brian wrote about one of the Principles of d3: simplicty.

“As a principle of d3, we want our client interaction to be simpler. So we want to talk about problems with our clients. We want these to be the concrete, explicit elements we dialogue about.” (read more)

Today, I asked on the Dialogue-Driven Development mailing list, “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 emotionalattachment to some idea or decision… ...When people are emotionally attached to one particular point of view, they have a difficult time making objective, rational decisions.”—David Goodlad

“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.”—James Adam

This resulted in me thinking up a new term for this horrible infection… implementitus.

“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.”—Josh Knowles

“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.”—Brasten Sager

I’m really excited to get the interact with other people who are facing the same types of obstacles that we are. Being a successful developer requires a lot of discipline and it’s our goal to enhance our communication skills… so that we can reach shared meaning with our colleagues, clients, and users.

If developer to client, developer to developer, or developer to user interaction is important to you… come talk with us in the Dialogue-Driven Development project.

Teams Need Healthy Collaboration

Robby Russell — Wed, 18 Oct 2006 10:05:00 -0500

A few weeks ago, I was explaining some of the concepts behind Dialogue-Driven Development to Michael Buffington and when I said that we were working to create patterns of Dialogue... his immediate thoughts were on code. I don’t remember the exactly how he worded it.. but he basically thought we were working on a parsing tool for grabbing requirements out of emails, messages, etc. I quickly explained that d3 had nothing to do with actual code and was merely a practice that we as developers and consultants are using to think about our interaction with clients, users, and amongst ourselves.

Just last night, I was chatting with a friend of mine about d3… (names changed to protect the guilty)

context: Harry works in a development team¹ of about ten people and Paul is one of his “team”mates.


  Harry: i guess it prevents discussion domination
   me: yeah, that happens as it is sometimes
  Harry: and ensures equal contribution
  Harry: paul does that 
    and he's not very polite about it either
    and will often raise his voice and speak over you
    which is crazy
    kindergarten stuff
  me: hah
  Harry: need a talking stick!

This happens all too often amongst ourselves. While we’re striving to improve our client interaction… we often overlook our own internal struggles to achieve healthy collaboration. It takes discipline by every individual in a collaborative environment to really think together.

So, how does d3 address this? Well, it’s our goal that through mindful dialogue, we can cultivate healthier collaboration in all of our professional (and personal) relationships.

I would also like to point out a few common misconceptions about d3.

d3 is not a methodology… nor a replacement for Scrum or XP. d3 is a thoughtful practice that focuses on the collaboration between a group of individuals, whether they be clients, developers, managers, or users.
d3 is not a Silver Bullet, but it can be used as effective ammunition.
d3 is not something you learn in a weekend, but you might be able to find a good book on Dialogue and have a new perspective on how you communicate with others.

Dialogue-Driven Development is about being in the conversation as it is happening… and really listening.

The next time that you’re getting ready to interact with your teammates, ask yourself:

Am I contributing something meaningful?
Am I listening to others well?
Is everybody contributing an equal share of information?

If you’re quiet, try to speak up more. If you talk too much, be mindful of how much you may dominate a conversation. If you’re not participating at all.. why are you there?

¹ You’ll be happy to know that Harry also gave his two-weeks notice yesterday.

The Circular Perspective of BDD

Robby Russell — Thu, 12 Oct 2006 09:56:00 -0500

A few weeks ago, Brian Ford was in my office and we were discussing BDD and how we can make this process even easier for our clients to understand… much less our own internal staff. With all concepts, each person has their own idea about what it is, why it is important, regardless of whether or not it’s accurate. This can cause some people to not find a good need for some practices.

During our discussion, Brian grabbed one of my whiteboard markers and drew diagrams to explain how he saw BDD vary from TDD. He has since posted an article on his blog titled, what’s it worth to me, and discusses his circular view of Behavior-Driven Developent and the importance of using Dialogue to evolve shared meaning.

Dialogue versus Debate

Robby Russell — Tue, 10 Oct 2006 00:40:00 -0500

How many times have you participated in a conversation with someone and realized that you really didn’t understand what they had said. Or… perhaps you’ve been talking and even though the other person is nodding, you’re not confident that they’ve really heard what you’ve been saying. Yet, you might find yourself nodding in agreement when they speak… and walk away… totally clueless about what you just talked about.

Were you really listening? Were they speaking over your head? Were you speaking over their head? Perhaps you were distracted? Whatever the reason… it’s probably worth thinking about. We all do it from time to time.

Even worse, you were only thinking about how they were wrong and you had the right answer already in your head…

In Dialogue, there are rules for participation, which we’ll explore in future writings.

One might wonder if we’ve been trained to work this way. In school, we had classes that taught us to debate one another… further cultivating a society focused on you versus I. But, what about the community? What about the team? What about us? Sadly, most of the teamwork that we saw encouraged was in the form of sports. To be fair… we did have debate teams… but the purpose was to argue for one side of an argument… not to find a way for both sides to work together. One might wonder our society would be like if we encouraged Dialogue in the same way.

Perhaps we need Dialogue teams. ;-)

Dialogue allows teams of people to work together. It’s a process that cultivates learning and discovery. Dialogue is not a process that encourages the passing of judgement or pushing for specific outcomes… the aim is to share understanding. Through empathetic listening and questioning, the seeds of trust are planted.

Dialogue-Driven Development is about building trust.

I came across this great table, which contrasts Dialogue and Debate. It’s worth taking a few moments to review.

Here are a few that caught my attention…

Dialogue	Debate
Dialogue is collaborative: the sides work together.	Debate is a type of fight: two sides oppose each other to prove each other wrong.
In a dialogue the goals are finding common ideas and new ideas.	In a debate the goals is winning with your own ideas.
In a dialogue you contribute your best ideas to be improved upon.	In a debate you contribute your ideas and defend them against challenges.
In a dialogue you listen to each other to understand and build agreement.	In a debate you listen to each other to find flaws and disagree.
In a dialogue you may consider new ideas and even change your mind completely.	In a debate you do not admit you are considering new ideas and you must not change your mind, or you lose.
Dialogue encourages you to evaluate yourself.	Debate encourages you to criticize others.
Dialogue promotes open-mindedness, including an openness to being wrong.	Debate creates a close-minded attitude, a determination to be right.

There is something to be said about the art of Dialogue, which is why we’re so excited about the d3 project.

This Week in d3: 1

Robby Russell — Fri, 06 Oct 2006 17:01:00 -0500

As overheard on the d3 mailing list...

“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.”—David Goodlad

“People have emotional attachments, pet ideas, favorite ways of doing things, and they are quick to impose those, under the guise of “business requirments”.”—Brian Ford

“Dialogue-Driven Development has the opportunity to step up in this environment and redefine the interaction between customers and developers.”—Brasten Sager (link)

..we’re just getting started. ;-)

If developer to client, developer to developer, or developer to user interaction is important to you… come talk with those of us involved in the Dialogue-Driven Development project.

Announcing the Dialogue-Driven Development Project

Robby Russell — Tue, 03 Oct 2006 08:30:00 -0500

I woke up this morning and came across an article written by Brasten Sager, titled, Of Dialogue and Development in which he discusses his initial (and healthy) criticism of Dialogue-Driven Development.

But d3 is an evolving thing. Its earliest forms offered very little definition, leading me to believe there was little to it. As it has evolved the goals and mindset of d3 and its proponents have become a little more clear, and after further consideration I’m now convinced that my original critiques may have been wrong.

I encourage you to read his article, which offers ideas (and diagrams) on how d3 might be injected into your existing process.

A small number of interested developers have been sending us questions about d3 and were wondering what the next step was for the community. We’re working hard on outlining patterns of dialogue, which is where we plan to put of our focus into. A small group of people have joined our mailing list and IRC channel over the past few weeks, where some conversations have occurred. After reading through Brasten’s post, I believe that our IRC conversation last week was a good example of how people with different ideas about something… can come together and have a shared understanding, which is exactly what Dialogue-Driven Development is about.

Through shared understanding, we can accomplish so much more.

“In true dialogue, both sides are willing to change.” —Thich Nhat Hanh

Thanks to the hard work of Brian Ford, we now have a website to announce, which will be the portal to various conversations, patterns, and resources related to Dialogue-Driven Development.

http://www.dialogue-driven.org

Project Enlightenment with d3

Robby Russell — Wed, 27 Sep 2006 02:38:00 -0500

What do we mean exactly when we say that we want to participate in thoughtful dialogue in a project? What is our intention with this? When I recently came across some essays by David Gurteen and read his definition of dialogue as being “a disciplined form of conversation” it got me thinking about how we often forget that like all skills, practice makes perfect. What make our conversations discilplined in the first place? Based on my experience, dialogue (disciplined conversation) manifests when all participants in a conversation are practicing mindfulness. I don’t believe that most people learn or behave well by being beaten into submission, so we must come to an understanding while we actively involve ourselves in dialogue. Most of us are civil towards one another, which does wonders for allowing us to tolerate each other, but I still can’t help but feel that we’re still missing the mark when it comes to having consistent and thoughtful dialogue.

Over the past several months, our team has been spending quite a bit of time and energy analyzing these problems. What we really starting to uncover is that the real problem seems to exist somewhere outside of our development methodologies. Working under the Agile umbrella provides no silver bullet. The real issues seem to exist much deeper in our human nature.

We’re not all that great at communicating

Humans are not perfect… therefore… our ideas are probably far from perfect as well. Our thoughts aren’t perfect. Our interactions aren’t perfect. We’re consistently inconsistent (heh) and while we can rely on averages to some extent to calculate probabilities, we can’t always explain why somethings still go horribly wrong. The principles outlines in the Agile manifesto stress the importance of focusing on people not processes and responding to change. If we are to put a heavy focus on the people involved in projects, we must acknowledge our strengths and weaknesses and find innovative ways to improve our communication skills.

On a daily basis, we’re faced with complex problems. Hopefully, we’re using a lot of our prior experience to aid us in making rational decisions about how we respond to them. There is a lot that goes through each decision that we make. We can’t automate this process (yet), but we can definitely share our lessons with one another. Our intentions need to be thoughtful and empathetic to the needs of all parties affected by each decision. As humans, we have the opportunity to really listen to the concerns of others and use not only our logical intelligence… but also our emotional intelligence.

Much of this comes down to each of us learning to understand how we make decisions and interact with people. It’s our goal with Dialogue-Driven Development that with your help, we’ll be able to outline patterns of dialogue, which we hope will be of great value to the community. Our team has been analyzing our interaction with clients and discussing what has worked well and what hasn’t. How did our clients respond to approach X versus Y? It’s important that we capture this information and have conversations about the results.

“The meaning is what holds it [dialogue] together. ..Meaning is not static – it is flowing. And if we have the meaning being shared, then it is flowing among us; it holds the group together…in that way we can talk together coherently and think together.” – David Bohm

Doesn’t that sound beautiful? Who wouldn’t want to reach such levels of project enlightenment?

d3 aims to be to communication what BDD is to specification

While at RailsConf Europe, I had the privilege to speak with several Rail developers… several of which are doing contract development for several clients, just like our team. We discussed d3 for a while and I walked away feeling really excited about the whole concept. When I explained that our team didn’t see d3 as a replacement for Agile methodologies like Scrum, XP, etc… but as another tool in our tool belt. Dialogue between developers, clients, and users should be agnostic about particular methodologies. We’re really excited about Behavior-Driven Development as a best practice in our development process and we’re seeing Dialogue-Driven Development as another best practice that we start using from the initial point of contact with a potential client to long after we deliver the working product that we were contracted to develop.

We’ll be posting some fun announcements about the d3 project in the coming week(s). Stay tuned…

Matz on Considering Interface

Robby Russell — Mon, 25 Sep 2006 10:11:00 -0500

...back in Portland after being in London and New York City for the past two weeks. It’s nice to be home. :-)

I came across this interview with Matz earlier today. It was published almost three years ago (pre-Rails)... I’m quite intrigued by what he is advocating here…

Bill Venners: You also mentioned in your ten top tips: “Be nice to others. Consider interface first: man-to-man, man-to-machine, and machine-to-machine. And again remember the human factor is important.” What do you mean by, “consider interface first?”
Yukihiro Matsumoto: Interface is everything that we see as a user. If my computer is doing very complex things inside, but that complexity doesn’t show up on the surface, I don’t care. I don’t care if the computer works hard on the inside or not. I just want the right result presented in a good manner. So that means the interface is everything, for a plain computer user at least, when they are using a computer. That’s why we need to focus on interface.

Some software people—like weather forecasters, the number crunchers—feel that the inside matters most, but they are a very limited field of computer science. Most programmers need to focus on the surface, the interface, because that’s the most important thing.

Bill Venners: You also mentioned machine-to-machine interfaces, so are you just talking about interfaces for users or also for machines?

Yukihiro Matsumoto: It’s not just user interfaces. When machines are talking to each other via a protocol, they don’t care how the other is implemented on the inside. The important thing is the proper output getting passed correctly via the proper protocol. That’s what matters.
If you have a good interface on your system, and a budget of money and time, you can work on your system. If your system has bugs or is too slow, you can improve it. But if your system has a bad interface, you basically have nothing. It won’t matter if it is a work of the highest craftsmanship on the inside. If your system has a bad interface, no one will use it. So the interface or surface of the system, whether to users or other machines, is very important.

One of things that we’re really advocating with Dialogue-Driven Development is artifact generation. Wireframes and lightweight prototypes are great for generating constructive dialogue between clients, users, and our team. We should make sure that we understand why and how users will use an interface before we worry about the code that will drive it. Too often we fall into a pattern of thinking where we’re convinced that we can build an agnostic application that has various interfaces to a central repository of business logic and data. While we strive for this during development, it really should be focused on after some initial interaction design has been planned. Of course, this is my opinion.

So, I must ask you. When you’re working with on a new project, do you focus on interface or code implementation first?

The Technology of Dialogue

Robby Russell — Tue, 12 Sep 2006 14:30:00 -0500

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 dialogue¹:

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?

¹ The Discipline of Dialogue by David Gurteen

Dialogue-Driven Development is about Listening

Robby Russell — Fri, 25 Aug 2006 19:11:00 -0500

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 settlement¹.

What is a conversation?

informal interchange of thoughts, information, etc., by spoken words; oral communication between persons; talk; colloquy²

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.

“Having two ears and one tongue, we should listen twice as much as we speak.”
“Don’t try to formulate your reply when the other person is speaking.”
“The person who starts a sentence should be the one to finish it.”
“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.”
“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. :-)

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

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

Information Anxiety and Solutions

Robby Russell — Tue, 22 Aug 2006 13:15:00 -0500

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

Robby Russell — Wed, 16 Aug 2006 12:26:00 -0500

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.

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

Project Illuminatus, an introduction

Robby Russell — Mon, 14 Aug 2006 19:52:00 -0500

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…

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

² 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

Robby Russell — Tue, 08 Aug 2006 12:15:00 -0500

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 me^{W^W}Wlets 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…

Clients Deserve Simplicity

Robby Russell — Sun, 06 Aug 2006 22:57:00 -0500

A few months ago, I posted an article titled, Trawling for Requirements, which was just before the Argon Express left for our trip to Chicago for RailsConf 2006. I’ve been kicking around some ideas with Brian ever since that afternoon on how there just seemed to be a big void in software development arena. It’s always felt that so many of the software development methodologies are designed to get developers to find a better way to work for and with clients. It’s our goal to outline a pattern that simplifies this process, not just for ourselves, but also our clients.

With each new project that our team starts, we are given an opportunity to improve on our evolving pattern for communicating with clients to better understand their goals. If there is one thing that we’ve seen help this process, it is consistent dialogue. When good collaboration exists through meaningful dialogue, confidence increases in not only the client. As developers, we are able to be confident that we understand their goals. This should generate better results.

“You are not writing requirements to serve as a contract with your client. Rather, you are writing them to ensure that both of you share the same and demonstrably correct, understanding of what is needed. Do not ask the client to sign off on the requirements; instead, ask the client to sign on to them and make them a collaborative effort.”

—Suzanne and James Robertson, Mastering the Requirements Process, 2nd Ed.

In Mastering the Requirements Process, the authors list the following as being key to identifying the project goal.

Purpose: What should the project do?
Advantage: What business advantage does it provide?
Measurement: How do you measure the advantage?
Reasonable: Given what you understand about the constraints, is it possible for the product to achieve the business advantage?
Feasible: Given what you have learned from the blastoff, is it possible to build a product to achieve the measure?
Achievable: Does the organization have (or can it acquire) the skills to build the product and operate it once built?

At first glance, I would agree that these are good questions to find answers for with your client.

Requirements, Not Solutions

Many clients come to us with a list of solutions (features) that describe implementation. This has been one of our concerns with the Product Backlog as it doesn’t discourage feature lists. Take a moment to read Goal Oriented Requirements, which gives you a few bullets to think about when interacting with your client when extracting requirements.

Take a moment to read Brian’s thoughts on the product backlog.

In Mastering the Requirements Process, the authors give two examples to show the difference between a solution and a requirement.

A Solution

The product shall display pictures of goods for the customer to click on.

A Requirement

The product shall enable the customer to select the goods he wishes to order.

When requirements are defined in this form, it allows for further dialogue about multiple implementations.

For example, we’re working on a project where the product shall enable the users to send messages to a central system. We’ve defined a few specific implementations (email, text message, web form) and know that as new technologies emerge, the same requirement will still apply. It’s important to remember that we are gathering requirements not solutions and from there… we can collaborate with the client to design a solution that fits the requirements. Before we attempt to do solve the problem, we must ask that the requirement is aligned with the project goal.

We want our clients to assimilate our development methodologies quickly and naturally, which is what Dialogue-Driven Development aims to help achieve—namely through communication, something we humans do rather well. By lowering the learning curve and accelerating the integration of clients into our process, we can focus a greater sum of our collective energy on the needs of the client, the purpose of the project, and the goals of it’s users.

Although, perhaps we have it all wrong when trying to make software and the development process simpler as Paul Kedrosky suggested. ;-)

Our clients don’t just want simplicity. They deserve it!

Dialogue-Driven Development is about rounded corners

Robby Russell — Sat, 05 Aug 2006 10:49:00 -0500

In response to our introduction of Dialogue-Driven Development, mechanismalley.com writes, ”...it seems to be the Rails community’s pattern to take an existing concept — or misconception — put rounded corners on it and deem it something new.” (link)

I’m not sure that I can completely agree with this generalization. What I’ve witnessed as a member of the Rails community, is an attempt to simplify code, solutions, processes, and as a result… conversation between developers and clients has become much richer and coherent. Take this with a grain of salt as this has only been my experience. Complex solutions are complex to explain and often too complex to know if they are actually solving the right goal. On the other hand, simple solutions make way for better dialogue. With Ruby on Rails, we are provided with a foundation that encourages and embraces best practices and simple solutions (rounded corners?), which makes it easier to discuss with the client. This is what fascinates me about Ruby on Rails… and what Martin Fowler in his keynote at RailsConf.

Perhaps it makes sense that what Brian and I are outlining with our approach to defining patterns for client<->development team interaction evolved through us working with Ruby on Rails. However, there is nothing that requires Rails in order to follow the patterns that we’re discussing. In Brian’s first article about d3, he referenced the following…

“What we are seeing is a drive toward simplicity. Conventional wisdom once was “quick necessarily means dirty”. Ruby challenges that.
—Martin Fowler

At the very core of our approach with Dialogue-Driven Development is the Agile Manifesto. The author of this post is correct, we’re taking an existing concept and putting rounded corners on it. We’re trying to make it simpler. We find that Scrum is too process heavy and while we can see it being a good step away from the Waterfall approach, it’s still not giving us that warm and fuzzy feeling. Rails developers know what that warm and fuzzy feeling is… and we are hoping to find something that gives our clients and us the same feeling when we’re not coding. We want lightweight methodologies to complement our lightweight frameworks and patterns.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

—The Agile Manifesto

It’s time to start rethinking how we work with clients. Too often we end up working for them and while we might build them what they want… we might not be giving them what they need.

So, I must ask… has working with Ruby on Rails reshaped the way you think about client and developer conversation? If so, for the better or worse?

High traces of collaboration and dialogue are usually found in the recipe of any successful project.

One cuckoo flew over the nest, Brian Ford
Dialogue-Driven Development
Dialog driven development is the real agile, Damien Tanner
Dialog driven development, Lazy Coder
It’s all about the dialogue, Brian Ford