I was recently confronted with a familiar situation: a customer telling my team how to design the system during a requirements session. For those of you unfamiliar with application development projects, let me explain the scenario this way; you’re building a new house and you tell your architect that you will need a place to store all of your gardening tools and lawn equipment. You instruct her to design a second-story storage area into your garage. “Wait,” says the architect, “I think I can get you all the storage that you need if we just add a built-in shed on the back of the garage.”
“No,” you insist, “the second-floor storage area is just the ticket.” What should the architect do? What should my development team do? The way I see it, we have a handful of choices:
- Beg for forgiveness (not permission) and do it
the right way our way.
- Debate with the customer until we’re blue in the face about the right way to do it.
- Sell the customer on
the right approach our approach.
- Throw our hands up and walk away form the project.
- Just Do It (the customer way).
Here’s what happens in the first four scenarios above:
- We tick off the customer, probably miss their vision and end up owning (responsible for) the feature/process/system in the end.
- We tick off the customer, waste a ton of time debating over pointless details and end up right back where we started.
- We convince the customer our approach is best, probably miss their vision and end up owning the feature/process/system in the end.
- Tick off the customer, get reprimanded for not making it work and hopefully don’t get fired or sued.
More often than not, the best approach is to swallow our pride and “Just Do It.” I know what you’re thinking. I’m taking the easy way out. “Just Do It” the customer way and then blame them when the project goes down in an inferno of failure. Except, that is not what I’m recommending. No, what I’m suggesting is that there is a strong possibility that neither of you is right and that by insisting that you are (or even quietly believing you are), you are setting the project up for failure.
How can this be, though? Developers know how to write software. We’ve studied database normalization, object relational mapping, decoupling and user experience design. We’re the experts…in software design. But are we experts in the customer’s business? While we may have years of subject matter experience, how well do we understand our customer’s specific business processes? Even if we have spent many years inside the customer’s team, working with them and their current systems, we may not understand their vision for the project. Heck, even the customer may not truly understand their vision for the project.
As an Agile practitioner, I believe that respecting the customer’s requirements is important. It’s important not just because the agile manifesto says so, but because (along with the rest of the principles covered in the manifesto) it’s the most effective way to uncover the real requirements. I’m not suggesting that we should blindly follow the customer’s lead into a situation that my team or I believe to be ill-conceived. I’m saying that we should respectfully explore the customer’s ideas. Doing so in small, well-planned chunks will usually bring more clarity to the goal that the customer is trying to achieve. So maybe I should rephrase my approach as “Just Go With It.” By exploring the customer’s vision/concept/requirement, we allow ourselves to understand more about them, while also showing the customer that we are listening to them. Not only does this improve our understanding of the customer’s vision, but it also develops credibility with the customer, which hopefully makes it more likely for them to respect you and your vision down the road.