©2002 Gerald M. Weinberg, www.geraldmweinberg.com
On a typical day, I get 100-200 email messages, and some of my clients in large projects receive even more. Though emails improve my ability to communicate clearly and quickly, they may also prove a hindrance to certain kinds of communication. In particular, email does not adequately serve as a medium for recording an important agreement. An important email may be too transitory, too easily lost among volumes of less important communications, too easy to misunderstand, and too easily lead to unnecessary conflicts.
Although email can reduce the need for personal contact, it cannot entirely eliminate contact between teams building components that must work together to form a system. Separation of teams tends to create language differences that lead to misunderstood emails. Teams develop local goals that may diverge from project goals and actually conflict with other teams’ goals. With different language and divergent goals, interfaces stop being stable, clear, stakes in the ground. Instead, they can easily become the disputed border between two warring states or two different cultures. To prevent border wars, I prefer the ancient solution – writing and signing treaties.
A software treaty is more or less identical to a treaty between political units. I like my treaties to be written on a single piece of paper with a fancy border, like a gilt-edged stock certificate. A typical treaty might contain.
1. A reference to the technical terms being agreed to – such as a reference to a specific version of a document in the project’s repository.
2. A statement that all signatories agree to the technical terms in (1).
3. A statement that the treaty will remain in effect unless and until renegotiated among all the signatories.
4. Dated signatures of each team’s official representative – most often the team leader. The treaty implicitly recognizes the independence of the signatory teams and their ability to enter freely into agreements on technical matters.
5. (Possible) Management signatures witnessing the treaty.
Although a manager quite likely acts as facilitator to the negotiations, treaties will not work if parties are coerced into signing something they don’t understand, or don’t agree with. Nor will they work if some affected party fails to participate in the negotiations and sign the treaty, so management must ensure that all affected parties are represented.
After signing, however, good management becomes mandatory to enforce the pact the parties agreed upon. In other words, once each party freely gives its signature, the matter is no longer a purely technical one, but becomes political.
Why political? Because after the agreement, one party could disrupt the project and/or make the other party look very bad by covertly changing the agreement. A written treaty seals off this avenue for expressing any animosity or mistrust that exists between the parties. When people understand that management will rigorously enforce each treaty, they can quit bickering and get down to the business of building. Moreover, teams can work with the assurance that anything not in a treaty is not a commitment – and will not become a commitment without going through the treaty process.
With signed treaties covering all interfaces, no single team can disrupt the project by covertly changing the rules in the middle of the game. Woe to any team that fails to meet the interface specifications agreed upon in their treaties.
What happens if one party to the treaty decides they made a mistake, or got a poor deal? For instance, during the negotiations, I might have agreed to pass error-free data in return for two milliseconds more of execution time, but now I find that I cannot scrub the data that fast. I can then call for a renegotiation, but I may have to trade something else for the relief I seek – even something that will simplify my enemy’s job.
Such a concession may prove a bitter pill for me to swallow, especially as the renegotiation is done in front of management, but I have to understood that unilateral changes to my treaties will damage the project and make my life much less pleasant.
The startup of a treaty system will sometimes seem awkward, unfamiliar, and overly formal. I know from history, however, that this degree of formality is needed if former antagonists are to work together cooperatively. White ties are optional, however, and quite soon the awkwardness dissipates.
We frequently see one party resist actually signing a treaty, but such resistance always indicates that the resisting party is uncertain. Because the whole treaty process is designed to eliminate uncertainties, resistance tells me what I want to know that there is still more definitional work to be done.
Treaties are especially helpful for contractor professionals, who may rush into a poorly understood commitment in their eagerness to improve their cash flow. But no matter how much I hope that the definitional job is finished, the strong commitment implied by a signature prevents me from mistaking hope for reality.
By keeping communications on the level of reality, rather than hope, I may create a few problems today, but I avoid bigger problems tomorrow.
By making agreements between cooperating parties a strategy for peace, I avoid the hardest problems of all, the misunderstandings that lead to interpersonal conflicts.
