Exploration Through Example

Earlier, I claimed that one of the distinctions between a money economy and a gift economy is that, in a money economy, it is the transaction that matters. The person with whom you’re transacting is, in principle, irrelevant:

That is, when I buy a candy bar from a convenience store clerk, I don’t need a personal relationship with him, nor does the exchange of coins for candy create one—any more than putting those coins in a vending machine would establish a personal relationship with it. In contrast, gift economies are both about moving goods around and also about managing (creating, maintaining) the personal relationships that make up a “We”.

If you’ll forgive me broad strokes, prior to Agile, software development was transactional. “They” (marketing, product planning, “the suits”) gave “Us” money and requirements documents. In return we gave them features that had business value for them: that is, features that could be traded to third parties for more money (and thus allow further transactions).

(Note: I am speaking mostly of the Enterprise and Big Company software contexts. Smaller companies and consultancies often operate differently.)

A simplistic way of looking at one part of Agile was that it simply exchanged the requirements document for a product owner, who is both more efficient and more effective at answering questions than a requirements document can be. But something else happened. The product owner was extracted from Them and placed in close contact with Us. He was converted from a symbol to a person. In projects that work right, he becomes one of Us.

As such, he plays a unique role, that of Our main interface to Them. We give him valuable software at frequent intervals, and he turns around and uses that software to represent Us (including him) to Them. In return, he helps us when we need it: he protects us from many of the gyrations of the business as it decides what it needs, who has control, and the like. He pushes back against bad decisions and encourages good ones. When We are less than perfect, he gives us slack to do refactoring sprints and the like.

A transactional economy has been turned into a gift economy, mostly hidden from the world outside the team.

Within the team, people use the phrase “business value“, but I don’t believe they mean what the world outside means. The phrase stands in for the network of social obligations oriented around the product owner. “Business value” is that which keeps the product owner happy, gives him strong evidence for his arguments, and allows him to give the gift of protection. [There’s also a strong identification with the end user, but I’m going to leave that out for now.]

Within the team, I claim, “business value” is a symbol, much like the cross is a symbol to the devout Christian. The cross represents the stance a believer should take to the world and the people around her. In case of doubt, the cross can remind the believer of the kind of action that’s almost always a good idea. In the same way, “business value” reminds the team member of the kind of action and attitude that will keep the team functioning: when in doubt, err toward making something the product owner can show off.

Business value is, then, a boundary object. A term from the sociology of science, “boundary object” refers to an object (physical or mental) that allows groups with different goals to coordinate their actions. In the original paper, a museum of vertebrate zoology means different things to University administrators (it’s a way to compete with their rival, Harvard), California legislators (a symbol of their State’s coming of age), scientific researchers (a tool for a particular ambitious research programme), and specimen collectors (a way to preserve the memory of a vanishing environment). So long as the goals and meanings don’t conflict, it doesn’t matter that they’re different.

The same is true of “business value”. No one should care that the team’s meaning for that phrase has all sorts of different connotations and relationships that have nothing to do with exchange-for-money. The software people are a goose that’s suddenly started laying golden eggs. Who cares what they believe about what they’re doing?

This person, that’s who:

The question that keeps getting asked [by the product owner] is what value does the customer get from paying back this technical debt? What value does the customer get from simplifying this design? What value does the customer get from cleaning this code? The answer is almost universally none. So, the [product owner] keeps pulling those activities out of the backlog because these are all internal codebase issues, the customer does not see it or realize value from it, at least not directly.

The product owner is breaking the tacit agreement that a boundary object requires. Not only must the team justify their request, not only must they justify it in terms of business value, they must also adopt the product owner’s definition of business value. This, I think, is an act of, well, cultural imperialism. Not only must we be useful and productive, we must be useful and productive for the right reasons. Not only must we do the right thing, we must believe the right way.

This insistence on goodthink is related to the scorn toward the stance of reaction I claimed earlier. The team cannot be a black box operating according to its own rules; it must have a visible interior that operates correctly.

I’ve done precious little reading in colonialism, but all this reminds me of the attitude of colonialist rulers towards the colonized: they must be remade. For that reason, I think learning about the strategies the colonized used to preserve their culture might be useful to us in Agile.