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.

Gift economies have a place in software lore. Eric Raymond used them to explain how open source works. Corey Doctorow built a non-monetary economy in his Down and Out in the Magic Kingdom.

My reading is that neither one of these are normal gift economies. Doctorow’s “whuffie” has the essential properties of money: it is quantifiable, you can lose it, and you must be concerned about whether the books balance.

Raymond also tames the gift economy by describing the open source hacker’s motivation as reputation, conceptualized as something numerical. By giving away software, the hacker gains reputation—just as the Doctorow character adds to his whuffie. This is perhaps because Raymond (if I recall correctly) takes as his exemplar of the gift economy the potlatches of the Pacific Northwest. However, as David Graeber points out, those examples of extravagant givings-as-status-competitions were taken from a time when the traditional culture was incredibly destabilized by sudden contact with an outside civilization (us) who flooded parts of the economy with wealth. It’s dangerous to assume they represent not-destabilized gift economies.

What both of these authors are doing, it seems to me, is characterizing a post-scarcity economy as one where we’ve just replaced money with something else that follows the same rules. They assume we are all, forever, homo economicus.

A better exemplar of a gift society is a well-functioning neighborhood in a high-trust society. A neighborhood like mine. I help one neighbor fix his bicycle (easy). I help another elderly neighbor chase a bird out of her house (took me forever). After our first zucchini-growing attempt, we gave excess zucchini to as many neighbors as would take it. In what-I-claim-is-not-a-return, one neighbor lights the pilot light for Dawn when I’m away. Another gives us excess pears. Another lends some muscle and advice when our car got iced+snowed in.

The important difference from the Doctorow/Raymond interpretation is that no one keeps track. I don’t have a ledger in which I record the value of my helping-my-neighbor-fix-his-bike and letting-him-extend-his-driveway-across-the-property-line and deduct from his debt to me the value of recommending-a-contractor and lending-me-his-snow-shovel-when-mine-broke. The very idea is absurd.

The assumption of a gift economy is that if you do neighborly things for all your neighbors, all your neighbors will do neighborly things for you. It’ll all balance out in the end, without anyone keeping track.

Caveats:

• There are people who cheat the system—the neighbor who often takes and rarely gives. That person is excluded from the gift economy to an extent compatible with peace in the neighborhood.

• This sort of gift economy happens in the egalitarian portion of society. (Graeber has a phrase for this, but I forget what it is, and my copy is thousands and thousands of kilometers away.) The Big Guys may contend under different gift economy rules, but you and I are not Big Guys.

Bruce Sterling wrote a short story that I think captures the difference in attitude between the participant in the gift economy and in the money(like) economy.

First, watch this video. Watch it once for pure enjoyment, if you like, then another time to concentrate on the foot movements of the woman. Ignore the flourishes (where she whips her heels around) in favor of how the other foot moves. (Turning the sound off helps me, and it may help you.)

To the right, please see a snapshot taken just after Sr. Naveira has led a barrida (”sweep”). (For more on that step, see this video.)

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move. I don’t say “mental” lightly: one of the hardest things about learning to follow is learning to squelch the urge to anticipate.

“Mental” goes further as well. As a leader, you can’t see the face of your partner, but you can see those of other followers, and they often display a sort of eyes-closed, inward-facing concentration.

(My description makes tango sound like a very command-and-control dance, where the leader plans and the follower executes. It pretty much is, at least in its traditional form, but the leader also has to react smoothly. See the postscript for more.)

I call this readiness to react gracefully to events that happen too fast to think about the stance of reaction. I contrast it to the stance of reduction, a readiness to reduce (abstract away, simplify, generalize) the world’s complexity into something simpler that you can work with and think about. We knowledge workers are good at that, to the point that we’re often scornful of other stances.

Many of the reductions we humans have come up with have great “stickiness”. For example, economists make their way in the world by modeling that messy species, homo sapiens, as “homo economicus”:

… a being who desires to possess wealth, and who is capable of judging the comparative efficacy of means for obtaining that end. — JS Mill

(Nowadays, economists speak of “utility” rather than just “wealth”.)

So sticky is the “homo economicus” reduction that economists face the occupational hazard of treating it as the only model of human behavior, which can make them say awfully silly things. Similarly, elegant and simple software development models like the V-model are so elegant, so simple, so pleasingly linear that their failure to work with real human behavior and limitations is commonly seen as the fault of the people, not the model.

One of Agile’s original attractions to me was, first, that it doesn’t abstract people into predictable, controllable units as much as other methodologies do, and, second, that it allows people to make decisions by reaction (”gut feel”) as well as by reduction (”rational argument”). My favorite example is the idea of code smells. Smell is one of the strongest and least rational senses: if you open a bottle of milk just under your nose and get a good whiff of rotten, you don’t stop to analyze the situation—you do something. So smell is a good metaphor for the reaction of an experienced programmer to dodgy code: the perception and reaction comes first. The justification for that reaction comes later, if at all—perhaps only if someone else demands it.

(I think of code smells as tacit knowledge with motive power.)

Programmers have long talked a-rationally about code, using phrases like “I think the code wants to…” Agile (or perhaps only XP?) makes that respectable.

Now let’s turn again to the quote I talked about in my gift economy post:

The question that keeps getting asked 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.

I want to claim that the true answer to questions like “why should I let you simplify the design?” or “why should I let you clean up the code?” is “because cues that you can’t perceive are making me move in that direction”—in the same way that cues you (my reader) probably can’t perceive are making Srta. Muzzopappa move in the video above.

But that would almost certainly not convince the product owner in the quote above. First, in modern hierarchical society, instinct is something leaders use to justify orders to subordinates. Subordinates don’t get to do that; they must provide their leader with rational (reduced) arguments for decisions and claims.

Second, the product owner has declared that the rational argument must be of a certain form: one that boils down to numbers (or at least to tokens that can be placed in order of increasing value). That can’t be done with code cleanup, which is about reducing the cost of an unknown number of future stories by some unknowable amount. The programmer must either lie or speak what, according to the groundrules, is nonsense.

What’s the effect of this habitual favoritism toward the stance of reduction?

Well, we know that the expert human brain disfavors what we normally think of as rational thought. Read Montague argues that’s because rational thought is expensive in terms of energy consumption, so the brain uses it as a fallback position. By default, we mostly act unconsciously, with the unconscious mind forwarding only anomalies to the rational part of the mind.

But rather than playing to our minds’ strengths, we ignore them. We spend our precious learning time training our rational mind instead of practicing our graceful reactions.

I’m not saying we shouldn’t train our rational minds: we need them to handle those anomalies. But if we train only them, we get… well, we get what we’ve got. So I suggest reversing our learning budget.

I especially think we should practice our graceful reactions to the rather unnatural human interactions that make up a software project. We should downplay weak-to-useless reductionist approaches like MBTI (about which, more later) in favor of the intentional learning and adoption of an appropriate stance of reaction.

I will write more on this topic, including some thoughts derived from how tango is taught.

Postscript: The reacting leader

Here is a picture of a tango milonga (dance):

The room is often very crowded. And each one of the men could go in any direction at any time. If you plan a complicated set of steps, your plan will surely be frustrated by someone moving into a spot you intended to go. So the leader must react to unpredictably changing surroundings.

He must also react smoothly to his partner. For example, suppose I make a bad lead: I thought I asked my partner to move forward and turn to face me, but I didn’t signal the distance of her step correctly and now she’s beyond me. I had intended to ask her to gracefully reverse her direction, but she’s not in the right place for that. I must make my next lead fit where she is, not where I wanted her to be.

Credit where credit’s due

The clip and snapshot of Federico Naveira and Inés Muzzopappa are used with permission of Gigi Canavese.

The picture of two couples is the cover image of A Passion for Tango, by David Turner.

The picture of a milonga is used with permission of Alto Maltés.

@Vaguery tweeted:

Someday I would like to explore who “we” is. The company, the team, or the people on it. Saying “all of those” is glib.

Item: a gift economy is one characterized by people giving other people things without knowing or caring when (or perhaps even if) they’ll get something in return, and without assuming that their gifts to person X will eventually balance out with X’s gifts to them. (In the egalitarian portions of society, the closest assumption is that their gifts to All of Us will balance out with the gifts they get from All of Us.)

Item: pre-money economies were primarily gift economies. They were not, as I was taught, barter economies. Barter economies have the same “books must balance” concerns as money economies—they’re just less efficient. Like money economies, barter economies are, uh, instrumental. What matters is the transaction, not the counterparty. 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”.

Item: Gift economies still exist alongside money economies. I helped my neighbor with his bike brakes a while back. Did I add that to an “aid to/from the family directly to my east” account? No. If our lawn mower broke, I do expect that Dawn could borrow theirs while ours is being fixed. But it’s absurd to think that I would wonder whether whether he’d now repaid his debt exactly, or if I owed him more help now, or if he still owed me. Only a University of Chicago or GMU economist would think that way, not a normal person.

Item: Teams of people in a workplace typically have a gift economy going on. I’ll go further than that. I’ll define a team—who “We” are—as a group of people who are knit together through a gift economy, particularly the exchange of favors (asked for or unasked for).

Example: Many Agile teams have “refactoring sprints” or the equivalent, where the Product Owner explicitly gives the team time to deal with accumulated mistakes and uglinesses. While (especially the first time) there might be hand-waving about how this cleanup will pay for itself eventually by allowing faster change etc etc blah blah blah, no one keeps any books that are eventually expected to balance. I characterize this as a gift from the Product Owner, who is one of “Us”. He gives this gift because he knows the rest of “Us” will go out of their way to help him someday, probably someday soon.

Example: In a comment on this blog, Daniel Hinz wrote:

The question that keeps getting asked 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.

This product owner sees no reason to make a gift to the team, only a transaction that trades quantifiable-ish value for quantifiable cost. He has only weak social ties to the team. He is not part of “Us”.

Conclusion: The people on the team are those who do favors for others on the team for no good, sound, logical, defensible reason.

Disclaimer: I’ve just begun serious reading on gift economies. More research is needed.