Oct 01 2009
The Mythical Customer Problem
The original XP book includes this magical role of Customer (as in On-Site Customer, Customer Tests). Scrum has a concept of a Product Owner, no less mythical than the XP Customer. Both of these roles represent a deus-ex-machina for programming teams, sort of the-rest-of-the-world entity that takes on all the responsibilities that we can’t. I see nothing wrong with that as a way to divide the responsibilities and clearly separate what the development team is responsible for. However, far too often I see teams that think that a single customer representative gets to play the role of God, someone who can solve all scoping and requirements problems and also has all the domain knowledge required.
Customer is a role, not a person. Very often it can’t be a single person – a domain expert that should ideally be on site is seldom the executive project sponsor who has the authority to approve cost or change plans. One group of people will know how the process works at the moment but another will have a vision what the new system improves. In any non-trivial business specialists focus on particular parts of their domain, so any single person will not know all the details of all the problems. And even if there is such a genius, that person should not bear the burden of getting the requirements right alone. Such a business expert doesn’t have the knowledge about technical possibilities or constraints (or else they wouldn’t need a programming team at all).
Instead of expecting everything to come from a mythical customer, I strongly suggest focusing on collaborative specifications, getting the right people regularly involved to discuss what the development team should implement next and how that fits into the big picture. It’s nice to have a call centre operator on-site to answer questions, but it is much more important to include that person, developers, testers and people who have the authority to make decisions into regular specification workshops to jointly produce the requirements, discuss, ask and answer questions so that everyone agrees on the definition of Done.
 |
 |
I think another common mistake is assuming that the customer knows how best to manage their data. They are sure to know things about the nature of their data, but that doesn’t make them automatically good at managing it for the long term. And there are plenty of hidden customers that have an interest in that data.
Your description fits with my current client very well. We use customer proxies to talk to the real customers and hold workshops for determining functionality and priority. It would be impossible for us otherwise to get a balanced and comprehensive view of requirements.
You’ve touched on a very good point here that decisions should indeed be shared and made with input and collaboration from the whole team and as many real customers as possible.
However, the point of the Customer / Product Owner role is ownership, i.e. who ‘owns’ the decision or, if you like, who takes responsibility for it and has the final say.
We need to collate a list of stories / tasks in priority order as the backlog for our product / project / release / sprint and we know that when more than one human being is involved there will be a difference of opinion somewhere. To prevent roadblocks we need to decide BEFOREHAND who will have the final say. This is why Scrum mandates the Product Owner role.
Whether it’s someone appointed by the company or members of the team take it turns, the point is that we have one person whose role is to make the decision. Of course, anyone can add an item to the backlog and everyone can and should voice their opinion but ultimately, we should all defer to the Product Owner.
If we feel the Product Owner is inadequate in any way or we have lost respect for them, that is a different issue.