Over the years I’ve served as a project, acquisition, and contracts specialist in both public service and private industry. Most of those assignments involved the introduction of digital technology, from the earliest days of the introduction of what were called mini-computers, through the introduction of the PC, to the various digital devices, robotics, and artificial intelligence that we use today.
A joke I often encountered over the years was that if you asked a software programmer what his solution could do the response all too often was: “what would you like it to do?” The point of the joke, which has more than a grain of truth in it, is that programmers do not live in (or would prefer not live in) the world of finite resources and often fall into the trap of excessive optimism. That this is backed by empirical evidence has been discussed previously in this blog, where over 90% of software projects in both private industry and public organizations either fail outright or fail to meet expectations. This pattern of failure is pervasive regardless of the method of development used: waterfall, spiral, or–the latest rage–Agile.
Agile is a break from the principles of scientific management upon which previous methodologies were based. As such, it learns no lessons from the past, much as a narcissist rejects the contributions of others. It is not that all of the ideas that were espoused in the original Agile manifesto in 2001–or those since–are necessarily invalid or may not be good ideas in modifying and improving previous practices, it is that they are based on a declaration without attribution to evidence. As such, Agile has all of the markings of a cult: an ideology of management that brooks no deviation and which is resistant to evidence. Faced with contrary evidence the reaction is to double down and push the envelope further.
The latest example of this penchant is by Neil Killick in his post “Beyond #NoEstimates — Why the traditional software contract must die.” It is worth a read but, in the end, the thrust of the post is to state that contracts enforce accountability and the followers of the Agile Cult don’t want that because, well, there is all of that planning, scheduling, budgeting, and reporting that gets in the way of delivering “value.” The flaw in the prescriptions of the Cult, particularly its latest #NoEstimates offshoot, has been adequately and thoughtfully documented by many well-respected practitioners of the art of project management such as that by Dave Gordon and others and I will not revisit them here. Instead, I will focus on Mr. Killick’s article in question.
First, Mr. Killick argues that “value” cannot be derived from the plethora of “traditional” software contracts. His ignorance of contracting is most clear here for he doesn’t define his terms. What is a “traditional” software contract? As a former contract negotiator and contracting officer, I find nothing called a “traditional” software contract in the contracting lexicon. There are firm fixed price contracts, cost plus type contracts, time and materials/labor hour contracts, etc. but no “traditional” contracts. For developmental efforts some variation of the cost-plus contract is usually appropriate, but the contract type and structure must be such that it provides sufficient incentives for “value” that exceeds the basic requirements of the customer, the type of effort, the risk involved, and the resource and time constraints involved in the effort. The scope can be defined by specific line item specifications or a performance specification. Thus, contrary to the impression left in the post, quite a bit of freedom is allowed within a contract and R&D projects under various contract types have been succeeding for quite a long time. In addition, the use of the term “traditional” seems to have a certain dog-whistle quality about it for the Cult with its use going back to the original manifesto. This then, at least to those recognizing the whistle, is a loaded word that leads to an argument that assumes its conclusion: that such contracts lead to poor results, which is not true (assuming a firm definition of “traditional” could be provided) and for which there is sufficient evidence.
Second, another of Mr. Killick’s assumptions is that “traditional” contracts (whatever those are) start from a position of distrust. In his words: “Working agreements that embrace…“Here’s what you must deliver or we’ll sue you”.(sic).” Once again Mr. Killick demonstrates his ignorance. The comments and discussion at the end of his post reinforce a narrative that it’s all the lawyers. I do have a number of friends who are attorneys and my contempt for the frequent excesses of the legal profession is well known to them. But there is a difference between a contract specialist and a lawyer and it is best summed up in a concept and an anecdote.
The concept is the basic description of a contract which, at its most simple definition, is a promise for a promise. Usually this takes the form of a promise to perform in return for a promise to pay, since the promise must be sufficient and involve consideration of value in order to establish a contract. It is not a promise to pay based on a contingent lack of a promise to perform unless, of course, the software developer is willing to allow the contingent nature of the promise to work both ways. That is, we’ll allow you to expend effort to try to satisfy our needs and we’ll pay you if it is of value at a price that we think your product is worth. It is not a contract in that case but, at least, both parties know their risks. The promise for a promise–the rise of the concept of the contract–is in many ways the basis for civilization. Its rise coincided with and reinforced civil society, and established ground rules for the conduct of human affairs that replaced the contingent nature of relationships between individuals. Without such ground rules, trust is not possible.
The anecdote explains the aim of a contract and why it is not a lawyer’s game. This aim was explained to me by one of my closest friends, who is an attorney. He said: “the difference between you, a contract negotiator, and me, an attorney is that when I come out of the room I know I have done my job when all of the parties are unhappy. You know you have done your job when all of the parties come out of the room happy.” Thus, Mr. Killick gets contracting backwards. The basis of this insightful perspective is based on the different roles of an attorney and a contract negotiator. An attorney is trained and educated to vehemently defend the interests of its client. The attorney realizes that he or she engages in a zero-sum game. The clash of attorneys on opposing sides will usually result in an outcome where neither side feels fully satisfied. The aim of the contract negotiator (at least the most successful and effective ones) is to determine the goals and acceptable terms for both parties and to find the common ground so that the relationship will proceed under an atmosphere of trust and cooperation.
The most common contract in which many parties engage is the marriage contract. Such an arrangement can be viewed as an unfortunate obligation that hinders creativeness and acceptance of change, one established by lawyers to enforce the terms of the agreement or else. But many find that it is a basis for trust and stability, where growth and change are fostered rather than hindered. In real life, of course, this is a false dilemma. For most people the arrangement runs the gamut between these perspectives and outside of them to divorce, the ultimate result of a poor or mismatched contract.
For project management in general and software project management in particular, the core arguments in Agile via #NoEstimates are an implicit evil because they undermine the essential relationships between the parties. This is done through specialized jargon that is designed to obfuscate, the contingent nature of the obligation underlying its principles, and the lack of clear reasoning that forms the basis for its rebellion against planning, estimating, and accountability. Rather than fostering an atmosphere of trust, it is an attempt for software developers to tip the balance in the project and contract management relationship in their favor, particularly in cases of external customer relationships. This condition undermines trust and reinforces the most common software project dysfunction, such as the loss of requirements discipline, shifting scope, rubber baselines, and cost overruns. In other words, for software projects, just more of the same.
Note: Grammatical corrections were made from the original.
Life, Project Management, and Everything 
Great post, Nick. I managed to get in my own thoughts in a blog post, below. Note that I don’t think the problem is Agile, or even Scrum coaches, but the apparent need to make Scrum seem valuable by arguing that other approaches are obsolete, destructive, etc. These folks should note that Toyota doesn’t run ads dissing Honda’s design methods; they run ads praising Toyota’s cars.
LikeLike
Thanks Dave. I’ve been following your blog and have learned quite a bit from your posts. I read your post and was thinking of a way of adding to the conversation but decided that your points needed no reply–at least, not without some contemplation. For example, I strongly agree with your insight that, given the history of the various methodologies used over the past 40 years, it still comes down to code quality. Also, I liked the fact that you mention that many of the elements of Agile were in use prior to the Manifesto appropriating them. It is this intellectual dishonesty which undergirds the approach that bothers me. As such, there is an element of ideology or cultishness to Agile. It begins with the proscription to write the Manifesto in any other form than that specified, through the appropriation and subversion of the meaning of common terms (as in “empiricism”), and continues when I encounter Agile devotees and Scrum coaches at professional meetings and conferences who eschew “traditional project management.” Epistemology matters because of the very issue you bring up on code quality: we can construct in our minds what we think is the best system in the world, but if it fails to deal with the cause-and-effect (and is not flexible and adaptive to address the cause-and-effect) of what we are building then it fails on the merits. This is aside from the pejoratives thrown around at anything that differs from the method.
LikeLike