I’ve recently been reading Bruno Latour‘s Politics of Nature, and have been struck by how well various agile practices fit into his framework. So I want to try to explain his framework (again!), and to explore how agile practices might fit in.
His book begins as a reaction against the split between nature and society, the split between facts and values. He sees in this split a misplaced polemicism: if, for example, these two worlds are separated by a vast gulf, then how is it that scientists, as members of society, manage (quite successfully!) to understand the workings of nature? In place of this split (the “old bicameralism”), Latour proposes a new split (the “new bicameralism”), between the “power to take into account” and the “power to arrange in rank order”.
This isn’t to say that Latour finds the old bicameralism to be completely useless: in particular, he uses both bicameralisms at once to create four quadrants, leading to four requirements, which are, in (temporal) order, “perplexity”, “consultation”, “hierarchy”, and “institution”. The first and last are related to the concept of nature from the old bicameralism, while the middle two are related to society; in the new bicameralism, the first two form the power to take into account, while the last two form the power to arrange in rank order.
To these four requirements, Latour adds two further functions: the separation of powers actively maintains the new bicameralism, the scenarization of the totality works to unify the resulting collective. Finally, the seventh function is the power to follow up, which reminds us that this is an ongoing process rather than a one-time activity that will analyze the world once and for all.
To make these seven functions more concrete, Latour discusses each of them in the context of various professions (scientists, politicians, economists, moralists, administrators); some professions are more associated with one side or the other of the old bicameralism, while some straddle the boundary. I’ll devote one section to each of the functions, giving a brief explanation of that function, a summary of how each of those professions contributes to that function, and ending with a discussion of how that function might be viewed in an agile context.
The Requirement of Perplexity
The first requirement is the requirement of perplexity, also known as the requirement of external reality. It says that “you shall not simplify the number of propositions to be taken into account in the discussion” (p. 109); or “First, the number of candidate entities must not be arbitrarily reduced in the interests of facility or convenience. In other words, nothing must stifle too quickly the perplexity into which the agents find themselves plunged, owing to the emergence of new beings.” (p. 110) In the old bicameralism, it was part of the notion of nature, while in the new bicameralism, it is part of the power to take into account.
Scientists bring to this requirement their remarkable ability to create speech prostheses: they’re wonderfully capable of creating instruments that allow us to be perplexed by the behavior of entities (or candidate propositions, if you like) whose existence we didn’t even suspect a few years prior. Politicians bring their sense of danger to this requirement: if they ignore the wrong people, the wrong facts, they may find themselves out of a job and disgraced before they know it. Economists are particularly sensitive to attachments between humans and nonhumans, increasing the ties between the two as a result. Moralists continually go outside the collective, actively attempting to ensure that those previously excluded have their say. And administrators can keep track of external reality over long periods of time, enabling us to be perplexed by phenomena that we might otherwise miss.
In an agile context, the first thing that the requirement of perplexity brings to mind is tests. An unexpected red bar is a wonderful example of perplexity, a reminder that our intentions of what the software should do aren’t always matched by reality. Like scientists, agilists go out of their way to build pervasive networks of speech prostheses in the form of comprehensive automated test suites. Though there is more to testing than automated tests: perhaps recent discussions of exploratory testing in the community are a reminder of the role of moralists, that we should actively look for the excluded.
Like politicians, agilists also have to have a sense of danger: if what we implement isn’t what potential users want, then we’ll be out of a job. The Customer role is our main defense here: like tests, Customers are a speech prosthesis, this time speaking for humans rather than nonhumans.
The Requirement of Consultation
The second requirement is the requirement of consultation, also known as the requirement of relevance. It says that “You shall make sure that the number of voices that participate in the articulation of propositions is not arbitrarily short-circuited.” (p. 109) Alternatively, “the number of those which participate in this process of perplexing must not itself be limited too quickly or too arbitrarily. The discussion would of course be accelerated, but its outcome would become too easy. It would lack broader consultation, the only form capable of verifying the importance and the qualification of the new entities. On the contrary, it is necessary to make sure that reliable witnesses, assured opinions, credible spokespersons have been summoned up, thanks to a long effort of investigation and provocation (in the etymological sense of “production of voices”).” (p. 110) In the old bicameralism, it was part of the notion of society, while in the new bicameralism, is is part of the power to take into account.
Scientists consult their colleagues through a process of peer review, and ease this consultation through descriptions of their experiments that are precise enough to be replicable. Politicians can really shine here, discussing matters with a whole range of people and groups who might be affected my the matter at hand. Economists can use their practice of attaching a value to interactions to smoke out stakeholders that might be ignored otherwise. Moralists can make sure that the people who are affected by a problem get to chime in, instead of leaving decisions solely up to the traditional powers that be. And administrators help ensure appropriate consultation by verifying the credentials of those wishing to participate.
And agilists? Certainly having a Customer make the business decisions is a big step up from, say, having engineers make those decisions. Of course, you don’t want the business side to go so far as to make decisions without appropriately consulting the engineering side; to that end, having the engineering team in charge of primarily technical decisions is probably consistent with this requirement. In general, I think collective code ownership is aligned with this requirement as well: given that database changes affect everybody working with the data, for example, you don’t want to give a DBA magical powers over them. And retrospectives give a forum where the whole team can be consulted on areas that matter to all of them.
Having said that, I’m not entirely comfortable that the agile role of a Customer does adequate justice to the requirement of perplexity. There are a lot of people outside the engineering team who will be affected by non-engineering design decisions; putting all of them behind a single Customer point of decision doesn’t fit the requirement of relevance, to me. I’m not saying that having a single Customer decision maker is bad—this requirement doesn’t mean that everybody has to have a direct say in every decision, just that they have to be consulted—but there’s a whole lot of consulting that has to go on behind the Customer’s decisions to fit this requirement. And agile is neutral on that: a non-consulting Customer is just as consistent with agile practices than a broadly-consulting one.
The Requirement of Hierarchy
The third requirement is the requirement of hierarchy, also known as the requirement of publicity. It says that “you shall discuss the compatibility of new propositions with those which are already instituted, in such a way as to maintain them all in the same common world that will give them their legitimate place” (p. 109), or that “no new entity can be accepted in the common world without concern for its compatibility with those which already have their place there. It is forbidden, for example, to banish all the secondary qualities by an ultimatum, on the pretext that one already possesses the primary qualities that have become, without due process, the only ingredients of the common world. An explicit work of hierarchization through compromise and accommodation makes it possible to take in, as it were, the novelty of the beings that the work of taking into account would risk multiplying.” (p. 110) In the old bicameralism, it was part of the notion of society, while in the new bicameralism, is is part of the power to arrange in rank order.
The example that Latour gives of this requirement for scientists is their ability to come up with potential compromises through innovations: pig organs might give a way around some of the moral concerns pitting human transplant recipients against their potential donors. If I’m understanding the requirement correctly, scientists also have examples within their own discipline: if you’re trying to overthrow an existing theory, you have to treat the phenomena that it can explain with appropriate respect. Politicians satisfy this requirement in a more straightforward method: they must always compromise in order to get bills passed, to have the government continue to run. Economists can make a whole range of phenomena commensurable, by discussing them in financial terms. The very process of moralizing involves establishing a hierarchy, making judgments of how entities fit into a common framework. And administrators have recorded the previous hierarchization decisions, giving us the framework to enable us to discuss the new hierarchization.
The first agile example that comes to mind here is the existence of your test suite, thought of as regression tests: that’s a very stark example of new entities having to show concern for existing entities. They don’t mean that the world is rigid, that existing features can never change; but if you want to make a change, you’ll have a red bar which you’ll have to explicitly decide how to turn green again. I suspect that the notion that the Customer decides business issues while developers decide engineering issues is consistent with this requirement; certainly the idea that you have a single linearly-ordered stack of incoming stories to implement is. Perhaps Kent Beck’s rules of simple design could also be seen through this prism?
The Requirement of Institution
The fourth requirement is the requirement of institution, also known as the requirement of closure. It says that “Once the propositions have been instituted, you shall no longer question their legitimate presence at the heart of collective life” (p. 109), or that “once the discussion is closed and a hierarchy established, the discussion must not be reopened, and one must be able to use the obvious presence of these states of the world as indisputable premises for all the reasoning to come. Without this requirement of institution, the discussion would never come to an end, and one would never succeed in knowing in what common, self-evident, certain world collective life ought to take place.” (p. 111) In the old bicameralism, it was part of the notion of “fact”; in the new bicameralism, it’s part of the power to arrange in rank order.
Scientists are very good at instituting propositions, at reaching a consensus on a theory and then building upon it. Politicians institute the results of their work in the form of laws; they are willing to bring closure by making enemies instead of trying to keep everybody their friend. Economists document the results of their deliberations in the form of measurements and calculations which can be used to make further decisions. Moralists, perhaps, help us understand the boundaries of institution through their concern for those who are left on the outside. And administrators ensure that the procedures are followed so that the institution happens according to due process.
Agilists have a few tools in this regard. The Scrum notion that you can’t add anything to a sprint once it’s begun is a form of closure, as is the existence of a Customer who has final say on business matters. The existence of an acceptance test suite that isn’t allowed to go red is a manifestation of institution. And agile teams generally have a specific process that they follow (perhaps one of the standard processes combined with local adaptations); that process, together with the idea that you can only alter it through an explicit process (retrospectives, typically) also brings closure to discussions of what to do, instituting the results.
Separation of Powers
The first four functions led us through the process of constructing the collective, leading through the quadrants that were formed by analyzing candidate propositions both through the old bicameralism (facts versus values) and the new bicameralism (the power to take into account and the power to arrange in rank order). The fifth function focuses explicitly on this new bicameralism: it is the separation of powers, “the maintenance of the separation or shuttle between the power to take into account and the power to put in order.” (p. 137)
Scientists bring to this function their tradition of autonomy: you can’t ignore something because it’s not part of the current version of the collective. The very notion of separation of powers comes from the political tradition. Economists are a bit harder to analyze in these terms; Latour’s claim is that their extreme simplifications of attachments between entities helps preserve this separation of powers, but I don’t completely understand his argument. Moralists emphasize the relation between the two houses by concentrating on the shuttle between them rather than the separation: decisions made in the ordering will have effects that we’ll have to take into account. And administrators will be unable to effectively coordinate activities and ensure that proper procedures are followed unless they keep track of which actions are within the one house, which within the other.
Agilists have several rhythms that, I think, fit well into this separation. Perhaps the red bar could be thought of as within the power to take into account, refactoring could be thought of as arranging in rank ordering, and the green bar is the shuttle from the first house to the second? Frequent releases are part of the shuttle from the second house back to the first. I mentioned the Scrum notion that you can’t add anything to an iteration once it’s begun back with the forth requirement (that of closure), but perhaps it fits better here, as part of the separation of powers? At first I thought that the customer / engineering split was part of this separation of powers, but now I’m dubious about that: it’s a separation of powers, certainly, but I don’t think it’s this one, because I don’t think either the Customer or the developers fit in one or the other of the houses.
Scenarization of the Totality
The sixth function is that of scenarization of the totality: “instead of starting from an already-constituted unity (nature or society), the various skills (of the sciences, politics, government, and so on) propose scenarios of unification that are all provisional and that the reconsideration of the collective will quickly make obsolete”. (pp. 248–249)
Scientists package all their individual findings into grand theories, grand narratives, happily rewriting past discoveries into a new narrative structure based on their latest understanding. Politicians are at their most effective when using a narrative that resonates with as many people as possible. Economists provide a scenario for the collective through their model of interactions, through what that model takes into account and what it excludes. Moralists I have a harder time with; my first inclination is that their grand moral statements provide scenarios, but Latour suggests that I’m misreading the intent of this function, giving them instead a role similar to their role in the requirement of closure, as a sort of loyal opposition to the very idea. And unless I’m missing something, Latour doesn’t even propose a role for administrators in this sixth function.
For agilists, that most obscure XP practice of Metaphor is doubtless relevant here. I suspect that refactoring as a whole is: for example, ensuring that each relevant concept lives in one and only one place in the code is a miniature bit of scenarization here. And I suspect that there’s a gap here in agile practices on the Customer side: an effective scenarization is an essential part in presenting your product to its buyers and users, as is the ability to change scenarios as the product evolves.
The Power to Follow up
The seventh and last function is the power to follow up. The journey through the first four requirements isn’t a one-time thing, leading to a collective that has reached its final form. Instead, the resulting collective is a provisional construct, and those placed outside the collective at the end (“enemies”) are there to perplex us, kicking off a new round in which they are candidate members of the perspective at the end of the next cycle.
Scientists bring to this the notion of a research front: the end of one experiment and its analysis suggests many more candidate experiments to carry out. Politicians bring an awareness of changing power relationships: the slogans that got them to power may be as likely to disgrace them two years later. Economists continuously measure the health of a system, its booms and busts and the shifts from one area of the economy to another. Moralists are always on the lookout for areas where we aren’t living up to our ideals, are seeking to represent those who have been previously excluded. And administrators bring continuity to this whole process, making sure that we follow up according to our protocols.
For agilists, this power is embodied in the concept of the iteration or, more generally, the various cycles (minute by minute, hour by hour, day by day, week by week) that pervade an agile product. We know as well as anybody that all decisions are provisional: the code that we write to get a test to pass this minute may look quite different fifteen minutes later after we’ve gotten another five tests to pass. The candidate features that have been excluded from this sprint may well be added to the next sprint; alternatively, our experiences over the course of this sprint may bring new candidate features to the fore that we hadn’t dreamed of a day ago. The composition of the collective is constantly in flux: the release that users are using today will differ, perhaps subtly and perhaps remarkably, from the release that they’ll use next month, next week, or at times even an hour from now.
This power is also at the core of the agile desire for clean code. We know that we’ll be going through this process many more times; we want to make sure that our pace through this process doesn’t slow, that our power to follow up doesn’t weaken. More subtly, the agile obsession with the notion of “done” plays into this power: we want to know when we’re following up and when we’re going through the various requirements, and the sharp boundary of doneness is an essential tool in that regard.
Final Thoughts
Looking back through the previous sections, in general I think agile comes off pretty well. Our tests serve us well right at the start, by giving us speech prostheses to detect entities that would otherwise be hidden within the software, and they also assist with the requirements of hierarchy and institution. And our appreciation of the power of iteration is an excellent embodiment of the power to follow up.
There are gaps, however. In particular, I think we’re weaker than we could be when it comes to the requirement of consultation: having genuine customer involvement is much better than having developers make business decisions on their own, and having the developers use velocity as a metric to inform the pace of development is much better than having a product manager try to decide both what goes into the product and the date at which the product will be released. But the idea that a single Customer makes all business decisions is a mockery of the notion of consultation, of seeking out appropriate spokespeople; while nothing forbids the Customer from consulting appropriately, surely we could give more assistance in that regard?
Looking through the examples that Latour gives from other professions, I wonder what agile could learn from them. I think we’ve done a reasonable job at learning from scientists, and even from some of the other professions (e.g. our focus on a few key metrics has something to do with the virtues that economists bring to this enterprise), but not from all of them. In particular, I suspect that digging into the contributions of politicians would be fruitful: like politicians, we have to win a contest by successfully navigating the desires of various interest groups (both internal and internal), so perhaps we should pay more attention to their skills.
As always, I suspect that lean has much to teach us. The single Product Owner doesn’t bother me in the way that the single Customer does, because the Product Owner’s role is symmetric across business and engineering. Set-based development is one answer to the requirement of consultation: it helps ensure that we don’t cut off discussion prematurely. Going to the gemba comes straight out of that requirement: if you’re perplexed about something, go to where that something exists, consulting with both humans and nonhumans who are located there.
Posts