Tag: business outcomes

The third statement of what we value from the Agile Manifesto states:

Customer collaboration over contract negotiation

This is an interesting statement for me as I am a consultant and the basis for my engagements with customers starts with a contract, in my case a Statement of Work (SOW). While an SOW is the starting point it is often left fairly vague in some ways to allow for adaptation during the engagement. We do this purposely so that we can work with the customer to uncover the requirements that fit into the broader framework of deliverables.

It is clear to me that the authors of the Agile Manifesto felt that clearly collaborating with your customer was superior to using a contract as some kind of checklist. The project may become highly adversarial in the event that we spend our time fighting over items in the contract instead of making sure we are collaborating with our customers. There is nothing less agile than simply following a contract instead of being focused on delivering the right business outcomes.

I have been as guilty as the next person is thinking that the customer understood the contract in detail, and when we delivered to the letter of the contract we actually had issues. This became my fault by not collaborating with certain stakeholders to the degree I should have. In fact, I know a fair amount of customers who never even read the SOW, so thinking you can use that later to negotiate delivery is somewhat meaningless. On the other hand, I have worked with customers where they analyze every sentence, clearly using the contract as the source of truth for all deliverables. This is both painful for the project team and really not in the customer’s best interest.

So what’s the best thing to do during an engagement if you are to adhere to the agile tenant where collaboration is preferred over contract negotiation? My advice is to do the following:

• The contract is a starting point for understanding high-level deliverables, maybe these deliverables become Epics in your backlog.
• Let collaboration guide your team with the focus on creating business outcomes, instead of blindly producing what the contract outlines.
• Instead of spending your time talking about what is in the contract, it is better to collaborate with the customer to show them that you will over-deliver and have their best interests at heart.

While this seems like such a simple statement that we value collaboration over contract negotiation, it speaks loudly to the real intent. In almost every engagement I’ve been a part of, requirements change as we learn more, and an agile team knows this and will use it to their advantage to produce something better than originally scoped out. Letting a contract dictate the total scope of the engagement and ultimately what is delivered in the end is not agile, but instead waterfall.

I would love to read your feedback on this subject.