“Customer collaboration over contract negotiation”
We all have customers. If we didn’t there would be no reason to do what we do. If we didn’t their would be no one to pay our invoices. And when someone agrees to pay you for work, they generally want to have some kind of agreement on the nature of the work for the money that is being paid. This agreement is usually put in writing and voila, we have a contract. This is an important part of the process and as everyone knows, contracts are valuable documents for both the customer and yourself. But as the Manifesto states, it’s important to not get caught up in negotiation fever.
While it is a good thing to have an agreement before work begins, there are a number of unfortunate aspects to even having such an agreement.
The main problem is complexity.
Software development, by its very nature, is a complex endeavor, dependent on communication and creativity to succeed. While it would be wonderful if all our customers were omniscient, they are often far from it. If we are building a house, we could easily choose things like materials and the architecture of the project and expect that the final building will resemble what was originally agreed upon. Such a thing is rarely true in something as complex as software development, but it hasn’t stopped people from trying (even today).
There is a field of study called complexity theory that applies well to software development in my opinion. In his article, ”On Understanding Software Agility—A Social Complexity Point Of View”, Joseph Pelrine writes:
Many people still regard building software as a complicated undertaking, but in fact it is a defining example of a complex or a ‘wicked’ problem. The concept of wicked problems was originally proposed by Horst Rittel and Marcus Webber. Wicked problems have incomplete, contradictory, and changing requirements; and solutions to them are often difficult to recognize as such, because of complex interdependencies. Rittel and Webber stated that while attempting to solve a wicked problem, the solution of one of its aspects may reveal or create other, even more complex problems. Rittel expounded on the nature of ill—defined design and planning problems, which he termed ‘wicked’ (that is, messy, circular, aggressive) to contrast against the relatively ‘tame’ problems of mathematics, chess, or puzzle solving.
If the nature of software development is indeed ”wicked” then trying to agree on all the requirements at the outset in contractual form is not only wasteful but counterproductive. A much better way is to form an understanding with broad brush strokes and work together to attack the problems, hence the need for collaboration over contract negotiation.
The same is true when the customer is internal. This is why Scrum has someone called the product owner who is available daily to the team to work on the software. Instead of assuming we know everything at the beginning and then have mind—numbing change reviews and contract addenda, is it not better to forge a lasting partnership? Or as Deming calls it, “a long-term relationship of loyalty and trust”.