I just finished reading Clean Agile, by the great and powerful Robert C. Martin (familiarly known in the software developer’s community as Uncle Bob).
At this moment, Uncle Bob’s brand seems to be almost glued to the word clean. To realize this, you just have to take a look at his last published works’ titles: Clean Code, Clean Coder, Clean Arquitecture…
I’m not sure if the fact that his new book, Clean Agile, has been called that way, is due to an imposition/strong recommendation coming from the book’s publishers/editors or, on the contrary, Uncle Bob truly believed the title Clean Agile was a good one. If this latter has been the case, it would be legit to tell Uncle Bob ‘when you say Clean Agile, are you suggesting that there is a kind of Agile that’s not clean? Is there such thing as a Dirty Agile?’
And, apparently, there is.
Dirty dancing
Let’s be honest: we all know Agile has become a buzzword. We have reached a point in which, from hearing so many times the word agile, it seems like people have been forced into this Agile thing, interested or not in practicing it correctly. And this always happens when a word gets famous or in fashion. I’ve heard the word agile coming out of the mouth of people whose behaviour is as agile as my dead grandmother in her grave, poor gramma. On the other hand, I know colleagues whose manners and code are so smooth that it’s difficult to believe them when they tell you that they don’t know who this Uncle Bob guy is: ‘Who is he, a football coach perhaps?’
I don’t know if I’m Agile or not. I guess not, because, I haven’t had the chance yet of working in a truly Agile way. I suppose I am an Agile-wanna-be. I’ve read quite a few things about Agile, but I feel like a christian that, after reading the Bible, goes to church and thinks: ‘WTF is this?‘
In that regard, Agile is like any other buzzword: something you can wear just to impress the others; or something you can truly believe in and apply no matter how hard it is to do it.
At least in Spain, where I live and work at the moment, we have a long way ahead in this respect of being Agile. For instance, I feel that TDD (Test Driven Development) is still being seen as an esoteric practice. At least this is pretty obvious in Andalucía, where I have spent my five years of professional experience as a software developer. I’m not basing my opinion just on my relatively short experience: the thing is I haven’t met a single person here that practices TDD rigourously on a daily basis. Of course I hope there are people practicing it right now; anyway, the fact is that it’s far from being the done thing. And I think that is worrying and a pity. Because I think Agile, up to this moment, is simply the best way of becoming better at what we do as Software Developers. Because, yes, the Agile movement was founded by Software Developers. But not just for the sake of software developers but for a greater target, as Mr. Kent Beck put it years ago:
Agile’s (required) basics
I think the essence of Agile is in the conjunction of its four legs. Then it’s up to you how fast you can run on these four legs:
- Simple design
- Tests and TDD.
- Refactoring.
- Small iterations.
To be Agile or… to be something else
The important thing here is not if you’re Agile or not Agile. The point here is to call a spade a spade, to be able to become “Agiler” when you choose to be Agile. Because if you’re only 70% agile, you’re lacking the Agile metrics to analyze how to become better at what you are doing. Actually, can someone be % agile? I don’t think so: this looks more like a binary thing, man. Whether you are better or worse being Agile, that’s a different topic. But you can’t be pseudo-Agile: if you don’t walk at least on the four mentioned legs, your experience is not fully Agile. And if it’s not fully Agile, it’s not Agile, it’s just something else. It’s not the end of the world not being Agile. You don’t have to be Agile if you don’t want to. Let’s just call a spade a spade and don’t intoxicate the concept, pretending to be something it’s not.
Some like to state about Agile, that this position is an elitist and radical one, as if defending it is just a matter of sour purism. The point is simply that Agile has its own rules. Imagine hearing someone say:
Here, we like to play soccer
Then, after taking a look at the soccer pitch, you ask the first guy:
Then, why is that guy holding the ball with his hands in the middle of the pitch?
Imagine the other one comes up with this retort:
C'mon , man, don't be so radical and elitist! Let the guys have their fun!
You get the point: that’s not soccer. Period.
To call a spade a spade
I’m not saying a pseudoAgile thing (or pseudo-whatever, for that matter) can’t be useful or fun, though. It’s like with any pseudo-anything. It can end up being helpful sometimes; but, if anything goes wrong, the problem is that you can’t blame Agile, as you can’t blame the designer of a chair when it breaks if you didn’t follow the instructions to assemble it. What I’m saying is that Agile has an atomic essence. If you don’t respect the atomicity of its practices and rules, then you won’t have a way to measure your success (or lack of it) in an Agile way, and make the appropriate corrections.
MyClass implements PerfectWorld, Agile{}
Agile is like an Interface, and those four legs above are the methods you have to implement. How well you implement them is, indeed, debatable; however, you are obliged to implement at least those four methods to comply with the interface’s contract.
Fragile Agile
Parodying that great Ramones song, Pet Sematary, I would say:
I don't wanna to be buried in an Agile cemetery.
As I began this post talking about my admired Uncle Bob’s Clean Agile, I want to end it up as well, this time with a splendid post written by him, where he dissects this topic in his usual way: fun and illuminating. Click here to read it.