By Nathan Donaldson
Customer Collaboration over Contract Negotiation
This is the line that made me think Agile was crazy talk. Forever and as long as I can remember contracts were those magical force fields powered by legalese to help protect the customer from us and us from the customer. Admittedly contracts would never work. At best, an issue or change pops up and you go into renegotiation and a new agreement is established and signed and everyone is happy about the forcefield being back up and then BAM! It breaks again.
“What is more insane? Trying something new after what you’ve done doesn’t work or doing the same thing over and over again and expecting a different result?”
Of course when you go into business with someone you want a contract. You want to define the cost of work, budget, resources, etc. Those things are all relatively static. But when it comes to software, why would you sign off on features or specifics about a product that doesn’t exist yet? How can you be sure what you think you want, is really what you need?
Unless you or your customer comes with a crystal ball or a supped up custom DeLorean, it’s unlikely either of you will know for sure what will end up being the most important features in the product. As the project evolves and work is continuously prioritized, those truths reveal themselves. This is even without considering the likelihood that the requirements will need to change for the customer to keep a competitive advantage.
So if our perception of the product will change as we get to know it better through working with it, who better to ensure the quality of the product than the customer? No one. Having the customer with you every step of the way, available for quick questions and clarifications ensures that there is no misunderstanding when the product is delivered. A living and interactive “contract”… some people call it a relationship.
Like any relationship it requires a commitment of time from the customer. Though this may seem like a big ask; the bigger question is this: How important is this product to them?
In Scrum this means that in addition to being readily available, the customer (or Product Owner – PO) also creates User Stories to define the features they need. They then prioritise these stories in order of business value. This small but important act of organization forces the PO to separate the work they need from the ones they want and thus helps the team to continuously deliver a product of the highest business value.
As the project progresses, User Stories the PO thought they needed “without a doubt” in the beginning of the project can often find themselves at the bottom of the pile, with little likelihood of ever getting picked up. As the PO works with the team and prioritizes the solutions they need, they learn more about what those solutions actually are, versus what they expected them to be. Often the team will provide simpler and more elegant solutions than original thought necessary.
Thus the act of creation is also an act of learning, for everyone involved. Understanding this and embracing it as the norm has created some amazing results here at Boost. Not just in terms of products, but also in terms of people’s outlook on future projects.
Getting a client to become a Product Owner can be difficult. Do any of you have any strategies for bringing them over? Or even just some favorite stories about the changes you see people make as they stop being a passive client and become and active PO?
