The user/customer is never right – at
least when it comes to designing good IT systems. This might seem
like a odd statement to come from someone like me that thinks agile
is great. Because agile places a lot of weight on commucation and
customer collaboration, and most agile methods uses user stories or
use cases as their basis for development. And if we base our design
on user stories they must be correct, right?
Well, sorta but not quite. In the
recent massive amounts of articles about Steve Jobs that have
appeared after his death I came upon this qoute: ”You
can't just ask customers what they want and then try to give that to
them. By the time you get it built, they'll want something new.". I know from personal experience that this is often the way
customers act when you present somenthing to them. There is always
changes or imperfections, or their problems and processes have
changes. I am sure many other developers out there know the feeling.
So if we do not trust the user/customer
to supply us with what to do, should we then just do what is awesome?
Well, that often do not work either. I found this qoute in a blogfrom CCP about the problems they face when developing (they use
Scrum): ”..when
we start off with an awesome idea rather than an actual problem we
want to fix or a feature that has a clear, functional and necessary
goal, it generally requires painful fixes further down the road”.
Does that leave us with a catch-22
problem? We can't rely on customers and we can't rely on what we find
awesome.
No – we actually have all the tools
needed in agile thinking. As I see it much of the agile way if
thinking is based on that the user never really know what they want.
We – the developers – need to help them. So lets look at it that
way.
First – as agile developers we are
always ready to respond to change over following a plan. We know we
can not trust the user/customer to know exactly what he wants, so we
make short iterations and continiously deliver stuff to the user, so
he can see if he can use what we have made – if the system solves
his problems.
Secondly we collaborates with the
user/customer. This is usually done by frequent interactions with the
user/customer to build trust between them and us – we need them to
trust that we understand their problems and that we will deliver
something that helps them.
Which leads me back to user stories and
the qoute from the CCP blog. User stories is a great tool if used
correctly. They are however not requirements. They are a tool that
facilitates communication with the user/customer, and grounds our –
the developers - understanding of their problem. It is not the
solution to the problem – the solution is experessed in deployable
code that solves the problem.
When we look at the standard template
for a user story (*) it has often struck me, both as a developer and
business analyst, how often the last part is omitted – the benefit.
But that is crucial for understanding the problem that we want to
solve. It is the benefit that creates value not the action. So I find that the trick to creating a good solution is to focus on the benefit and
how to achieve that and not so much on the action. If we can find a
better/faster/smarter action that achieves the same goal surely we
will deliver value. But if we assume that the user/customer is right,
we often focuses on the action – which is usually also easier, but
also leads us much more in the direction to focus on contract
negotiation instead of customer collaboration – afterall the system
can do all the required actions, right?
In my experience it is the projects
that take user/customer inputs as absolute requirements that fail –
at least in delivering value. The ones that succeed is the ones where
the developer solve the user/customers problem often using novel
technology or solutions that the user/customer did not think of. So
the user is never right – but neither is you – but that does not
matter if you have a little faith and trust in each other and look at
the problem and what creates value.
(*) "As a <role>, I want <goal/desire> so that <benefit>"
