Agile values: Customer Collaboration Over Contract Negotiation

I’ve reviewed the first two Agile values from the Agile Manifesto (individuals and interactions over process and tools, and working software over comprehensive documentation), so on to the third value: customer collaboration over contract negotiation.

This value gets at the heart of what it means to be Agile: people are bad at telling us what they want and we’re bad at hearing what they have to say, but people are very good at responding to something they can try out. Working in this model will ensure you’re not wasting time and resources on software that’s ultimately not going to help move the business forward.

Essentially, you shouldn’t expect to get it right on the first try. Any time I’ve handed a project over to clients or users and there’s no or limited feedback, I know I’ve built something uninspiring.  You want feedback! That’s how you know that you’ve built something exciting.

Rather than doing a big upfront requirements discovery period where the clients or users are expected to tell you everything they want, spend some time understanding their underlying needs, build a little something to show them, and expect to continue to iterate.

For a client relationship, this is generally structured as a time and materials engagement. You meet with the client weekly, bill them at an agreed-upon hourly rate, demo work regularly (at least every other week), and agree on the next-highest-priority items.  At any point, if the client is not seeing value in the work delivered, they can cancel the contract.

This is designed to prevent the expense and time of creating a change order every time the client’s needs change, or worse, continuing to work on something that was guaranteed as part of the original contract but everyone knows will not provide any value. Instead, there’s a bi-weekly agreement of what work will be prioritized in the next two-week sprint, the work is demoed, feedback is received and tweaks can be made so the team can move on to the next-highest-priority items. This ensures software that is delivered faster and better meets the client’s needs because more time is spent on understanding those needs and creating shippable software and less time on contract negotiation.

In my experience, this is one of the most misunderstood values because it’s assumed that it only applies if you’re working in a consulting model. In fact, it is even more important when working with internal stakeholders. Instead of a team or pod spun up for a specific project, a team is aligned around a business objective, which its members can deeply understand. They then work with the stakeholders to prioritize their roadmap based on what will deliver the highest business value. 

The team stays in sync with the business needs and can make tweaks to the roadmap to ensure they’re always working on the highest priority problems. Instead of committing to projects, which have a start and end date, the team is committed to business goals and is accountable for serving the business, not just completing projects regardless of the value they bring.

Crucially, instead of a team spun up to complete the project which then hands the work off to a maintenance team afterwards, the team maintains ownership of the work indefinitely. This is important because they’re likely to build the system in a scalable way if they will be on the hook for their decisions, rather than hacking the solution together just to make a timeline.  

The team is also able to learn from their mistakes. When there’s a separate maintenance team, they’re the ones who end up having to resolve the bugs and usability issues. That means the project team is likely to make the same mistakes on their next project. Keeping the ownerships within the originating teams ensures that they’ll have to resolve any usability issues with the product and learn from those mistakes.