Fifteen years ago, at a ski resort in Colorado, a number of technologists came together to discuss the state of software development. Included in this meeting was Kent Beck, Martin Fowler, and Ron Jeffries, both proponents of eXtreme Programming. Also present were Ken Schwaber and Jeff Sutherland, both key early proponents of Scrum. Also present was Robert C. Martin, better known as Uncle Bob Martin, and several other technologists.

The Values and Principles they published after that meeting are still discussed today and seem as important now as they must have then. All of them seem to be universal truths of software development; all of them except one. For the longest time, I’ve struggled with the importance of the third value, “Customer Collaboration over Contract Negotiation”. As it is with all of the Values, this statement means that while there is value in the first item, in Agile, we value the second item more. Thus, this value states that Agile software development values Collaborating with customers over negotiating with them over a contract.

For consulting companies and contractors, this value is VERY important, as it sets the tone for interactions one should have with clients. But, how does this value apply to a company that directly hires and pays the software developers that design, write, and maintain their systems?

I would argue that this value should read “Collaboration over Negotiation” and simply do away with the nouns in the statement. In this new format, it means that while we may need to negotiate from time to time, we value and prefer to collaborate. For Agile Teams, this means that when they are working with stakeholders and end-users, they strive to collaborate with them on requirements, design, scope, and schedule. Instead of the business dictating a set date, we strive to have a conversation, a collaboration, where both sides strive to talk openly and come up with a plan that is realistic and attainable.

Within an Agile team, this means that the User Stories we use as our chunks of work are truly a promise to have a conversation and don’t boil down to a negotiation over what set requirements actually accomplish the story. We don’t always cry ‘scope-creep’ when the Product Owner asks for a small change; we strive to collaborate at how to create the best product we can in the constraints the Agile Team is working with.

Between team members, this means when we interact with our team mates, we strive to collaborate with them instead of taking a more adversarial, negotiation-esque attitude in our dealings with them. If we have a disagreement on the design of a feature or a disagreement during a code review, we strive to collaborate together instead of taking a competitive approach.

The power of the Agile Manifesto partly comes from the fact that it is still relevant to discuss in a fast moving industry 15 years after it was published. They apply to software development broadly, but in their broad scope, sometimes need to be scaled down to understand how they apply in the real world.