Big-Agile Is The New RUP

Some of you who follow Joel, even if only to comment that he's largely irrelevant these days, might have found this coming a bit out of the blue. Why would he make a blog post just to have a partial transcript of one of the StackOverflow podcasts?

And then I found this beauty. Wow.

Turns out the transcript on Joel was specifically because he believed that the Big Agile guys were (intentionally or deliberately) misquoting him. Some really exceptional bits from the article and comments:

Joel said that the SOLID principle aren’t “agile”. (sigh). Everybody and his uncle thinks he knows what the term “agile” means. But I’m the guy who called the meeting where the name “agile” was picked. I’ve been writing about Agile development since the term Agile development was created. I think I know what is Agile and what isn’t. And I think I have the authority to override Joel on this one. Joel, the SOLID principles are agile.

Wow. Appeal to Authority much? Oh, wait, then someone calls him out on it. Here's Uncle Bob's response:

“But I’m the guy who called the meeting where the name “agile” was picked.” Appeal to Authority is a fallacy.

Not in this case, since I am one of the authors.

Wow. It's as though he actually doesn't understand what "Appeal to Authority" actually means. He seems to quite legitimately believe that since he was one of the original people who coined the term "Agile" he can define precisely what that means for the end of time.

Let's look back at my original purity vs. pragmatism post. Now let's look at the comments on Uncle Bob's post. Remind you of anyone?

Agile Is The Anti-RUP
The original motivation of Agile Methodologies was to get away from the RUP and other similar staged-delivery software engineering/delivery methodologies. The RUP is a big, rigid waterfall model that pretty much guarantees that your project is going to be a late failure. Each step is rigorously enforced, and you can't move from one step to the other until you've completed all the requirements. Furthermore, all the outputs are rigorously defined so, for example, you must have UML Class Diagrams (and no other type of diagrams) before you can commence coding.

However, even though anyone these days could look at the RUP and instantly see that it had to be a great big failure, nobody had a Name for what all the effective techniques that weren't in the RUP (or were completely diametrically opposed to the RUP) were. So when people who are extremely respected started saying, "Hey, you can be more successful by ignoring the RUP and doing it this other way" people loved hearing that. People gave these new Agile Methodologies a try, and even bought into the ones that were packaged as a cohesive, brand-name entity (because the only way to compete with a single-named overarching methodology is with another one: RUP vs. BSDM, XP, Scrum).

The best part was that "agile" was just a set of generic techniques that you could pick and choose from and still get some credibility. You could easily define what you do to someone by saying "yeah, we're big on CI and unit testing, do 4 week spikes, and have 2 people sitting on the business desk" and someone would understand what you're doing, and say, "hey, that's pretty agile."

Big-Agile Is The New RUP
Nowadays, that's not true. Let's look at some of the problems I see with the Big-Agile community:

Arguments From Authority. I'm sickened by someone saying "I alone have the right to decide what is Agile and what is not Agile because I am The Authority." No, no you don't.

Argument from Authority only works with factual statements: "I was in the room when Martin Fowler's head exploded, therefore I am an authority on whether Martin Fowler's head exploded in that room." It doesn't work for an argument of opinion.

You definitely get some kudos for being in the Agile world for that long, being a generically smart guy and by really helping the community grow. But that doesn't give you a trump card you can just unzip and slap on the table.

Simple Becoming Rigorous. Let's take a very simple concept: write tests before you write the code. Sounds pretty simple, right? Apparently not. Apparently saying TDD means a whole lot of very particular things that if you don't like TDD, you apparently aren't doing. Go back to the Uncle Bob post. Look at the comments. They're conflating concepts (Uncle Bob conflating TDD with having a rigorous testing policy), and not responding when someone makes the most valid criticism of all:

If TDD and SOLID is too obscure that regular-intelligent people don’t get it, then the problem is with TDD and SOLID, not with the regular-intelligent people.

You see this as well with all the people who essentially say, "If you're not using BDSM/Scrum/XP, you can't be Agile."

You're Doing It Wrong. This is pretty similar to Simple Becoming Rigorous, but the basic concept comes back to all the old, original XP arguments: If XP Doesn't Work, It's Because You Did It Wrong. XP will always work by definition, therefore if it didn't work, you failed to do it correctly. Tautology. But you see this all the time whenever someone says "Yeah, I tried Agile Technique X, and it didn't work very well for me/my team," and the response is "that's because you didn't do it right." It's condescending, and it assumes that all developers are exactly the same, and all projects are exactly the same as the project that you've just been on.

Agile techniques are supposed to be so simple that you can't do them so wrong that they don't benefit you. TDD? As simple as "write tests before code." Standup meetings? As simple as "ensure meetings are short by not allowing people to sit down." How do you get those wrong?

One Right Answer.  You tried a particular little-agile technique that you don't like or that doesn't work for you? Obviously you're wrong. That technique is perfect and must be applied in all cases. It never doesn't apply.

Comment The First: "maintaining a system that wasn’t written with SOLID in mind is the opposite of enjoyable." Really? You can't handle working with any system that wasn't developed with your personal architectural concept in mind? They're all rubbish? Each and every one of them? I don't know what SOLID is except for what Joel said. Honestly, at this point, I don't care. If it will warp me and my systems so much that I will never be able to look without hostility at anybody who doesn't use it, it's a virus, and I choose not to be infected.

Comment The Second: "I have never met anyone that has honestly given it a fair trail (20 days or so) and not become addicted for life." Note the use of the term "honestly" to conjoin this with You're Doing It Wrong.

Here's someone who really seems to get it:

Some zealots are giving ahering strictly to dogmatic methodologies (not necesarily SOLID) a higher priority than delivering software and satisfying customers. If your code is incredibly clean, but doesn’t meet the user’s needs, it is useless. Of course, ideally, principles and methodolgies are used pragmatically in delivering software that does meet customer’s needs but I have seen developers forget the objective of the system they were working while obsessing on the details of the implementation.

At the end of the day, nobody cares how high your code coverage is, or how many interfaces your system has, or what mocking framework you use, or anything else. They only care about one thing: are you consistently delivering software of value?

Agile vs. Big-Agile: Game On
I fully expect the Big-Agile crowd will probably find this completely insulting, and rely on all of the above arguments:

• He hates Scrum because he only has a passing familiarity with it
• He doesn't purely rely on TDD because he honestly hasn't given it a fair trial
• He doesn't like Pair Programming because he never did it correctly
• His experience writing use cases down doesn't count because he didn't use the correct size of note cards and didn't use the correct pen colors

At this point, I don't care. Let me put a stake in the ground.

Big-Agile Zealots Are Killing The Name Of Agile Methodologies

I've interviewed with a lot of firms recently, and I actually have to completely qualify the fact that I believe in little-agile methodologies, because at this point, they see the word "Agile" on a CV, and they think that you're TI from the Purity vs. Pragmatism article. It turns them off, because you guys are viewed as ranting zealots.

And you know what, when I then explain what I find works well in the real world with the types of people I tend to work with, they do the same thing and like it. They like agile methodologies, they don't like Agile Methodologies. They just find the Big-Agile crowd all completely unbearable to listen to at this point.

So with that in mind, unless we can get the "little-a-agile" terminology spread, we're going to have to part company, so that Big-Agile can own the now tainted "Agile" terminology, and those of us who are far more pragmatic can have our own word to play with that you can't try to authority-away our rights to self define.