← Back to Portfolio Index

Field Essay · Agile Manifesto · Part 3 of 4

Customer Collaboration over Contract Negotiation

Contracts exist to remove uncertainty, which is exactly why they clash with R&D. When fixed scope helps, when it hurts, and why collaboration wins in the long run.

· Originally published on LinkedIn

Part 3 of a four-part series on the values of the Agile Manifesto, first published on LinkedIn.

What is the most crucial part of any business? Its customers.

It’s a well-known, well-accepted fact. Yet organisations often lose sight of it, drifting from customer-centric to product-centric (Nokia might be a good example). As they do, the agenda moves away from customer collaboration and towards contract negotiation.

  • Customer collaboration means working closely with the customer across the whole product development lifecycle, and staying open to change and feedback.
  • Contract negotiation means working to a fixed scope of work and statement of requirements, with no room for changes to the final product.

B2C vs. B2B

In most business-to-consumer organisations, the “contract” is internal, so there’s plenty of room for collaboration. A B2C organisation will rarely fail to follow this principle unless something is fundamentally wrong.

Business-to-business organisations often end up in harder spots. Collaborating with the customer can mean absorbing extra costs that a fixed contract would have avoided, and customers themselves often feel more comfortable with a fixed contract than with an iterative scope.

For predictive projects, clear contracts make perfect sense. But most agile methods exist for uncertain projects, and the whole point of a contract is to remove uncertainty.

That’s why research and development projects don’t go hand in hand with contracts: in uncertain work, contracts do more damage than good.

An example from future mobility

Take an organisation building a new kind of public transport system. The better approach is a floating set of requirements, reviewed and iterated as the team learns.

Run it predictively instead, with tight contracts for each deliverable, and product development suffers. The team feels restricted when it comes to innovation, and as soon as a deliverable turns out to be unfeasible, the team’s energy goes into negotiating the contract instead of optimising the product.

Does this mean predictive projects shouldn’t collaborate?

No. Customer collaboration is critical for long-term relationships. And every organisation needs innovation to sustain itself, and innovation is never predictive. It always comes with uncertainty.

The takeaway

Without customer collaboration there can be no agility. Prioritise collaboration for the long term, and use contracts to support the product development cycle, not to interfere with it.