Customer collaboration over contract negotiation

The third set of values from the Agile Manifesto are some that a lot of people struggle with, primarily because of pressures from outside the team.

A customer is anyone to whom we provide a service, and that can include internal departments, a business unit within our organisation or an external customer. Ultimately it's the people who need to be satisfied with the end result of what we produce.

If we operate from a fear perspective, or an us-and-them perspective, we want to do what we've been asked to do and no more. We want clarity on what we've been asked to do, so we ask for all the requirements to be gathered and documented. That set of documents then forms the basis of the contract that we agree with the customer. The problem with that approach is that high customer satisfaction is unlikely - because they usually don't know exactly what they want. They have an idea and then try to devise their requirements around that idea. It sort of works, but there's a better way.

If that customer sits with the Scrum team and discusses their ideas a collaboration starts to form. A sharing of ideas that enriches the experience and the product. A short time box of work is agreed in detail and work begins. (The sprint). When the work is done it is demonstrated to the customer (The Review) and they are asked if this is what they wanted. Now that the customer sees his idea in reality, he may or may not like it and he may decide to shape it differently for the next sprint. This evolving process is repeated until the customer agrees that they have a minimum marketable product, something that can now be used by the end user. And throughout the lifecycle of the product, the customer has worked closely with the team and a really useable product has emerged.

Now that's not to say we throw out contracts because we are usually dealing with large sums of money and we have people who we are accountable to, so we need to act professionally. That being said, the risk of a project is narrowed to the timeframe of the sprint. I worked on a project where we released the finance in tranches, periods of time, that were co-ordinated around the sprints. So we agreed to release enough funds for the first 3 months of work, with reviews at the end of each sprint that would allow backing out if needed. We removed all the initial clauses that the procurement teams had put together that referred to the exact nature of what we would deliver. This caused repeated consternation from the procurement teams and they raised it as a high risk of being sued with the legal department. So we invited them to the sprint reviews and they watched as the customer effectively sold the idea to them. He was happy, he was seeing regular progress and was happy with the quality. This eased tensions somewhat.

And who is the customer in the above scenario? We call him the Product Owner in Scrum. The single representative of the customers views.

No Comments Yet.

Leave a comment