Democratic Development

(This post is another follow-up to Agile is Antifragile.)

I recently finished The Democracy Project by David Graeber. It's an excellent book, in part a personal history of the Occupy Wall Street movement, and in part an explanation of how to organise groups and solve problems using the consensus processes of "direct democracy". To my surprise, I realised that Graeber's insights can also be applied to software development. I think these insights explain not only what Agile development is really trying to do, but also reveal a cornucopia of organisational techniques that we can reuse to improve our practice of Agile development.

In Agile development, the team is supposed to organise itself — "horizonally" as Graeber would say — rather than being directed "vertically" by some manager. But exactly how? Practically every Agile process mandates short daily meetings, but practically no Agile process suggests in detail how those meetings should be run, or exactly how they lead to the team organising itself. What's really going on here? And why is "horizontal" better than "vertical"? As Graeber explains, what should be going on is decision making by consensus:

This is how consensus is supposed to work: the group agrees, first, to some common purpose. This allows the group to look at decision making as a matter of solving common problems. Seen this way, a diversity of perspectives, even a radical diversity of perspectives, while it might cause difficulties, can also be an enormous resource. After all, what sort of team is more likely to come up with a creative solution to a problem: a group of people who all see matters somewhat differently, or a group of people who all see things exactly the same? (Graeber, p203)

The reason for adopting consensus in a group is that "horizontal" decision making produces better decisions. And the key thing to notice is that the point of every meeting is to decide what to do next, in order to further the common purpose of the group. (There can still be some disagreement. In particular, there is no need to agree on "why". Agreement on "what" is sufficient.) Graeber goes on to explain:

The essence of consensus process is just that everyone should be able to weigh in equally on a decision, and no one should be bound by a decision they detest. In practice this might be said to boil down to four principles:

• Everyone who feels they have something relevant to say about a proposal ought to have their perspectives carefully considered.
• Everyone who has strong concerns or objections should have those concerns or objections taken into account and, if possible, addressed in the final form of the proposal.
• Anyone who feels a proposal violates the fundamental principle shared by the group should have the opportunity to veto ("block") that proposal.
• No one should be forced to go along with a decision to which they did not assent.

Over the years, different groups or individuals have developed systems of formal consensus process to ensure these ends. ... In fact there's an endless variety of ways one might go about making decisions in the spirit of those four principles. (p211)

You might question whether these principles of consensus are really what Agile development is about. You might say, yes, these principles are going to lead to better decisions. But the developers are, at the end of the day, paid staff. If someone in authority decides to impose a decision, the staff will have to go along with it even if they do detest it. Maybe so. But I think this actually means that consensus is an excellent touchstone for whether or not you are really doing Agile development. I think that at the point when someone outside the team does impose a decision, at that moment you know that you are no longer doing Agile development.

Graeber goes on to explain a particular widely-used consensus process for moderately sized groups which grew out of several different traditions, including Quakerism and radical feminism. I won't go through it here (it's outlined on p214-215) and as Graeber says, maybe in a small group that kind of formality is not needed, if everyone understands the consensus principles. But it does help, I think, to have concrete processes to consider and use in larger groups. Everything invented in the world of Agile development seems to be foreshadowed in the world of "direct democracy". For example, a "Scrum-of-Scrums" meeting is almost exactly the same as a "spokescouncil". I think we can learn a lot from these people.

(If you want to see what some of these formal processes look like in more detail, you can find a good overview in The Five Fold Path of Productive Meetings by Starhawk.)