Negotiations and Web Sites

After teaching a course last Friday I began to realise how important negotiation skills are to software development, and how powerful the combination of Agile methods and negotiation skills can be.

One of the stories I often tell on our Introduction to Agile course is about the first two projects that I worked on when I started out as a software engineer. Both projects were huge. Both projects were making good money from the company in their maintenance phase, they generated a steady stream of changes and updates which my company charged top rates to provide. Both projects had reached the end of their initial development phase on the verge of disaster. Both projects had got to the point where the customer was threatening legal action. In one case the customer was the British navy. If they had sued it would have probably been the end of the company.

In both cases, just when it looked like the projects were about to end in disaster, something very interesting happened. The projects brought in a negotiator. I think I saw him once on another project that I was working on that was about to reach its "Critical phase". He was short, (even shorter than me) and stocky with a totally bald head. They called him the Bulldog. All he ever did was go from project to project which had reached crisis point and negotiate with the customer. He would turn up to meetings with the customer and let the customer vent their frustration about not having any software, or about having software that could only run for five minutes without falling over or whatever it was. He would then try to get out of them what was the most important thing that the software had to do and also get out of them a little bit of money and a little bit of time in which to do that thing. He would also persuade them that moving the project little by little towards totally working was infinitely preferable to calling in the lawyers. If the lawyers were called in, all work would have to stop. After the dust had settled - in a few years maybe. The customer might get some of their money back, but they still wouldn't have any working software. Whatever the problem the software had been commissioned to solve would still be unsolved.

The theory of negotiation basically says that everyone who's party to a negotiation has something called a BATNA. I know, it's not a very pleasant acronym. It stands for "Base-line Alternative to a Negotiated Agreement". I think Agile methods, and especially the practice of delivering working software all the way through a project are very interesting. In their book Getting to Yes by Roger Fisher and William Ury, the authors recommend that negotiations move from positions to values. This is what happens when a project moves from talking about a specification document to working software.