Andrew Binstock recently wrote a blog entitled The Corruption of Agile, which built upon another blog by Allen Holub entitled The Agile Holocracy. Allow me to summarize:

Holub says:

“…agile is a culture, not a set of practices…”

Binstock amplifies:

“Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it’s Agile, if not, then it’s doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile.”

At first blush these statements seem reasonable. After all, a culture is an expression of values. However, Holub’s and Binstock’s statements carry with them the implication that culture and practice are separate. They are not. Indeed, culture is defined by practice.

You know the culture you are in by observing the practices of the people around you. If you see a woman in a burka, you can guess her culture. If you see a bride and groom breaking a glass under a canopy, you can guess the culture. If you see a batch of children swinging a stick at a paper mache donkey hanging from a tree, you can guess the culture.[1]

You can’t have a culture without practices; and the practices you follow identify your culture.

###Example As an example of this I was once a member of a Jiu Jistsu dojo: Hakko Ryu, the School of the Eight Light. We adhered to the practice that, upon entering or leaving the dojo, we would bow to the dojo. This was an expression of respect for the place in which we learned, and for the knowledge and skills that we gained. If a new student joined, they would quickly observe and emuluate this practice. No one had to tell them to do it. The practice was contagious.

One day, our Sensei proposed a new practice. If you were late to class, instead of simply bowing, you would also drop down and do 10 pushups. He asked us if we would accept this new practice. This created an immediate schism. The younger folks were all in favor of this new practice because it was an expression of respect for the value of punctuality and also respect for those students who were on time. Others of us were opposed because this new practice represented a disrespect for those of us who had complex schedules that made regular punctuality impractical. We valued our professions and our marriages above the dojo and did not want that value punished.

The Sensei had made his proposal at the end of a class, and asked us how we felt. I blurted out that I was “fundamentally opposed”. When asked why, I could not articulate the reason. The practice struck at a value that was so deep and intrinsic, I could not find the words. Indeed, even though this event happened over fifteen years ago, I only just found the words as I wrote this blog. At the time I simply responded by saying I needed more time to process.

The class ended with no decision. The subsequent scene in the locker room was grim. Those of us who didn’t like the proposed rule eyed each other and shook our heads. One member even vocalized his frustration by saying “things are changing for the worse around here.”

Fortunately, before this negativity could get out of hand, the Sensei walked into the locker room and said: “Forget I said anything about it. Please act as though the proposal had never been made.” This was a very wise move. The negativity and suspicion had not had time to take root, and by the next class it was gone.

This is an example of how deeply entangled practices are with values and with culture. Cultures express their values through their practices. It is absurd to imply, as Holub and Binstock do, that practice is irrelevant to culture.

Despite Binstock’s assertion, if you find yourself in a team who practice continuous integration, short iterations, pair programming, and test driven development, it is a powerful indication you are in a team who shares the values of the agile manifesto. If they did not share those values, they would not follow those practices.

###Ritualism Of course it’s possible for a team to be so entrenched in practice that, over time, they forget the values expressed by those practices. This is a common failing of bureaucracies and religions. They become so strongly defined by their practices, that the practices become rituals, the original values are forgotten, and the rituals become the values.

The fear of ritualism is appropriate. In 1999, when Kent Beck and I decided to put our energies into the promotion of Extreme Programming, we feared that we could be starting a religion instead of a movement, and vowed to fight ritualism when it arose. This concern and vow was expressed again in the 2001 meeting that produced the Agile Manifesto.

But in the years since, ritualism has not been the problem. We don’t see lots of people ritualistically practicing pair programming, test driven development, small releases, on-site customer, etc. We do see people adopting these practices out of enthusiasm. But enthusiasm should not be mistaken for religion or ritualism. Enthusiasm implies a change to the status quo; ritualism implies the exact opposite.

Perhaps it was the fear of ritualism that motivated Holub and Binstock to suggest the separation of practice from culture. Perhaps they fear that the emphasis upon practice is necessarily a deemphasis of value. But this is entirely incorrect. The current enthusiasm for TDD, for example, is a very deep expression of value.

In any case, if you separate the practices from a culture, as Holub and Binstock suggest, then you corrupt the culture. You simply cannot have a culture devoid of practice.

###TDD I raised the specter of TDD because Binstock railed against it rather loudly in his blog. For example:

“It will pain some readers to know that the vast, error-free Internet predates Agile and even predates TDD. Crazy, right?”

And again:

“When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than the a function of careful discipline and development rigor.”

These rather snide complaints are disappointing. Is a practice like TDD, or the enthusiasm for that practice, so threatening that it should be answered with derision?

Of course good software was built before TDD. Good software is being built today without TDD. So What? Those facts imply nothing at all about the effectiveness of TDD. After all, many doctors saved lives before the practice of sterile procedure, and many accountants managed to keep reasonable accounts before the practice of double entry bookkeeping. So what? Past success does not imply the ineffectiveness of new practices; nor does past success imply that the enthusiasm for new practices is inappropriate.

###The Tension of Adoption I understand why people might look at new practices with skepticism. The enthusiastic adoption of a new practice by one group creates tension with others who do not adopt the practice. The adopters can make the non-adopters feel slighted and invalidated; as if everything they had ever done in the past was wrong. The adopters, in their enthusiasm, may claim that adoption is a new requirement of professionalism. The non-adopters may claim that the adopters are fanatics who are detached from reality and ignorant of the past.

Certainly this happened with sterile procedure in medicine. The adopters were derided and dismissed by the medical establishment for sixty years before the adopters eventually outnumbered the non-adopters. Doctors at the time did not like to think that they were causing disease by failing to wash their hands. They also expressed their concern about the time such washing procedures would require. Then, as now, doctors were busy people. Hand-washing rituals would reduce the number of patients that could be treated.

Double entry bookkeeping had an even more checkered history, being adopted, forgotten, re-adopted, decreed, and ignored, for three centuries. The fight to make that practice mainstream was long and difficult.

Nowadays these practices are ingrained in the cultures of medicine and accounting. It is hard to imagine a doctor who fails to scrub before surgery, or an accountant who uses single-entry bookkeeping for corporate accounts.

The new practices won out over the old ones because the population of those who did not wish to change their practices gradually declined while the population of those who were enthusiastic about the new practices grew. The new practices expressed a shift in the values of the cultures that adopted them. Those practices cannot nowadays be separated from those shifted cultures.

###The True Corruption of Agile The biggest problem I have seen within the Agile movement is the elimination of the practices. One by one, over the years, the practices have been de-emphasized, or even stripped away. This loss of practice has diluted and changed the Agile culture into something that I don’t recognize as Agile any more. It has been a shift away from excellence towards mediocrity, away from hard realities, towards feel-good platitudes.

It began with the notion that anyone could become a “master” of anything by sitting in a two day class and getting a piece of paper. Soon to follow was the dilution and eventual loss of the technical practices. This prompted Martin Fowler to publish his classic and definitive blog: Flaccid Scrum. Then came the emphasis of project management over craftsmanship and the rise of the soft skills (attitudes) over the hard skills (practices).

At that 2001 meeting in Snowbird where we wrote the Agile Manifesto, Kent Beck stated one of our goals: “..to heal the divide between development and business.” Unfortunately the deemphasis of practices within the Agile movement has only served to widen that divide. While project managers have flocked into the Agile movement, developers have fled out of it. The original movement has fractured into two movements. The Software Craftsmanship movement has preserved the coupling between practice and culture; whereas the Agile movement has shifted away from it.

So, to my mind, the true corruption of Agile is Holub’s statement:

“…agile is a culture, not a set of practices…”

No. Agile is a culture expressed through a set of practices.

Are those practices set in stone? Are the original 13 practices of XP the holy writ? Are you an apostate if you don’t practice TDD? Of course not. But if you don’t use those particular practices, you’d better use some that are as good or better. And the practices you use will define your culture and be an expression of your values.

If your values are those of the Agile Manifesto, then your practices will likely look a lot like those original 13; because to a large degree it was those 13 practices that drove us to write that manifesto.

If you’ve got better practices, I’d love to see them. If I believe they are better, I’ll adopt them in a heartbeat. Because, under no circumstances, will I become the doctor who gets in the way of hand-washing.

• [1] If your political correctness alarm just started to ring, you can shut if off. Yes, I’m profiling. I’m profiling because cultures define profiles. If a culture did not define stereotypes and profiles it would not be a culture. There is no such thing as a culture without profiles.