Agile, “Corrupted” and Proud

Posted by Leo Soto on March 31st, 2014.

Bob Martin defends the coupling between culture and practices in his latest blog post. According to him:

“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.

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

That reasoning is too narrow. While it’s true that practices are probably the most visible expression of a culture, what matters most to me are values (or, if you prefer to call them so, beliefs).

Think about how some movements/cultures make themselves irrelevant by focusing just on practices. Catholicism, at least in this part of the world, focused too much in attending to mass and commiting some prayers to memory and too little on the value and meaning of being catholic (of course it’s not the only religion guilty of that, but I use them as example because the catholic church was the undisputed dominant religion in most of Latin America not too long ago and it’s in constant decline).

Think on the myriad of companies that froze themselves in a particular way by focusing on practices instead of their own values and culture. Microsoft and their stack ranking practice come quickly to my mind as one of such examples.

It’s not just a one-way street, just practices being the expression of cultures. Extreme adherence of practices by individuals can destroy (perhaps a better word would be dilute) a culture.

How I came to the agile world

I became interested in agile because their values aligned well with my own values and my experience working with open source projects. I had seen how you can make high quality software without all that waterfall crap. I had seen (for example) how a couple of (losely) coordinated individuals can beat a comitee with process, direction, whatever.

Perhaps the only principle of agile that’s not obvious in Open Source is “Customer collaboration over contract negotiation” but you can make a case that the way IBM, Google, Red Hat, and any company can become a customer of open source is to collaborate with it.

Note that there is very little in common between agile practices and open source practices beyond (in some cases) automated testing and (in less cases) continuous integration.

I gave TDD, Pair Programming, Continuous Integration, Frequent ”Standup” Meetings, and all those techniques a chance because they came from people with shared values.

As an individual, I still practice most of them. Some of them some of the time, others most of the time, others rarely.

Note the indefinite — the relativity — reflected on the above sentence. That’s not, in my opinion, a bug. It’s a feature. Run away from people preaching absolute truths! (including this one)

What I can observe in the team where I work is the same story — we value the freedom to adapt our practices on a case by case, project by project basis. Of course we don’t randomly change the way we work. But we change it, we test new ways, we experiment, we fail, we succeed, we try again, we explore. No process is sacred and we like it this way.

Bob seems to think otherwise:

“[…] 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”

That’s flawed logic. I have seen people with different values using gantt charts, PERT estimation and other project management practices, just because they were taught to use such practices as the standard. The same can happen (is happening?) with agile practices.

Ritualism is a problem

Bob says:

“[…] 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.”

While I’m not at all convinced about the supposed distinction between enthusiasm and ritualism, I’ll focus on arguing another point: The so-called status quo is not a global property of the entire universe. It’s easy to set-up micro cultures where their status quo is different than the status quo of the others.

I actually worked in an environment in which agile practices were the status quo. And it felt both enthusiastic and ritualistic (but just ritualistic in Bob’s view of the world). A friend got to the point of testifying as a expert witness in a judicial case that not adopting certain Agile practices was unprofessional.

Speaking of what:

”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.”

True. But think on why people had to make a point about how good software can be made without TDD.

I have done it only as a counter to the enthusiastic/ritualistic people making the absurd point that you can’t make good software without professional-best-uber-agile-practice (such as my expert witness friend) and I suspect the same is happening here.

Corruption

Bob finally goes for the heretics:

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.

Perhaps such practices can change and (due to the complexity of software development) are not universal? He partially agrees with the first part:

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.

Unfortunately he seems to believe in more or less universally good/better practices. Sometimes I have no idea if some stuff we try at Continuum are aplicable to our next project/client — I could hardly know if they are generalizable even further.

And anyways, how would you know if a practice can be as good or better without — horror! — “corrupting” yourself and deviating from the “original” practices and try something else (thus believing that agile is really about the culture/values/principles/beliefs rather than such original practices)?

Therefore, I declare myself a deeply corrupted agilist. And I’m proud of it.

Originally published at techblog.leosoto.com on March 31, 2014.