Robby on Rails: Tag agile

Basecamp...

Robby Russell — Wed, 04 Jun 2008 12:13:00 -0500

Kudos to the 37signals team for launching what looks like a nice way to get the word out about their products.

I’ve been using Basecamp for three years and it’s been a great tool for collaborating with our clients.

Disclaimer: This is my get-rich-quick scheme for the day.

The Art of Delivery, part 2

Robby Russell — Thu, 22 May 2008 13:42:00 -0500

Two years ago, I wrote an article titled, The Art of Delivery. I wanted to post a few updates based on how our process has evolved since then (and continues to).

Over the past few years, we’ve been fortunate enough to work on quite a diverse collection of projects. This has enabled us to work with many different clients and solicit feedback on our process. This has given us an opportunity to evolve a set of best practices that fulfills the long-term project goals/budgets of our client while making sure that we’re able to maintain a design and development process that is agile.

As I’ve mentioned in previous posts, our team typically bills work per-iteration on projects rather than per-hour or a flat-bid per-project. Since iterations are bite-sized pieces of the entire project and limited to 1-2 weeks, our teams estimates are much more accurate and we’re able to keep things rolling and on track.

The basic structure of our project looks like this.

A Project has many releases
A Release has many iterations
An Iteration has many deliverables
A Deliverable has many tasks

Before we begin working on an iteration, we outline a set of goals that we want to create solutions for. This process comes out of discussions between our client and us until we agree on what is the highest value/most critical to the success of the project, based on our shared understanding of where we are today. These goals translate into Deliverables, which in a typical iteration might require Interaction Design, Interface Design, or Development. We tend to break our process up into stages so that Interaction Design on Module XYZ would be implemented in a following iteration. This is because it’s unrealistic to expect someone to provide an accurate estimate on how long it’ll take to implement something before you know how people will interact with it.

Within any given iteration, our team is spread across several sets of deliverables. As a team, we breakdown these deliverables into smaller sets of tasks. It’s our aim to keep tasks smaller than a full days worth of work as it’s much easier to measure progress across the iteration when we can track tasks at a granular level.

Essentially, tasks are the individual steps needed to achieve these goals. We don’t go out of our way to list each one of those during an estimate process as some tasks take less time than it takes to generate an estimate for them. Each person providing estimates should avoid getting too granular and aim to find a good balance that compliments their workflow.

Like most things… mileage may vary.

Through this process, we can get calculate the estimated costs for each deliverable, which then provides us an cost for the entire iteration. In addition to deliverables, we also budget a set of hours/days so that we can be compensated for handling small requests, bug fixes, and project management. It’s important to factor these things into your process.

In future posts, I’ll discuss how we’re handling this process while working on multiple projects… as that’s where it can chaos can start if you’re not careful. ;-)

How does your team work? As we’re always evolving our process in an effort so that we can be more efficient and speed up our delivery cycle, I’d love to learn from those in the community.

The Argon Express 2008? It's not too late!

Robby Russell — Wed, 05 Mar 2008 18:39:00 -0600

Picture yourself and your laptop. It’s been over a day and you’re sitting on a train with a group of Rails developers with a view like this over your shoulder.

Hacking and reading on the train.

Enjoying the sceneary of the U.S.A.

Two years ago… a group of us went from Portland to Chicago for RailsConf 2006 on the Argon Express.

I know this is a tad late… but uf you haven’t purchased plane tickets to Portland yet for CabooseConf or RailsConf 2008 and would be interested in catching the train from somewhere the East Coast, email me and we’ll talk. I’m hoping to organize the Argon Express 2008 over next few weeks.

Embracing Chaos, part 1

Robby Russell — Mon, 17 Dec 2007 22:21:00 -0600

Consider this part one of several posts on my thoughts of the art of embracing chaos.

Don’t let the books fool you. The construction of custom software is an unmastered and volatile cesspool of chaos. I don’t adhere to the belief that there is a perfect methodology or process that will work for every project… as I’m sure many of you don’t.

Unlike bowling, you’ll never achieve a perfect score. Even in bowling, It’s unlikely that anybody will learn how to bowl a perfect score and do so on every game for the rest of their career.

You’ll never meet every expectation that a client has on every project.

You’ll never meet every expectation that a user has when they interact with your application.

Expectations are an interesting thing.

Your project might get widely adopted and embraced, but you’re still trying to control chaos.

It’s chaos. Pure chaos¹.

So, why do we bother? Why do we try so hard when the odds aren’t in our favor?

To be continued…

¹ Chaos Theory, Wikipedia

Skitch... my favorite desktop application of 2007?

Robby Russell — Tue, 20 Nov 2007 13:04:00 -0600

It just occurred to me that my first Skitch was on July 7th, 2007. 7/7/7. I’ve been meaning to post an article about how Skitch has changed the way our team approaches reporting bugs and communicating ideas visually.

First of all, the Skitch web site advertises it (see video) as a fun tool for playing with photos and sharing stuff with friends/family. While this is true, I think their bigger market could be those of us who work in the web design and development community. It took a less than a week for Skitch to become a tool that I rely on the most during my day to day work and since it keeps surprising me that people aren’t using it and/or haven’t heard about it… I thought that I’d share how we’re using it at Planet Argon.

Introducing “LOLBUGZ”

Our team is currently using Lighthouse for managing bugs/tickets for internal and client projects. If there is one way to slow down bug fixing cycle.. .it’s the ticket submission process. It takes a lot of time and commitment to try and communicate some problems that you’ll find in a web application. This is why screenshots can be so useful to helping speed up the process. Skitch allows us to not only provide a screenshot really quickly, but it gives us the ability to focus our attention with shapes and text, which provides more context when viewing an image.

For example, here are a few real-world Skitches that I’ve used to report some problems.

What happened to this drop down?

This pagination needs some CSS-Love!

Oh no! Tags are getting grouped together…

Styling has gone crazy…

I mastered an unordered list! (hooray!!)

This list isn’t scaling anymore…

Side note: LOL BUGZ was a term coined by Rick Olson at Active Reload to describe the tickets that I post for Lighthouse. ;-)

Trying out 15 during the initial releases for the iPhone… bug report sent via twitter to Erik Kastner.

As you can see, using Skitch helps communicate some very specific things without needing to type a huge description. Of course, we do try our best to add more context with our tickets. For example, here is a real-world example of a ticket that I posted on Lighthouse. As you’ll see, there are a few skitches embedded in the tickets, which works much better than attaching screenshots to tickets.

One of the best features of Skitch is it’s work-flow. Within a few seconds, I can do the following tasks.

Take a screenshot of a specific region of my screen
Add some arrows and text
Click on Webpost, which will upload directly to myskitch.com
Click on Share to navigate to the new upload
Click on the embed textfield and it uses JS to copy the embed html into my paste buffer
Paste the html snippet directly into the ticket that I’m reporting
Submit my LOL BUG

Side note: it also allows you to upload to Flickr, a ftp account, etc.

Over the past four months, Skitch has become one of my favorite OS X tools. The interface is lightweight and the workflow is almost perfect (feature request: providing the embed code in my paste buffer without needing to go to myskitch would be A+++)

I’ve also used Jing, which works on Windows and OS X and does video. I’ve not found it to be as intuitive for working in this manner. In fact, the work-flow leaves a lot to be desired. However! It does do video and this has come in handy a few times for showing people some “live” interaction-type bugs that can’t be communicated as easily through text/images.

If you’re not using Skitch yet and are on OS X… I highly recommend that you try it out for a few weeks during a bug fixing sprint. We’ve gotten our clients and almost everybody on the team using it in this fashion. The productivity increases haven’t gone unnoticed.

That’s not to say that it’s not fun for point out things that aren’t related to your project bugs. ;-)

Happy Skitching!

UPDATE

Plasq liked the writeup and gave me 50 extra invites to pass out for Skitch. So, if you’re in need of one… ask me via email. Thanks Plasq team!

Designers, Developers, and the x_ Factor

Robby Russell — Wed, 01 Aug 2007 00:39:00 -0500

Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.

Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.

I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.

Scenario #1: The case of the changed div id, (victim: designer)

Designer adds a few HTML elements to the page, defines an id on a <div> tag and styles it with CSS.
A few days later, a developer needs to make some changes, tests it in their favorite browser and commits.
Later, the designer doesn’t understand why the styling is all messed up. “It was working fine.”
...minutes, hours… go by where the designer tries to track down the issue. “Oh! Someone renamed the id in this <div> tag. Sigh.”
Developer apologies, but explains that he needed to do it because he needed to make it work with his new RJS code.

Scenario #2: The case of the changed div id, (victim: developer)

Developer is implementing this cool new Ajax feature into the web application
- The code relies on there being one or many HTML elements in the DOM with specific id values defined.

Example: <div id="notification_message">

A few days later, a designer is making some changes to the layout and needs to restyle some of the view that this <div> tag is defined. Designer decides to change the id to a different value for any variety of reasons. (or perhaps they changed it to use a class instead of styling it by the id). Often times, we don’t know who set the id or class… and many times the developers aren’t savvy enough with HTML and designers end up cleaning things up a bit.
Later, code is checked in and designer didn’t notice that the Ajax was now breaking as they weren’t focusing on just the layout.
Day or two later, developer sees bug, “Feature X isn’t working, throwing JavaScript error…”
Developer is confused, “Hey, that was working! What happened?”
Developer tracks down the problem, discusses with designer, they figure out a solution. Problem solved.

I could outline a few other examples, but I really wanted to highlight these two types of situations, as our team has seen this happen on several occasions. Luckily, we’ve learned through these experiences and have taken some measures to try and avoid them in the future.

Moving forward (together)

Both of the examples above, were essentially the same problem, but resulted in problems for a different role in the design and development cycle. While, I’ve definitely been the victim of #2 several times myself, I know that I’ve also been the guilty of #1. So, what can we do as designers and developers to work with each other without causing these little problems from occurring? (remember: many little problems can add up to a lot of wasted time spent resolving them)

Several months ago, I had a meeting with Chris (User Interface Designer) and Graeme (Lead Architect/Developer) to discuss this very problem. At the time, we were implementing a lot of Ajax into an application and were occasionally running into Scenario #2. We discussed a few possible ways of communicating that, “yes, this div id should NOT be changed (without talking to a developer first)!”

Idea 1: Comment our “special” HTML elements

We discussed using ERb comments in our views to do something like the following.


  <% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
  <div id="notification_message">
    ...

We all agreed that, while effective, it was going to clutter up our RHTML code more than any of us desired.

Team Response: Meh.

Idea 2: Reserve id’s for developers

Another idea that came up, was to ask that designers only use classes and ids wold be used by the developers when they needed it.


  <div id="developer_terriroty" class="designer_territory">
    ...

Chris pointed out that this wasn’t an ideal solution as there is a distinct case for when to use ids versus classes.. and he is very strict about adhering to the HTML/CSS standards.

Team Response: Not hot about it…

Idea 3: Naming convention for Ajax-dependent elements

The third idea that was discussed, was specifying a naming convention for any elements that were needed by our Ajax code. We played around on the whiteboard with some ideas and settled on the idea that we’d prefix our id’s with something easy to remember for both designers and developers.

We agreed on… x_ (x underscore), which would make an element id look something like this:


  <div id="x_notification_message">
    ...

x == ajax... get it?

While this adds the strain of typing two more characters to much of our RJS code, we don’t run into Scenario #2 very often anymore.


  render :update do |page|
    page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
    page[:x_notification_message].visual_effect :highlight
  end

or in client-side JavaScript (where we also use this)...


  $('x_notification_message').do_something

I find that this helps our team keep a clear distinction between what can and shouldn’t be changed in the views by our designers. Sometimes they have a good reason to do so, but they know that if there is x_, then they should ask one of the developers on the team for assistance in renaming it without causing any problems in the application. It also allows our designers to add classes to these elements, or style the id that we’ve defined.

Team Response: Wow, was that all we needed to agree on? Hooray!

This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.

If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?

Until next time, remember to hug your designer. ...and if you’re still having developer design your applications, consider hiring a designer. ;-)

UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)

Berkun introduces ADD

Robby Russell — Tue, 19 Jun 2007 17:22:00 -0500

Author of The Art of Project Management, Scott Berkun, introduces Asshole Driven development.

“Asshole Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.”

Read the rest…

Rails Business: Weekly Review #2

Robby Russell — Mon, 18 Jun 2007 01:26:00 -0500

First of all, I’d like to welcome the more than fifty people that have joined the Rails Business group since my last post. Over the past week, there were less posts, but we did cover a few important topics, which may be of interest to you.

Subcontracting

Michael Breen asked a few questions about subcontracting for larger firms and how people set their rates when doing this. Several of the responses provided some personal experiences (good and bad) of being a subcontractor on large projects. Where some risks are and how to negotiate your rates, when applicable.

Read the discussion

Change Requests

Nick Coyne started a discussion on how to manage change requests in an Agile development process.

Dealing with large clients

There was also a discussion about how to go about responding to a 150 page RFP for a large client. A few of us offered our experiences of bidding on large projects. Read more

Join the Community

The list is about to pass 400 members and it’s already proving to be a valuable resource for all of you entrepreneurs out there. I encourage you all to introduce yourself.

For more info: http://groups.google.com/group/rails-business

BDD is still kinky

Robby Russell — Tue, 10 Apr 2007 16:51:00 -0500

I still believe that Behavior-Driven Development is kinkier than Test-Driven Development...

Embracing Failure, part 1

Robby Russell — Tue, 10 Apr 2007 16:38:00 -0500

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

In what ways is your team embracing the failures of your development projects?
How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

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.

Is BDD kinkier than TDD?

Robby Russell — Thu, 08 Feb 2007 13:20:00 -0600

If you’re in need of a compelling reason to switch from Test-Driven Development to Behavior-Driven Development... consider this.

“BDD sounds kinkier.” -Michael K. Loukides, Book Editor for O’Reilly

...on that bombshell... I am going to suggest that this be used as the official BDD logo.

There you have it. Deep down… the biggest reason that I switched from Test::Unit to RSpec... was the sex appeal. ;-)

What was your reason?

Rails 1.2 On CRN.com

Robby Russell — Sun, 28 Jan 2007 13:58:00 -0600

I was recently asked a few questions by Stacy Cowley, a writer for CRN about the Rails 1.2 release and how our Design and Development team at PLANET ARGON is adopting it. This Q&A session resulted in a brief article titled, Ruby on Rails Gets RESTFul in Major Update, which appeared on the CRN site last Friday afternoon.

Thanks to the Rails Core team and all of those in the community who continue to help make Ruby on Rails an awesome addition in my tool belt.

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!

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.

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

Agile Interaction Design

Robby Russell — Wed, 30 Aug 2006 14:36:00 -0500

I would like to start some dialogue with all of you…

In a recent post, Jeremy Voorhis said the following about About Face 2.0 in his post announcing his Agile Book Club.

About Face 2.0 isn’t bad; it’s full of some great advice. My biggest gripes with it are the follows:

It declares that programmers are just unfit for interaction design.
It advocates for waterfall development.
Cooper has a defensive tone whenever discussing his beloved discipline of interaction design.
The web chapter is dated.
If you can get over all of those things, it is full of great ideas, specifically about working with personas, and data entry and retrieval.

I disagree with a few of these conclusions. In particular, that Cooper advocates waterfall development. I’ve been hearing a lot of developers throw the word, “waterfall” around… but why?

Take the following excerpt from this great conversation between Kent Beck, the father of XP, and Alan Cooper.

“During the design phase, the interaction designer works closely with the customers. During the detailed design phase, the interaction designer works closely with the programmers. There’s a crossover point in the beginning of the design phase where the programmers work for the designer. Then, at a certain point the leadership changes so that now the designers work for the implementers. You could call these “phases”—I don’t—but it’s working together.”[1]

I’m curious as to how anyone would consider this to resemble Waterfall, which might imply that Cooper’s approach to Interaction Design is incompatible with the principles behind the Agile Manifesto.

Dave Churchville posted an article last year titled, Agile Interaction Design?, which discussed how the role of an Interaction Designer (ID) can be compatible with Agile methodologies. “An ID team probably becomes the voice of the customer in Agile methods, and as such should be working closely with the development team as well as the users. In that sense, the ID role may be more of a liaison between customer and developer.”

So, do you think that Interaction Design as described by Alan Cooper… is compatible with the principles of the Agile Manifesto?

UPDATE It looks like this conversation was picked up on the Joel on Software discussion boards.

¹ http://www.fawcette.com/interviews/beck_cooper/page8.asp

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…

Extreme Motivational Posters

Robby Russell — Mon, 07 Aug 2006 11:55:00 -0500

Take a look at these extreme programming motivational posters.

Found via Think Box.

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!