malvasia bianca

I tend to think of agile as a way of thinking about programming that’s very supportive of individuals, their quirks, desires, and autonomy. As I’ve been tossing some of the ideas behind this post around in my head, though, I’m not entirely sure why I have that attitude. Certainly the lean pillar of Respect for People sounds very well aligned with autonomy, as is the Agile Manifesto’s valuing of “Individuals and interactions over processes and tools”; and, looking through the eXtreme Programming practices, Collective Ownership (“anyone can change any code anywhere in the system at any time”) sounds like it supports autonomy, and the 40-Hour Week acknowledges that our selves are richer than what is visible at work, with work not being allowed to dominate.

But there are a lot of other XP practices, and a lot of them are about following rules: Coding Standards, Pair Programming, TDD. And, while lean’s idea of Respect for People isn’t at all a sham (it’s a deep-seated belief that everybody has valuable ideas to contribute and should have the power to, for example, stop production lines), lean also codifies that knowledge in the form of checklists that all team members follow to help them (get them?) to work as efficiently as possible.

In retrospect, I think that a lot of what is going on in my attitude is that many of the agile practices happen to be ways that I enjoy working. This meant that I was likely to interpret them as supportive of individuality, but quite possibly a better read is that many of them happened to be aligned with my individuality, and people with different tastes could just as reasonably seeing them as suppressing their individuality.

So: am I completely wrong? Should I more correctly interpret the XP practices, for example, as dicta from above that suppress individuality? I don’t think that’s true, either. For one thing, I rarely get that feeling from agile thought leaders. They may be uncompromising on what XP means, and say that, if you’re not following the practices, you’re not doing XP, and that you might learn something new if you put down your individuality and followed those practices. There’s an important difference, however, between saying that they believe XP practices are a productive starting point and saying that everybody should blindly follow those practices, and those same thought leaders will often say in the very next sentence that, once you’ve given the strict practices a real try, you should next evolve it to better fit your needs and circumstances. (Where those circumstances very much include the individuals on your team, not just your business and technical context.) In fact, many people say that retrospectives are the single most important agile practice!

Or take Scrum, the agile methodology whose name is, in my experience, invoked in the widest variety of contexts. Part of Scrum’s popularity is due, I think, to its lack of dictates about what to do, which many companies interpret as thinking that it fits well into their pre-existing practices. But, if those pre-existing practices include top-down command-and-control direction from management, then they might want to look at Scrum more carefully: the Scrum Guide doesn’t acknowledge managers at all, with the only roles being the Product Owner, the Development Team, and the Scrum Master. And yes, many people interpret the Scrum Master as being a manager; but the guide characterizes the Scrum Master as being “a servant-leader for the Scrum Team”, with removing impediments a key role and giving orders not. (And a manager isn’t hidden on the Development Team, either: “Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule”.)

So no, agile isn’t top down, it doesn’t suppress individuality. But it doesn’t give unfettered reign to individuality, either: returning to the manifesto, we see individuals joined at the hip with interactions, the word “team” is everywhere in Scrum, and people working in a Lean organization are very far from free agents. If I were to pick one value for agile, “communication” would be a good choice: most of the XP practices are about improving communication directly or indirectly, as are practices from other agile methodologies. (I haven’t mentioned Kanban yet, but it’s all about clear signaling of your current state, needs, impediments, and priorities.) And you can’t communicate if you’re on your own!

And that communication flows everywhere. Maybe that’s where agile’s acceptance of individuality comes in: if communication is going to flow through people, then it has to accept that those people are, well, people, each with their own individual effect on (contribution to!) that information flow. In particular, a top-down, command-and-control organization hinders communication: yes, messages that look clear are broadcast, but they’re only sent in one direction, and the more top down you are, the harder it is to check whether that communication has even been heard as you intended it to be heard, let alone to learn from mismatches between how it is interpreted and how the intent was.

And this, in turn, leads to the question of team size. In a team of one, a world where everybody is a free agent, meaningful communication can’t exist: there’s nobody to speak to who really matters. But if the team gets too large, you have the opposite problem: you can say that everybody’s voice matters, but if there are too many of those voices, then you can’t hear them. So: a large enough team to allow for a range of meaningful interactions, but a small enough team where everybody knows everybody else as an individual.

This small team size works well with many of the other core agile values and practices, too. Over the last year, I’ve gotten a much more visceral appreciation of the importance of retrospectives than I ever had before; and one of the things I’m really feeling there is that, to experiment well, you need a large enough group to give meaningful reinforcement to your experiment but a small enough group that new ideas can come to the fore and can be played with. Sure, if you have a twenty-person team, then sometimes all twenty people need to do something in the same way, but you’ll learn a lot more quickly if there are five-person groups that can come up with ideas, try them out, modify or discard them, and come up with ways of working that work well for their context and, perhaps, for the larger group as well. Or take the servant leadership that scrum recommends: maybe you can command a team of twenty, but serving twenty people? Not so easy.

I refer to myself at times as an anarchist. I’m actually not familiar enough with anarchist literature and philosophy to know how accurate that label is, but it’s definitely the case that I don’t like other people giving me orders, and I don’t feel comfortable giving other people orders either. (Though I’m sure there’s some amount of self-delusion in the latter—the various people who have reported to me over the years probably have a more jaundiced view of me in that regard, and I’m certainly not shy about my opinions.) But, while I’m far from an expert on what the word “anarchist” really means, I am fairly sure that the stereotype that “no rulers means people do whatever they want” is, at best, a very partial view of the philosophy. Instead, you’ll often find anarchist paired with other words like “collective” or “syndicalism”, words that say that, at its core, anarchism is concerned with forming groups, with organization, with people coming together. (Returning to agile: agile is in large part about choosing your priorities, but that choice is ever so much richer if it’s done as part of a group!)

And, of course, in so many situations this kind of non-hierarchical organization is accepted and natural: when hanging out with friends, when forging a marriage. Some companies seem to pull it off, too—it’s no coincidence that multiple friends forwarded me links to the Valve Employee Handbook, and their website proudly proclaims that they’ve been “boss-free since 1996”. They’ve certainly been successful with that strategy, as has Semco. Though that’s a pretty small list of success stories; who knows whether that means that those companies are the vanguard of a new way of working (democracy was once a new idea even outside of the workplace, after all) or a sign that that approach will rarely work in business contexts.

Fortunately, I don’t need to answer that question. But I am learning something about myself, that I like to be in situations where I’m working closely with a handful of peers. And I’m learning something about agile, too: the focus on agile teams really means something, both in terms of team size (neither too large nor too small) and in terms of being empowered groups of empowered individuals.