Filed under: Agile, Requirements, — Tags: Gojko Adzic, Know the real customer, Requirements, Solve the right problem, Valtech — Thomas Sundberg — 2012-04-02
I attended a session with Gojko Adzic at Valtech in Stockholm in feb 2012. Gojko had some great comments about requirements and especially challenging requirements. A challenging requirement is a requirement from a customer that there is some kind of issue with and therefore something that will bring you problem.
If you don't understand the problem, you will in the best scenario end up solving a problem that doesn't hinder you from solving the real problem. The probability that you will solve the real problem is too close to zero to be interesting.
An example could be that a customer asks for a real-time system. They might have a background from a batch oriented system where batches were executed once a month. If the same batch is executed once an hour, this might be the real-time the customer is asking for. Real time might mean totally different things to developers and customers. In this case, real-time means a few times every day. The real problem in this case was the once a month batch execution and really had nothing to do with real-time systems.
If the customer insist of you using a specific technology, ask them why they hired you. They obviously have an understanding of the technology that you don't have.
A couple of years ago I prepared a tender where the customer had insisted that the solution had to contain an Enterprise Service Bus, ESB. I didn't understand why they wanted it for a small solution that we where offering. It turned out that an ESB wasn't needed and that it would be very unprofessional to include one in the proposal. So instead of including an ESB, I spent some time explaining why it was an extreme overkill to use it. I had a hard time convincing the rest of the team that prepared the tender. After a long debate we ended not including the ESB in our offer.
The first problem a customer gives you is probably not the real problem that should be solved. Ask why this problem should be solved. Keep asking why until you find the money behind the request. There are almost always either protecting, preserving or making money behind a request. Ask why until you understand how this solution will contribute to the money.
This may be annoying to your clients, but at the end of the day you will have understood what really is important and can focus on solving that problem. Instead of solving something else, less important or even the wrong problem. This might be annoying to the customer at the beginning, but it is actually to behave professional.
Knowing who is your real customer, their needs and their background will enable you to build something that solves their problem. Even if you think that their problem is stupid or uninteresting, it is not stupid or uninteresting to them. So understanding your users will enable you to deliver a solution that really works for them.
How do you get to know your real customers? Meet them, visit their working environment and see how they are working today. Invite them to demonstrations of the system you are building. Let them get access early and often so they are familiar with the system the day it goes into production. Listen to their feedback and implement the changes requested so whatever tool you are building actually supports their needs.
If you don't have a clear view of where you are going, then you will get lost among all the details. You cannot see the big picture.
If you start with stories or use cases (or what ever you want to call the chunks of functionality needed), then you will not really see the whole picture due to all details.
Always make sure that you have the entire picture clear while working on the details. Otherwise you will get lost.
If you really understand the problem that actually needs to be solved and who will be using the solution, then you have a great chance to deliver the right product. If you don't know, then you will most probably fail. This will probably force you to leave the initial specification. It was written early, when you and the customer had the least knowledge of what actually should be developed. It is at best not totally incorrect. Inspect and adapt applies here. Inspect what the customer actually need and adapt your solution to it.
Remember
Ron Jeffries had a great quote at Agile 2008 in Toronto
"The most important information in a specification is the phone number to the person who wrote it."
I totally agree. I seldom read specs, I try to have somebody explaining it to me instead. It turns out that it works most of the time and I have been a developer for many years by now.
RSS