iBrasten

“In such a dialogue, when one person says something, the other person does not generally respond with exactly the same meaning as that seen by the first. Rather, the meanings are only similar and not identical. Thus, when the second person replies, the first person sees a difference between what he meant to say and what the other person understood. On considering this difference, he may then be able to see something new, which is relevant both to his own views and to those of the other person.”

\- David Bohm

For the last little while, I have been less than supportive - even mildly critical - of Dialogue-Driven Development as purported by Robby Russell, Brian Ford and the rest of the PLANET ARGON team. The concept originally appeared to arise from a series of blog posts and discussions on the topic of development processes in use at PLANET ARGON, of which most were derived from existing Agile methodologies.

My critiques of Dialogue-Driven Development (or “d3”) were primarily driven by a belief that the newly-named methodology offered nothing new to the Agile family, and even resembled existing Agile methodologies like Extreme Programming too closely to be considered distinct. Mixing practices of various Agile methods is always a good idea and should be encouraged, but repackaging methodologies - with no additional value added - is pointless at best. This formed the basis of my critiques regarding 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.

It is important to note that I am not a driving force behind Dialogue-Driven Development and the opinions in this post are just that—my opinions. d3 itself will evolve in a manner acceptable to its primary supporters at PLANET ARGON and the software development community as a whole.

Evolving Dialogue-Driven Development

Dialogue-Driven Development’s impact on software development will depend on its purpose and the practices it defines. The worst possible outcome for d3 would be to become Yet-Another-Agile-Methodology by concerning itself with the practices implemented during development phases.

Instead, d3 is uniquely positioned to alter the way developers and customers interact in an Agile environment. It is my opinion that d3 should take advantage of it’s core principle - dialogue - in two ways: firstly, d3 should redefine how customers interact with the Agile development process; and secondly, d3 should encourage the creation of dialogue patterns, specifically those regarding requirements gathering and customer feedback.

A New Interface to Agile Development

During a recent chat with a d3 proponent I was confronted with the statement “my customers do not want to learn scrum.” It resolved a dilemma I’d been having with myself for some time on how to prod customers into better agile practices. While I pride myself on considering all available options in most situations, I have to admit that this one took me by surprise. I had never considered that the answer to my dilemma was: you don’t. And yet, there it was. My customers do not want to learn agile.

Dialogue-Driven Development has the opportunity to step up in this environment and redefining the interaction between customers and developers. Under my version of d3, agile development methodologies and practices are trimmed in the areas related to customer interaction. Agile becomes primarily a tool of the development team—no less important, but perhaps less visible.

Dialogue-Driven Development would provide a formal method of interaction between customers and developers, defining various methods, goals and artifacts involved in the dialogue process. Requirements gathering and feedback can then evolve independently with the sole purpose of improving customer interaction—without the constraints of any particular development framework.

It is important to make the point that dialogue would be the result of the process, not the execution of the process. It rests on the shoulders of d3 to discover and define what dialogue is and how to accomplish it reliably.

Well-defined Dialogue Concepts

Different ideas of dialogue will produce different results, so it is critical to the success of d3 that the concept of dialogue is well defined and easily understood. David Bohm provides a detailed look into the concept of dialogue and is currently highly regarded amongst the proponents of d3. Adapting Bohm’s ideas to customer / developer interactions would provide a solid base from which d3 could evolve. Several aspects of Bohm’s dialogue concept have the potential of greatly increasing mutual understanding of the project.

As a couple of examples:

1. Encouraging awareness of emotional or intellectual reactions.

Bohm explains that every individual holds certain truths that will be irrationally defended with minimal provocation. This is true even in business and technical settings.  Recognizing reactions to technologies, buzz-words and the like could give extremely valuable insight into the customer and their needs, even if they would not be able to articulate it themselves.

2. Creating something new.

Customer / developer interaction can look very different depending on the motivations involved.  When either side is motivated simply to deliver information or dictate fact - as is often the case - then a valuable source of creativity is lost.  Dialogue should encourage customers and developers to learn from the collective experience and opinions available, and jointly discover new solutions to the problems being addressed.

Well-defined dialogue concepts based on the successes and failures in the “real-world” will help development teams implement Dialogue-Driven Development easily and with greater success.

Patterns of Dialogue

If Dialogue-Driven Development is to succeed, it will need to produce reliable and repeatable patterns for implementing d3 in various situations. Patterns could potentially address a wide-array of variables from personality types to customer resistance, and should consistently result in positive dialogue-friendly situations.

Though there are countless situations for dialogue patterns to address, one of the more critical ones I see is the need to provoke dialogue in a project where the customer is either unaware of the dialogue practices or may even be hostile to them. d3 would be unable to function in such an environment unless it is able to accomplish the same results covertly. I believe this is one of the greatest challenges facing d3 in the near term.

Change of Heart

I said at the beginning that my critiques of d3 may have been wrong. I wasn’t being entirely honest, because I’m convinced now that they definitely were wrong. So am I a supporter of Dialogue-Driven Development now? Well, honestly I don’t know where d3 is headed. But I will happily support something to the extent that it’s goals and methods are compatible with mine. And to that end - for the moment - I’m excited about Dialogue-Driven Development.