Antagonism and Agile
Shortly after my last blog (The Agile Holocracy) hit the wire, "Uncle Bob" (Robert) Martin responded with a blog of his own that's definitely worth a read (The True Corruption of Agile). Though Bob thinks that he's rebutting my post, I find myself violently agreeing with many of (though not his main) points, so it seems like a little clarification is in order.
What I thought I said is that agile cannot succeed in the context of an antagonistic culture. Bob says that I implied that culture was paramount and practice irrelevant. It's that word "implied" that got him into trouble, I think. The usual answer to "we had an implicit agreement" is "I never agreed to that!"
Since Bob's post emphasizes practice, let's start there. Practices are important. I think that practices and culture go hand in hand, however, and that the former cannot succeed without the support of the latter. Bob's lament that people are abandoning well-understood practice frameworks does have merit, however. My guess is that he's worrying about the tendency of Scrum shops to throw away everything except short iterations and agile planning, and that's certainly a form of dysfunction.
I've said it before, but many Scrum shops have been trained to think that they're "doing agile" when they're doing Scrum, so they see no reason to look further than the 16-page Scrum Guide. You can't cover Agile in 16 pages, however, and the Guide is short on practice-related advice. In all fairness, I will say that the Scrum Guide doesn't prohibit you from adding the missing pieces, but many shops don't go there.
Unlike Bob, I don't pine for a golden age of the original 13 XP practices. The notions of agile have to apply to the process itself. Any cohesive set of practices that realize the Agile Manifesto and Principles are fine with me.
Nonetheless, designing your own practices from scratch is hard to do. The practices that compose the existing frameworks interlock in complex ways. Changes are difficult unless you really know what you're doing.
Take the much-maligned pair programming. Pair programming's benefits include automatic code reviews as a side effect of writing the code, mentorship, and making it easier to come up to speed on unfamiliar code. You can also learn a lot from your other half, so the practice helps diffuse knowledge throughout the team.
If you opt not to do pair programming, you need to find some other way to get those benefits. One company I worked with regularly had senior people review the code of junior people, with the reviewer/reviewee pairs changing all the time. That works. So does regular Friday-afternoon training sessions, occasional big-picture architectural discussions, and the like.
Problems arise when somebody who doesn't understand the interdependencies skips the pair programming without adding practices that give you the same benefits.
Bob also mentions the problem of "ritualism." Canned processes are often cargo cults. People follow the rituals, sometimes slavishly, without any understanding of what those rituals are supposed to accomplish. This approach works about as well as the cargo cultists building bamboo replicas of airplanes in the hopes that real airplanes would land.
So, what about culture? Returning to my main point from last time: No agile practice can succeed outside the context of an agile-friendly culture. Bob posits (and here we do disagree) that the practices themselves create that culture. As an example, he tells a story of his martial-arts Dojo. He says that bowing to the Dojo when entering or leaving the room instills a culture of respect amongst the students. He also cites as an example changes in medical practice that have led to cultural changes in the medical profession.
He sums up with a very true statement: "Cultures express their values through their practices."
But that statement seems to rebut the rest of his post. The culture has to come first (or at least coincidentally), otherwise how can it "express values?"
When practice comes first, it takes an awfully long time for the culture to change. Consider how long it took for doctors to stop bleeding people (at least in the literal sense). Similarly, simply introducing new practices in the engineering department just doesn't cut it. The agile philosophy never, in my experiences, filters upward. The antithetical-to-agile practices outside of engineering just don't change, and the engineers don't get the support they need for success. The good practices tend to wither on the vine.
It's possible that introducing new practices into the engineering department might change the culture of the engineering department. I don't think that that culture will be able to escape from engineering, however. The whole company has to be agile, not just the engineering department.
If an organization as a whole has a culture of overtime, however, it's very difficult to institute the practices surrounding continuous pace. People who try to work sane hours are usually fired (ironically, for not being "team" players). Similarly, a culture of mistrust as embodied by formal sign offs up the management chain, paternalistic performance reviews, and so on, fights against self-organizing teams. A quarterly planning culture prevents you from planing continuously, and drags you away from priority-based planning. Replacing a culture of individual fiefdoms (separate Product Development, UX, Dev, and QA organizations) with multi-functional teams is very difficult — startups do have an advantage, here — but it's necessary. Without that, you can't integrate testing into development, for example.
Most of the canned processes are designed to appeal to traditional phased-development mangers, because you can introduce them without disruptive cultural change. Without disruption, however, no agile process can reach its full potential. The canned processes are an easy sell, but as Bob points out, anybody who thinks that they're a "master" of anything after taking a two-day course is kidding themselves.
So, to summarize: Agile software development works because of the disciplined application of agile practice, but unless an agile culture infuses the organization, the odds of successfully implementing those practices are very small. The cultural changes have to precede (or at least coincide with) the introduction of new practices.