Don't Give Your Customers What They Ask For
Give them what they need. There is a pairing exercise participants experience in my BDD with Cucumber workshops, where one person describes a commonplace activity to the other. The challenge is describing it without being able to use certain common words. One thing I have noticed, no matter where I have run this exercise, is that very few people actually explain why this activity should even be done. They typically spend all the time describing the mechanics of how to do it, but don’t explain why, and the listener usually doesn’t think to ask. I contend that as technologists we do the same thing to our customers all the time.
The critical piece here is asking "why?"
In the class exercise, if the person explaining the activity had started with why, the rest of the description would have been so much clearer and fallen into place quicker.
For us, we need to ask our customers, "why do you need this?" "How will it help you?" "What problem does having this capability or feature solve?"
And then ask "why?" a few more times. Not in an annoying way like a small child does, but as a genuine drive to deeper learning and empathy.
Failure to do this will lead to a mechanical understanding of the need rather than the type of creative collaboration that might lead to deep insights about the true problem being addressed. I think it is this lack of deeper questioning that explains how many user stories lack a clear statement of the benefit returned by implementing the feature described by the story.
In Ten Lessons from GitHub’s First Year, Tom Preston-Werner writes:
Adapt to Your Customers
Here’s a seemingly paradoxical piece of advice for you: Listen to your customers, but don’t let them tell you what to do. Let me explain. Consider a feature request such as “GitHub should let me FTP up a documentation site for my project.” What this customer is really trying to say is “I want a simple way to publish content related to my project,” but they’re used to what’s already out there, and so they pose the request in terms that are familiar to them. We could have implemented some horrible FTP based solution as requested, but we looked deeper into the underlying question and now we allow you to publish content by simply pushing a Git repository to your account. This meets requirements of both functionality and elegance.
Ten Lessons from GitHub's First Year
In Readme Driven Development Tom points out how "building the right system" always trumps "building the system right":
I hear a lot of talk these days about TDD and BDD and Extreme Programming and SCRUM and stand up meetings and all kinds of methodologies and techniques for developing better software, but it’s all irrelevant unless the software we’re building meets the needs of those that are using it. Let me put that another way. A perfect implementation of the wrong specification is worthless.
Readme Driven Development
Producing working software frequently is necessary but insufficient. Producing valuable working software frequently is what matters.
Note: I posted an early version of this articule on my company blog on 21 July 2011, but am reposting it here.
Flying Machine Patent from US National Archives. Patent Drawing for a Flying Machine, 10/05/1869. Creator(s): Department of Commerce. Patent Office. (1925 - 1975).
About the Author
Paul is a software design and development coach and mentor. He is available for consulting and training through his company, Virtual Genius LLC. He is the author of The EventStorming Handbook and major contributor to Behavior-Driven Development with Cucumber. He is also the founder and chair for the Explore DDD conference.