My last four days, at the Agile CultureCon split between Philadelphia and Boston, have thrown more new ideas and techniques at me than I’m used to encountering in a normal four months. Or more. It was very challenging and exciting, the more so because I was immersed in a culture at some distance from those where I usually hang out.
The organizers (Dan Mezick & Andre Dhondt) and various friends (now including me) are launching from agile software development into new ways of organizing work and communication that dynamite a lot of common assumptions about the necessity of power relationships and hierarchies. What makes this really interesting is not the theory but the working examples. They’re not dealing in vague platitudes, but in methods that can be taught and replicated. (And yes, I will describe some of them later in this post.)
Nobody in this crowd thinks politically (or at least if they do, it doesn’t show); it’s all framed as ways to fix corporate cultures to make them more productive and happier. But what this was, underneath occasional freshets of vaguely new-agey language, was a three-day workshop in practical anarchy.
Pulling me in was the result of a nearly last-minute brainstorm by Dan Mezick, who is a leading figure among agile-development coaches in the Boston area. He approached me by email a few weeks ago reporting that he’d read How To Become A Hacker and considered it (his words) “foundational wisdom”. It gave him the idea that my experience of articulating and shaping the hacker culture might be useful information for what the would-be culture-hackers at the conference are trying to do.
(Dan didn’t know when he decided to invite me that the hacker-culture connection with agile development goes right back to agile’s beginnings. I had been invited to the Snowbird gathering where the Agile Manifesto was hammered out in 2001, and if not for a schedule conflict I almost certainly would have been one of the signatories myself. My occasional conversations with people like Kent Beck and Martin Fowler have since confirmed that other signatories were pretty strongly influenced by my articulation in 1997-1998 of of what the hacker culture had been doing. So, in one important sense, the hacker culture is part of agile’s ancestry.)
Their initial problem, as Dan puts it, is that so far agile development hasn’t been scaling very well. Techniques like unit testing and TDD, design by story, pair programming, scrum, planning poker and the like have amply proven themselves at the small-group level (up to, say, a dozen developers). Properly applied they do boost the hell out of the effectiveness of product teams. But evidence that they can be scaled up effectively to much larger projects or coordinated enterprise-wide development is lacking. Dan sees a lot of snake oil being peddled under the “enterprise agile” label, and he doesn’t like it.
So what has gone wrong? Why aren’t agile techniques scaling? Takes no genius to diagnose that problem: agile, trying to scale up from the bottom, collides with the top-down-imposed conventional corporate habits of death marches, rigid hierarchy, and waterfall planning. And loses, because the imperatives behind all that sludge are wired too deep into the culture of most corporations to be displaced by mere productivity improvements, however dramatic.
Where Dan and Andre and their friends get radical is in the cheerful conclusion that conventional corporate culture needs to be blown up – or, to put it more diplomatically, re-engineered to enable higher productivity. Where they get effectively radical is that they’re not willing to stop at slogans and exhortation. Instead, they want to write a how-to manual. How to meme-hack your corporation so it’s not wasting most of its energy on authoritarian bullshit and territorial games, how to make it a place where more value is added and people are happier. Oh, and where agile techniques can be applied throughout.
The conference had some noise and nonsense in it, including one fuzzy-sweatered wack-job who wasn’t ignored as roundly as she should have been. But with that filtered out, the theme was very clear: we need to learn how to change the cultures that hold people and productivity back so they’ll stop doing that. This is a larger mission than simply “make agile development work” and potentially a far more transformative one.
The contrast with the hacker culture is interesting. We opted out and formed our own big tribe, with members in but not of the places where they work; later (after 1997) we built bridges back to the corporate culture from outside it. The agile people were, in a way, braver than us – they never left and never formed a big tribe of their own; instead, they’ve been trying to reform the corporate/institutional world from within, operating as a whole bunch of parallel microinsurgencies with some common ideas but not a lot of sense of shared purpose.
Well, up to now, anyway. Dan asked me in because he thought the experience of the hacker culture might be relevant, and – it is. Because what this conference showed me is that the agile folks are beginning to struggle their way through the same transition we went through between 1990 and 1998. Once again, I see a culture that had been diffuse, mostly unconscious and local trying to wake up. Thinking about shared purpose; moving from craft practice to intentional technique; asking itself questions about what the things it does mean in a larger context – and beginning to find answers.
Dave Taht (aka Dave in my basement) was along with me on this anthropological journey and disagrees. He thinks these people are at a much earlier stage corresponding to us in the 1970s, because they don’t yet have as much shared cultural capital to build on. He’s got a point; they don’t have a significant common corpus of slang or jokes or hero stories – there’s no agile-culture analog of the Jargon File or the joke RFCs.
For good or ill, they also have no equivalent of the Free Software Foundation. That is, there haven’t been any previous attempts to create a unifying “what we’re about” that failed to take on the majority of people in the culture. Their one previous try, the Agile Manifesto, was a success – at least at naming the movement and articulating very broad principles. In effect, they got their “agile” equivalent of the term “open source” a decade before fully understanding their mission, rather than after that awareness had already almost fully developed as happened with us.
Still, the parallels are powerful. People there ate up the material I brought about advocacy tactics and meme-hacking and leadership (about an hour and fifteen minutes split over three 25-minute sessions) and clearly thirsted for more. My value to them was that I had already successfully pulled off culture hacks on a large scale at least twice – and could explain how I had done it.
Since my blog audience mostly knows that story already I won’t rehearse any of it here, but rather write about what I learned from the interaction.
I’ll start with something relatively simple. I got enough exposure to agile techniques during this conference to figure out something I’d been puzzled about for a while. I knew that the Agile Manifesto described values very similar to those of the hacker culture. I also knew that wasn’t accidental. I also knew that some agile practices – notably unit testing, test-driven development, and design by story – have easily been absorbed and naturalized by hackers. But others (pair programming and scrum, for example) have not been. And I have wondered why this is. The separation between hackers and agile developers seems largely a matter of historical accident, so why has the cross-fertilization not gone further?
The answer is not complicated and perhaps I should have seen it sooner. Most of the agile stuff is designed to improve the quality of the interactions within teams that meet face to face and have stable membership. The hacker culture, on the other hand, evolved to support remote teams in which partipants commonly never meet each other and membership is unstable. The agile techniques we’ve picked up on are precisely those that can be applied in our communications environment.
When I describe the typical workflow of an open-source project to agile-development people they tend to look like they’ve been hit by a truck. Almost all communication by email and IRC, with only sporadic use of even voice phones? People join projects and cooperate for years without ever meeting each other? We take drive-by patches from people who pop up once, then disappear and are never heard from again? How can that possibly work?
One thing that got through to them and stimulated a lot of talk and thought is the idea that how far inside you are on a project is defined by whether and how frequently you push commits to the project’s repository. More generally, we nowadays define membership in the hacker community basically by who is pushing commits to public repositories (yes, I noted that the criteria used to be fuzzier and there are some interesting exceptions and edge cases).
Several people responded to this by observing that the agile community doesn’t have this objective kind of in/out criterion because it doesn’t have shared projects, and mused that maybe it needs to start some.
But let’s get to the fun stuff. Some of the techniques the agile people are playing with and thinking about now make me wonder “how can that possibly work?” But I’ll start with the easy ones.
The problem all of these are aimed at solving is that coercion and power hierarchies waste huge amounts of time and energy, block an organization’s ability to learn, do needless harm to people, and squander resources that could otherwise be turned into productive outcomes. Evil is not just evil, it’s stupid! Not being stupid pays off, therefore not being evil pays off. These are ways to not be stupid.
Before the conference, Dan educated me about the Core Protocols. This is a set of communications practices to be used among humans that are designed to suppress a lot of the bullshit and primate politics that commonly get in the way when we try to do and decide things together. I got to see and use them both by email with Dan and face-to-face in groups at the conference.
The Protocols have at least two results. One is to create psychological safety, largely by guarding the right of participants to opt out of a transaction rather than be subjected to power trips or other forms of manipulation. Another is to make it easy for participants to model each others’ intentions and desires. The consequence is that groups using them can learn more effectively and make good decisions more rapidly.
The Core Protocols are very clarifying – that much is obvious to me even from limited exposure. One of the authors calls them “software for your head”, and they’re a building block that can be used with other kinds of software for your head, including ways to re-invent how we organize groups larger than will fit in a single meeting room.
Two of these got an airing at the conference. One, actually the less radical one, is a kind of organizational design called sociocracy. Yes, I know the name is horrible – actually, its English-speaking practitioners agree it’s horrible, but think they’re stuck with it for historical reasons. No, it’s not socialist or anything like socialist; in fact, a core part of the theory is concerned with using free-market incentives to reward efficient collective behavior.
A sociocratic organization consists of a set of interlocking working circles. The rules of interaction within circles are constructed to support egalitarian behavior within the circle, suppressing normal primate-political bullshit through means recognizably similar to the Core Protocols (they also include interesting procedures for supporting consensus-based decision-making). There is expected to be a control hierarchy among the circles, but the damaging effects of the power relationships that sets up are mitigated by a clever hack called “double linking”.
Each circle has an operational leader appointed by the parent circle it reports to, and each circle has an elected representative to the parent circle, but they are not allowed to be the same person. The pass-requirements-downwards function is disconnected from the report-problems-upwards function.
There’s a Discordian maxim called the “SNAFU Principle” states that true communication is only possible between equals – because where there is a power asymmetry the inferior will tend to tell the superior what the superior wants to hear, and the superior will tend to tell the inferior only that which preserves his superiority. In hierarchical organizations the SNAFU effect leads to a progressive disconnection of decision-makers from reality as information passed up and down the command chain becomes progressively more distorted by this effect.
Sociocratic double-linking is a clever pre-emptive strike against the effects of the SNAFU principle. The existence of a reporting chain separated from command authority at least removes much of the normal incentive for command chains to distort information passing between levels.
There’s still hierarchy in the system, though. The more radical path is to flatten the firm entirely – no bosses, no subordinates, not even sociocratic circles. And this is just what two of our presenters, from a firm called Morning Star, told us about.
At Morning Star, they practice “self-management”. Your job isn’t defined by who you report to, but by your commitment agreements with your colleagues. In effect, everyone in the firm has horizontal contracts with other firm members. The business runs on a painstakingly-maintained process model and objective performance indicators. The contracts include performance targets, and your pay is tied to how you meet them. More details in the book Beyond Empowerment, which lightly fictionalizes the history of Morning Star and then presents supporting factual case studies.
Morning Star must be doing something right – it’s the top company in its market niche and robustly profitable. And it’s far from what most people would think of as the best case for radical experiments in corporate governance – capital-intensive manufacturing using a lot of unskilled seasonal labor. But perhaps the most intereresting thing about Morning Star’s organization is that they’ve scaled it past the Dunbar Limit.
Sufficiently small groups with sufficiently good leadership can make almost any theory of organization work. But human beings have only a limited ability to scoreboard the behavior of acquaintances, which tops out at the Dunbar limit of about 150. Above that size more formal lines of authority and obligation become necessary. Or so goes the theory, anyway. Morning Star seems to be a counterexample.
I shall finish my report by noting that I learned a new way to think about prophecy. Well, a specific and interesting meaning of the word “prophet”, anyway. This was at a keynote address by one David Logan, who has spent years studying what he calls “tribal leadership”. His “tribes” are social networks, usually (though not always) below the Dunbar size limit.
In Logan’s analysis, a firm – or an entire society – is best understood as a mosaic of interlocking tribes, each with its own microculture. Logan distinguishes five culture types or stages: Stage 1 = “Life sucks”, Stage 2 = “My life sucks”, Stage 3 = “I’m great (and you’re not)!”, Stage 4 = “We’re great!”, and Stage 5 = “Life is great!”. The whimsical titles conceal some heft; see Logan’s TED talk about how tribes evolve (or fail to evolve) from the highly dysfunctional Stage 1 (normally found only among criminals) to the high-creative Stage 5.
In Logan’s model, a “prophet” is a person who moves a tribe from one stage to another by – and this is what caught my attention – “preaching the inevitability of values-based change”. If this were a movie, tension-inducing music would be starting to play…
To do this, the prophet first has to understand what the tribe actually wants. Tribes form in the first place because of an alignment of values. The alignment may be around something trivial like rooting for a sports team, or something functional like doing a particular job, or something more profound like a shared aesthetic or political idea.
The point is that a tribe does, at least epiphenomenally, want something. But (the music is getting louder) not every tribe knows what it wants. The shared desire and values may be partly or wholly unconscious, and point to something larger than the tribe understands. The prophet’s job is to reflect the tribe’s values back at it in such a way that it changes stage – wakes up and starts to function at a higher level.
At this point in the exposition hairs are beginning to stand up on my arms. It only gets spookier when he talks about tribes organically growing their own prophets out of themselves to transform themselves – exactly expressing the feeling I’ve often written about that the hacker culture created me in order to be able to see itself better.
And what does a prophet do to transform the behavior of a tribe? He tells stories about what it was, is, and might be. He reminds people in it who they are. And this is the point at which I’m muttering I’ve been here. This guy is talking about me. I never thought of myself as a “prophet” before – I preferred to leave that kind of imagery to RMS – but it is undeniably true that I’ve written mystical poetry for hackers.
Huh. So other tribes create their own equivalents of “ESR”, do they? Interesting. Never thought about that before either. Perhaps we could form a mutual-support group for extruded polyps of tribal consciousness. Or something.
I was so energized by Logan’s keynote that when Dan Mezick told me he had an open session slot because a speaker had canceled it, I stormed into it and delivered an extended rant on practical prophecy 101 – not just what a prophet does but how to do it. With major tactics like giving things the right names as a source of power. Dave Taht recorded at least part of that talk; might be it will make it onto the net.
There’s lots more I was originally going to write about – the epic of the party bus that linked the Philadelphia and Boston halves of the conference, for example, and some of the very colorful people I met, and the exciting beginning of our attempt to create a culture-hacker’s manifesto which I think might someday be considered as important as the Open Source Definition.
But, on reflection, this report has been mostly about ideas, and I think I want to keep it that way rather than wandering further off into personal narrative, no matter how interesting that might be.
So I’ll finish by repeating that I think these are really important ideas. I’m glad I was there for this beginning; there are, I think, many more discoveries ahead of us on this path.
We may yet succeed in culture-hacking not just individual institutions but society as a whole into something saner, kinder, less hierarchical, and more productive on all levels. It’s worth a good hard try, anyway.