The agile community up until recently, despite all of our excellent intentions, has won a reputation for dividing the software world into "Us," the ones who know how best to build software systems, and "Them," the great waterfall unwashed. I think this has been, at least to some extent, sadly well deserved.

There have been at least hints of other divisions as well: Us the unempowered team vs. Them the Dilbertian managers from hell. Us the true agilists vs Them the faux agilist poseurs. And even Us the abused programmers vs. Them the unreasonable customers. We've got a fair bit of anecdotal evidence now that such views have not been helpful.

Even in the presence of real dysfunction, it matters a great deal how we conceive of the situation and especially the people involved. In particular, it does none of us any good to look for enemies, or victims to be protected from enemies. When we presume that there is a Them that is somehow set against Us, we are already subtly creating a barrier that creates Them. We are alienating people. We may not realize we are doing it, but we are likely foreclosing the opportunity to create better commmunity. So, how has this come about, and how are things changing?

First, a bit of background.

When agility emerged in the late 90s, several of us underwent passionate epiphanies, embracing one or another specific method. Again, our intentions were certainly good. We wanted (and still want!) more business value, less waste, better code, more fun programming. We wanted honor and respect. We wanted no longer to be judged, belittled, coerced, or manipulated. We had suffered too long at the hands of dysfunction. We had a fair amount of pent up frustration and anger.

This fueled the passion of our conversion. Finally! The Right way to build software! Hallelujah! Test-infected, feedback-infected, we went forth in the fervor of newfound jihad, test-driving, refactoring, bashing down cubicle walls, scribbling every idea on 3 x 5 cards, tossing our documentation, retrospecting, and automating the build/test/deployment cycle.

But in our zeal, did we reciprocate the honor and respect we expected? Not always. Without knowing we were doing it, perhaps, we went looking for enemies as much as for allies. All issues of specific practices aside, we sometimes resorted to some of the same interpersonal approaches that had hurt us so badly. We sometimes judged people, belittled people, harassed people. This was nowhere in our principles and practices. It just happened.

My opinion is that we got carried away with ourselves. It was a mistake, typical of newcomers to a compelling belief system. All these years later, one hears entirely too many stories of big-name agile consultants still berating or bullying their clients, in response to pushback on this or that specific recommended practice. Consultants who throw up their hands and say, "Well, Hey, if you're not willing to at least try all the practices, then there is no helping you. You just don't get it."

In addition to being ineffective, this is plain wrong. It has nothing to do with which teams adopt which practices, and how successful or healthy the teams are or are not. Bullying and arrogance are never appropriate or helpful, and just as we always knew we deserved them, every development team everywhere deserves honor, compassion, and respect.

This division between "agile" and "not agile," as if agility were somehow binary, is a harmful oversimplification. Agility is not binary. It's a spectrum, like the rest of the qualified world. It is not true that you are either Agile or Waterfall, as provocative as that might sound. There was always a little backdoor agility in just about every waterfall implementation, and as the entire industry slowly goes agile, the binary distinction is decreasingly useful.

Furthermore, there is no perfect agile approach. Certainly some teams, codebases and projects are more agile than others. Many of us have seen that more agile teams, projects and codebases tend to be more successful and healthier, and so we are on a path from less agile to more agile. We are pursuing and studying agility. But we are all on that agile path together, and being on that path together matters much more than our different positions on that path. Our similarities are much more important than our differences. We can and should agree more than disagree.

However much we discern quality differences in the agility of one team or method over another, we have no right to judge the people involved. Discernment is always helpful, since it helps us all along the path. Judging people is never helpful, since, again, it is alienating and divisive rather than sharing and inclusive. It burns bridges instead of building them. These may sound irrelevant to agile adoption and agile coaching and mentoring. They are not. They are at the crux of our health or dysfunction. (For a more detailed description of how judging insinuates itself into our interpersonal communication, see this article on Empathetic Listening.)

And here is another (perhaps subtle) irony: the division between "agile" and "not-agile" has, itself, more than a little taste of non-agility to it. Let me explain.

In the revised version of Extreme Programming Explained (by Kent Beck and Cynthia Andres), the authors make clear that XP is about cultural change and community, first and foremost. It is about people learning and growing together. Two key practices from this book are Respect and Whole Team, which expressly insist that we knock down barriers between "Us" and "Them," so that there is only "Us." These practices invite all of us to be inclusive, not exclusive. They ask those of us on the agile path to treat each other with honor, compassion, and respect.

This has several specific ramifications. For one thing, it means that wherever you are on your agile path, I should not judge you. I may discern some characteristics of your approach that I feel are healthy or unhealthy. But if you tell me that you and your team are most comfortable at position X on the agile path, and that works for you, my response should be "Hey, that's great, if that works for you. That's OK."

I may have specific recommendations for how you and your team can get more agile, if you decide that it's worthwhile to try it. I may strongly encourage you to be courageous, to make a leap of faith, to push it a bit further and see what happens (after all, trying things and responding to feedback is the essence of agility). But I'll always respect your judgment and decisions, whatever they are.

Don't get me wrong. Specific practices matter a great deal. We cannot hope to master the principles of agility without mastering the practices. They are the etudes from which we learn to produce real music (though they are not the music itself). When we work harder and harder on the agile practices, we internalize the principles that underlie them. We get it in our fingers, as jazz players say. We get a feel for when to do things by rote, and when to deviate. We learn to improvise. There is no way down the agile path except through this process of internalizing the practices.

Without a certain level of pair programming, helping me to spread and gather knowledge, and preventing individual programmers from getting stuck, I get nervous. That feedback is very important to me. But there are times when I now know from pairing experience that I can afford not to pair right now, and that choice is most expedient. For example, I might determine that neither the code nor the spread of information will suffer from not pairing on a particular task as much as my deadline will suffer from pairing on it. There are also times when I simply cannot afford to pair. For example, there is not enough time, money, pairing expertise, or political capital available for the particular situation. Finally, there are cases when I cannot be persuaded not to pair. For example, when teasing apart a Gordian Knot of dependencies in an unfamiliar, business-critical legacy codebase, retrofitting characterization tests as I go. I definitely want two programmers covering each other's backs on that one.

So I know enough now to make the pairing choice (however painfully) in a way that is still most appropriate, and most agile. I still prefer that all code on the teams I lead be written by pairs, whenever possible! I simply know enough to know when I should choose not to.

In general, I prefer to work with all of the Extreme Programming (XP) practices, whenever the circumstances permit. That's where I am on my agile path. I believe that many teams defer their good-faith attempts to adopt some XP practices not out of a strong knowledge of overall agility and appropriateness, but instead out of FUD (Fear, Uncertainty, and/or Doubt). But you know what? That's OK. That's where they are on their agile path. For any team on an agile path, including mine, I can probably imagine a way that they (or their parent organization) could be more agile. I'm always looking for more agility!

We are all entitled to traverse our own paths from fear to courage, in our own way and at our own rate. We keep trying things, measuring the feedback, and adjusting course, in every context and at every level.

None of this tolerance provides an excuse for not continuously improving, or for being complacent at a particular level of agility - quite the opposite. Agility insists on continuously improving. The subtlety is that it insists that wherever we are now on the agile path is still OK. We are not incompetent developers, or ostriches, or losers, because of our particular position on the agile path. Again, what matters most is that we are on that path, together. We are all improving together as part of a larger agile community.

At first, I was describing this tolerance and compassion as Agile 2.0, but the term has some unfortunate effects. It implies that "Agile 1.0" (whatever that means) in any way endorsed the arrogance I'm describing here, which it did not. It also sets up yet another division in the agile community, which we certainly do not need.

No, I won't make the mistake of creating yet another barrier here, between Us, the agilists who are never arrogant, and Them, the agilists who are. In fact, in case the above paragraphs don't imply it strongly enough, I'll come clean right now and admit to having made arrogant remarks in the past about software development approaches that were not as agile as I prefer. On the one hand, it pains me that this is true, while on the other hand, I've learned some useful and interesting things from my introspection. In fact, I've gotten more agile through this introspection. So why was I arrogant and defensive? Why did I reflexively judge someone else?

I think it has to do with ego attachment and identification (see an article here on how I think identity can help or hinder the development of Whole Teams). I believe that it's possible for us to become arrogant and defensive when our belief systems (e.g., a fixed set of agile practices) are challenged. Someone questions the wisdom or applicability of some practice or tenet that is close to how we define ourselves (personally, professionally, politically, whatever), and before we know it, we react as if someone has told us our children are ugly. We snort, we huff, we roll our eyes. Our blood boils. These morons! Don't they realize they are stuck in a dysfunctional pattern? I'm just trying to help them help themselves! Why won't they listen to me? Are they insane or just plain stupid? Well, to Hell with them!

Though I'm confident that this reaction is something I am less and less capable of, I know that if I don't watch myself, it can overcome me. I work pretty hard to watch the quality of my reaction, and when I say something hurtful, I try to rectify that hurt promptly.

What I have learned to do is discern the difference between discernment and judgment. By discernment I mean noticing that a practice or pattern is unhealthy or bad. By judgment I mean judging the persons involved as unhealthy or bad. Whenever I feel an emotional charge of anger or frustration, I presume, these days, that my ability to discern without judging is being clouded. I do what I need to do to calm down, to sit with that emotion, until it passes. I then express what I am discerning in the situation in a way that honors everyone involved, without judging them. I'm not claiming this is at all easy, at least not for me! But I do claim that it's essential to the work I do.

There is a wide spectrum of leadership styles, running from imperious, paternalistic control to compassionate facilitation. Thought we have all seen that leaders worldwide still tend toward the former, many of the most successful leaders claim that the best leadership hews to the latter. It influences through example, encouragement, and through a fundamental alignment of responsibility and authority. One of my favorite agilists, Mike Hill, taught me that we can only influence those in agile transition by "listening, remaining calm, finding the fear and assuaging it." Mike says "throw the stick away, and invent new carrots."

Authentic leadership artfully blends hierarchy and heterarchy to let the best systems, solutions, and practices emerge from the idiosynchracies of the current, local context. It lets the right systems grow like the right plants in a particular organic garden, instead of trying to manufacture them homogenously like a factory-style agribusiness farm. And yes, it reflexively honors and respects people, and treats them with compassion.

There is great new work out there in the world of agile management and authentic leadership. The agile management system that I believe holds the most promise is called Holacracy, developed by an excellent and unique agile group at Ternary Software. For a good introduction to Holacracy, see the Holacracy website at www.holacracy.org, and the Cutter Consortium Executive Report by Ternary CEO Brian Robertson called " Holacracy: A Complete System for Agile Organizational Governance and Steering." To my mind, Holacracy represents an entirely new ballgame for agile management. Within a well-run Holacratic system, the kind of arrogance we're discussing here would be gently and firmly excised - the system itself would not permit it.

Here is where we start to get just a tad esoteric on our agile path. Buddhism champions the idea of equanimity, which is essentially the ability to handle whatever comes along without freaking out. The premise is that while we have but limited control over the frustration, pain, and suffering in our lives, we can learn to control our reaction to such unpleasantness. The irony is that the more equanimity we possess, the better "control" we magically seem to have over our circumstances, and the more easily we can avoid the unpleasantness.

Equanimity is at the heart of true agility. The more equanimity we possess and exhibit, the more agile we can be. I could name several agile software thoughtleaders who are developing and articulating this less fundamentalist, more tolerent, more respectful side of agility. They reflexively treat everyone with honor, respect, and compassion. When a software project is trying desperately to run off the rails (and when are they not?), these kinds of agilists stay cool and calm, striving to remember and remind everyone else around them that deep down, it's all OK, and that there is a lesson or opportunity that is always trying to emerge.

It feels to me that there is a community of agilists emerging that share these values. In addition to people like Kent Beck, Mike Hill, and Brian Robertson, all mentioned above, I've been influenced here by another few folks in particular. From Ron Jeffries, who has seen it all, I learned "The trick is this: pretend you aren't afraid," meaning that through calm, purposeful, focused attention, we can traverse difficulties most easily. From Dave Hussman, a supremely relaxed and easygoing agile coach, I learned the phrase "Roll with it," meaning something like "Try something that seems appropriate to the current context, measure the results, and adjust accordingly. Meanwhile, dude, enjoy the ride!" From Anth Moquin, I learned that "complexity is our friend," and that "hidden in every problem and challenge are the seeds of the solution." Again, if we freak out, we're less likely to be able to perceive that hidden solution.

I'll say it once more: our intentions were always good. But I'm hoping that our behavior is evolving. As it tends to be expressed by its advocates, I'm looking for a gentler, more tolerant, more relaxed, less dogmatic, but still continuously-improving agility.

I think this is where agility is headed now. Perhaps this is where we were always headed.

-- Patrick Wilson-Welsh, Adaption Software     revised 8-28-06

[More of Adaption's Articles.]