Introduction
December 2023 was a big one for me. I completed a project at work I have been working on for the last 3 years. What I did and what the project was about is doubly-irrelevant for this blog. For the first, in my line of business one is not supposed to talk shop in the public. For the second, I ultimately do not care.
I argue that the biggest blunder of my generation is to insist that work should have some deep fulfilling meaning. I think this is asking too much. For the purposes of one’s mental health, it is sufficient that it make some sense most of the time. Just think about the pyramids in Egypt. They look miraculous not only as physical objects but also as reminders of the work of countless hordes of people. Yet, at least I struggle to find any meaning in them.
Imagine the construction site of a pyramid. There were a handful of assholes who whipped the slaves and thereby denied themselves the pride of having actually created something really beautiful with their own hands, for there are more beautiful things in this world than scars. Then there were the slaves who did not fight back despite being in the majority, so denying themselves the logic of arithmetic. And finally there was the dead pharaoh whom they all worshipped and who was at the same time absent and omnipresent.
Some progress has surely been made in the last 5000 years as at least some of the passage seems alien to us. The basic power structure has nonetheless remained the same. There is the absent but omnipresent boss. There is the middle management. And then there are the doers. To make matters worse, if I left it at that, I would already manifest some ideology because ideologies are defined by their boundaries — they are born whenever certain people are left out and they are born whenever people feel they are left out. Of course there were the countless people I omitted. There were the multitude of bakers, whores, cooks, brewers and so forth working amidst the biblical swarms of flies.
I am afraid that as long as there are pesky insects there will be ideologies which ultimately serve the same purpose of sucking drops of our life energy from us. But there is still some hope. If we leave meaning by the wayside, it still makes a difference how we work. That I do care about in a deep way. It is also something that I have been thinking and studying for the past years. You could even say that my last project was an experiment whose final report this blog post is. It is only now that I am able to connect the dots.
Luckily for me, it only took one good book to sum up all the wisdom I have gathered over the years. What do you know, work and equitability are topics that have vexed the minds of many thinkers in the past! My role here is to merely raise my hand up and tell you that I got the lesson. If I’m lucky, I’ll get you to read the book I’m talking about: Roger Fisher, William L. Ury, Bruce Patton: Getting to Yes: Negotiating Agreement Without Giving In.
You see, it was only quite recently that I realized that I have been trying to be a principled negotiator all along. I finally see that there are more fundamental aspects to organizing work than what usually falls under the umbrella of Agile that I once studied so hard.
In particular, it has become apparent to me that the benefits promised by agile methodologies are subject to how well the work is lead which in turn is in large part about how you negotiate. In other words, the work can be as agile as your HR department declares, no doubt based on some arbitrary set of metrics, but without proper leadership, the work will be mostly about fixing defects and ways to masquerade confusion with agile jargon.
“Thanks Cpt. Obvious”, you might say, “any more of these truths that you would like to vent out?” Well, let me try to be constructive and put some flesh on the bones of my argument by summarizing what Fisher, Ury and Patton discuss in their book. I want to talk about how to get the most of agile by following the four key principles the authors present.
As an aside, Getting to Yes is a real page-turner. It contains a lot of real-life examples of conflicts, from car insurance disputes to full-fledged wars. No wonder the book is is a perennial best-seller and a classic among the business-savvy. Reading the book, I felt like eavesdropping on the training material for lawyers and business executives. Indeed, the authors Roger Fisher and William Ury are the founders of the Harvard Programme on Negotiation.
The authors have also published a whole host of sequels to the original book. There is Getting to Yes with Yourself for the self-help market and Getting Past No for those who did not get to yes. Then there is Getting It DONE: How to Lead When You’re Not in Charge whose title would be perfect for this blog, with a tongue in cheek reference to Jira and everything. Being aware of the copyrights of the authors, I suppose they would be nonetheless cool if I stick to their formula and call this blog the next best thing: “Getting to Deploy: Negotiating A Sprint Without Giving In”.
Separate the people from the problem
The theory of negotiation as presented in Getting to Yes is rather straightforward. Negotiation is a process that aims at an agreement. While good negotiators approach their work from a humans-first point of view, good interpersonal skills alone will not lead to wise agreements. The agreement should be formulated as a solution to a problem that can be described in a rational way. This does not imply a dichotomy between reason and emotions. It merely means that good negotiators are emotionally intelligent. If for example some aspect of the agreement involves “saving face”, a good negotiator knows how to factor this in their arguments without getting caught up in their own pride.
In a software development context, the situation is also rather straightforward. It is often easy to point at the problem: the software does not exist, it lacks a feature or is found to be defective. The situation gets a lot more interesting when dealing with distributed systems. When a new feature requires a modification in another piece of software, developers need to meet and negotiate.
The authors of Getting to Yes go to great lengths at describing the crippling effects of positional bargaining. This means a situation where the negotiating parties go down the path of offers and counteroffers where the stronger party will most likely have the final say. I recognize the situation. In software development, it takes the form of “backlog-driven development”. Rather than trying to solve the problem in a rational way, the solution is based on how little work ends up in my team’s backlog.
The first step in being principled about these negotiations is to separate people problems from the problem itself. As far as the problem itself goes, it is necessary to do due diligence and read the documentation on the architecture and system design. These are the documents that should show what the principles are. No architecture documentation? Well, a principled negotiator should forget about the original problem and start to work on getting the documentation. I have once received it in the form of an ad hoc puppet show where the marker pens in the meeting room played the role of actors and miscellaneous office trinkets played the role of APIs.
It is also necessary to be mindful of what the goal of software architecture is in the first place. It is to create cohesive components that depend on abstractions. As software architects are typically more on the introverted side and possess strong system thinking capabilities, it is no wonder that the ideal situation is to minimize dependencies in the first place — then the need to negotiate is minimized as well. It therefore pays to understand that starting a negotiation has already a hidden psychological cost associated to it. In general, software architects are not like the jolly hagglers you encounter in the bazaars of the Orient. The starting point of a negotiation is often that we have a leaky abstraction on our hands.
If we then focus on the people problems, I suppose they are not that different from any other discipline. Too much work, too little time. Programmers are also human.
The one aspect of time pressure I want to highlight has to do with what agile aficionados have been championing all along. Namely, it is necessary to leave some slack in the day-to-day work so that developers have the mental capacity to approach problems creatively. I remember reading about “80% capacity” being optimal, but cannot give you better sources except “Pareto’s principle” accompanied by my jazz hands.
The people problem can also be about bad timing. These feature request meetings have the tendency to emerge randomly, and sometimes it just happens that something is amuck in production at the same day, which creates an emotionally unproductive setting for collaboration. Again, factoring in the necessary time to let things cool down is what gives better results. For example, I have found it useful to start from asking when people are on holidays. It is a far better ice breaker question than “when do you have free time to do this annoying thing I would need from you.”
Finally, I should also add that a negotiation that ends with wishful thinking about fixing the problem properly sometime in the future does not constitute a real agreement. It is as realistic as expecting shards of glass to spontaneously jump together to make a vase. To be principled in these matters is to deal with real timetables and real commitments.
Focus on interests, not positions
I once watched a very interesting analysis of The Cats, the musical and the movie. The analysis starts by claiming that songs in musicals can be roughly divided into two classes. There are the “I am” songs and the “I want” songs. The villains typically sing the “I am” songs which help to establish their nefarious nature and hide their true interests. The heroes on the other hand sing songs about what they aspire to be or what they wish to accomplish. The end result is then that The Cats is the ultimate musical as it consists of many hours of boring “I am” songs by the different cats as they introduce themselves, followed by one hell of a “I want” song — Memory.
This observation has a parallel in the world of negotiation. If the story is about who is who, it ends quite quickly and lacks all of the momentum a good story has. If on the hand, we give a voice to the characters and let them describe what they want, the story starts to unfold almost on its own. The same applies to negotiating.
Indeed, if you want to play the villain in a negotiation, the recipe is to just describe your position and then shut up. To be a principled negotiator means to arrange the negotiation so that participants are encouraged to describe their interests. They need to be given the chance to be the heroes of the story.
The result is then obviously a conflict as not all interests can be satisfied. It is a fact of human existence that we value different things and end up bickering about the small stuff. However, somehow we nonetheless thrive because of these conflicting interests. The authors of Getting to Yes point out in a very illuminating fashion that a conflict of interest is often the prerequisite for reaching an agreement in the first place. Just think about it. A cabbage peddler in the proverbial bazaar has to value money more than their produce in order to sell it.
In my experience, software development is in no way different from the general case. It is helpful to consciously try to encourage people to state their interests. Sometimes the negotiation gets stuck as people formulate their interests based on other people’s interests. They perhaps lack the courage to be so selfish as they privately would like to be. Another bone of contention is that some people would like to be told what to do while others prefer autonomy.
However, after the interests are known, I have more often than once witnessed a miraculous event. The solution to the problem at hand just pops out of nowhere. For example, if a developer identifies the location of the problem in the source code during the negotiation, it can sometimes happen that the fix is just a minor tweak that is deployed to the test environment by the end of the meeting.
Invent options for mutual gain
The third aspect of being a disciplined negotiator is to understand that our collective capacity to solve problems is damn near infinite. If we were forced to rebuild the pyramids, we could easily do it at a fraction of the cost spent in the war in Ukraine. Yet, the obvious question would be whom would this benefit. Cui bono?
The authors of Getting to Yes map out a strategy to seek the coveted “win-win” that is the mark of a good agreement. The idea is to separate the problem solving capacity of all the stakeholders from the stressful grind of the negotiation proper.
As anybody who likes negotiation is sure to admit, the process has a component of an ego trip to it. My intuition tells me that introverted people underperform in these situations despite often having superior substantive understanding of the problem at hand. By the same token, people’s stress coping skills are not the same as their problem solving skills. It is therefore beneficial to create an environment where every stakeholder can contribute irrespective of how power hungry they are.
The practical solution is then to have separate workshops leading up to the negotiation. The workshops are solely about throwing out ideas. It is then an indicator of psychological safety how creative and wild the ideas are. These workshops help to reduce the solution to a finite set of candidates, each with agreed upon pros and cons. This is an effective strategy because it involves reaching pre-agreements about the different alternatives so that the final agreement is reduced to picking a solution out of a menu based on the best possible knowledge that was available.
The strategy also reminds me of my previous post about how to program well. Once again we see that we humans are good at tackling a problem if it is of the “divide and conquer” type.
However, I recognize that this chapter is a bit idealistic in the context of software development. The tricky part is that in real software projects there is often no sense of strong psychological safety: developers can easily feel that they are not being heard. It is very much like in the poem “It still moves” by Eino Leino: “When the gentle is put amidst the rough, it is often the rough who prevail.”
I have participated in all kinds of workshops that had the grand goal of figuring out the best alternatives so that powers that be could decide the proper course of action. In truth, I always felt I was wasting my time. From a software developer’s point of view, the solutions can be expressed rather simply in software terms. It is an unsolved problem how to communicate this to business owners who think in terms of budgets and resources. It seems that in reality there are only two options for mutual gain. Either we developers acquire MBA degrees from some Caribbean online university or business owners take on “Java for dummies”.
Insist on using objective criteria
Finally, the last aspect of being a principled negotiator is in my opinion the most important one with regard to agile ways of working. It has also a lot to do with buzzwords like lean manufacturing, CI/CD and DevOps.
The wet dream of anybody working in the enterprise is surely to have an entire day free of any distractions. This is simple in theory but difficult in practice. All one would need to do is to decline to attend the meetings that creep in our calendars. The authors of Getting to Yes discuss in length how to deal with this issue. The authors instruct to be always aware of one’s BATNA, the Best Alternative to Negotiated Agreement.
If your BATNA is better than what can be achieved by participated in the meeting, there is no need to negotiate. If you can limit your work in progress to one thing, your primary interest should be to get that piece of work done. If the meeting does not advance that goal, there is no need to attend it. Mind you, if you attend meetings muted, you are a villain. I recognize the harshness of my tone, but I am frankly fed up with people who fail to apply any of the thinking behind agile in practice. Their calendars look like a mess. There should be a separate negotiation guide for the extremely agreeable: Saying No: A little bit of self-interest goes a long way.
I have been in several heated and unresolved debates about this matter. I am willing to admit that not all people in the enterprise have the luxury to focus on one thing at the time. The pressure to multitask is many orders of magnitude stronger when moving from a software team level to a whole business unit. However, my argument, as corroborated by Getting to Yes, remains. It pays to consider if negotiation is even required. Instead of even trying to agree, the BATNA should be that there is an pre-existing agreement, a procedure, on how to get a particular thing done. Sounds a lot like good governance to me.
Suppose you limit your time to the negotiations that actually matter. The authors of Getting to Yes further stress to insist on objective criteria as a basis of reaching an agreement. This has the effect of further freeing up time from your calendar. Just take a look at it. How many of the meetings last week were essentially about the back and forth among people who do not understand what was agreed upon?
Principled negotiators recognize that a hidden motivation in reaching an agreement is to not return on the matter in the foreseeable future. The better the agreement, the less likely it needs to be renegotiated. Like stated previously, negotiating is mentally taxing and may require substantial coordination with all the stakeholders.
In traditional agreements, the criteria takes the form of Terms & Conditions. While reading the book, I made the discovery that in the agile world, the criteria should be expressed as the Definition of Done (DoD) for a particular user story. It then requires only a little bit of reasoning to arrive at the conclusion: a good DoD is an acceptance test that allows the team to state with confidence that the software works as intended.
This is a far better approach to work than spending time estimating it, as highlighted by Jeff Sutherland himself (see the attached twitter post), and has sort of revolutionized how I approach my work.
I have found that building the confidence to deploy working software to production is the proper job of a Lead Developer. It is what ties everything together. While it would be beneficial that we had more generalists, we nonetheless live in a world of specialists. There are the analysts who analyze, designers who design and developers who develop. It then takes somebody who specializes in giving the work a direction. It takes somebody who sees the work as a manufacturing pipeline whose end stage is deployment to production. Otherwise, we end up just fooling ourselves. The agreements we reach have little value if they do not end up benefiting a paying customer.
Conclusion
To draw this lengthy blog to a conclusion, I would summarize what I have learned in the past 3 years as follows:
An agile sprint is an agreement to complete a piece of work. The content of that piece of work is subject to negotiation among the team members. For there to be a real negotiation, there should be a healthy conflict of interests. And for there to be a productive negotiation, the conflict should not spill over so that people take it personally. For this to even work in theory, true agility requires a lot more back-scratching and amicable louse picking than is physically possible after offshoring entire business segments beyond oceans. So better be principled and insist on working with people you know and trust.
It is evident that not all team members will be negotiating with equal fervor. They should nonetheless be aware of their BATNA: the decision to not participate should be a conscious one. Insisting on the piece of work to be done in the sense of agile ideals of delivering a feature to end-users is also obviously only an ideal. Yet, I would start to measure agility by inspecting how close to this ideal the Definition of Done of a particular piece of work is. The closer it is to actual production deployment, the more principled the team is.
Finally, one of the deeper aspects of agile retrospectives is to raise awareness of the habits the team has. Habits are extremely costly to change, but confronting them honestly is at least a start. Ideally, good negotiation habits should be present from the get-go. Principled negotiation strikes me as a good platform to build upon. The theory has been literally battle-tested and should work universally. It therefore captures something essential about the human psyche.