This post originated from an RSS feed registered with Agile Buzz
by Robby Russell.
Original Post: Dialogue-Driven Development is about rounded corners
Feed Title: Robby Russell gets agile
Feed URL: http://www.robbyonrails.com/xml/rss20/tag/agile/feed.xml
Feed Description: Robby on Rails gets agile with Dialogue-Driven Development
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 DDD, 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.
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.
Previous Topic
