Give them what they need

There is a pairing exercise participants experience in my BDD with Cucumber workshop where one person describes a commonplace activity to the other. The challenge is describing it without being able to use certain common words. You need to attend the workshop to see what this looks like, and how much fun it is (I'll post a short video of participants soon).

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?"

Ask your customers, "why do you need this?" "How will it help you?" "What problem does having this feature solve?"

And then ask "why?" a few more times. 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.

I really enjoyed reading Tom Preston-Werner's post Ten Lessons from GitHub’s First Year. Tom says it better than I ever could:

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.

In another post 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.

Producing working software frequently is necessary but insufficient. Producing valuable working software frequently is what matters.