Agile Software Development

Sometimes there are customers who "generally" agree to using Scrum as a software development process, but fail to fulfill the product owner role. What do you as a team do then?

Product owner responsibilities are the ones that virtually any customer has got. Product owner is responsible for deciding what features are the most profitable for him, for controlling the return on investment, for accepting or rejecting the work results - in essence he is responsible for making money out of the development effort. I've never seen a customer who would not like to to decide on what is the most important for spending his money on.

What often happens in the case of not collaborating customer is one of the following:

• product owner simply does not have time to participate the sprint reviews every two weeks, or maybe he does not believe that his attendance will be worth the time spent

• product owner cannot freeze his wishes for even the sprint period of time and gets new priorities every day
• product owner is used to contracting in the waterfall manner, got used to that it is pointless to review the mid-project documents and does not really know that Scrum will make him a usable product after just a handful of sprints

Solutions

Every team and every customer are unique. There is no universal answer that works for all of the situations and that's why there is a Scrum Master role one of whose major responsibilities is exactly to help customer and the team to understand each other. However, there are some techniques that work for quite many teams. What often works is:

• Get a proxy product owner
  If real customer is available too rarely, there could be a person who knows the customer area best, maybe travels to his site from time to time. This person can act as if he was a customer and make the decisions basing on his knowledge of the real customer interests
   
• Push demos to the customers
  What worked for my own team in the past was pushing the easily downloadable demos to the customer. If they were one-click easy to install and try, than even the laziest busiest customer was curious enough to give it a try and tell the product owner what's wrong with the current version. Naturally, unless the problems discovered were huge, it was the product owner who had to call the customer for feedback, because the real customer was too lazy busy for it.
  I've also head that some teams videocast their sprint reviews to the remote customers
• Reserve some slack for urgent requests
  It is indeed not recommended to include the new content into the committed sprint. However, if you absolutely need to do it, why not to reserve some time for urgent requests in advance?
• Explain the costs
  In many cases the customer doesn't realize what consequences his sudden requests cause. After explaining that the urgent request can spoil the results of a week, customer might decide that his request is not that urgent and might delay his request until the next sprint.

As usual Scrum does not solve the problem. A customer not caring about the project is unlikely to get a good product whatever methodology is applied. Scrum only helps to make the problem explicit and visible. Whether to act on the process revealed is certainly up to the people and not to the process used.

Does your team have or had a problem with the customers not willing to collaborate? What was the reason for it and did you manage to fix the situation?