Reflections on the Growth of Agile

Excuse me, but isn't any methodology that rises about the sea of unnamed, custom processes nothing more than a large scale marketing campaign? Agile could have continued to grow without a manifesto, just not as fast. Wasn't that the point?

Why even "promote" a methodology at all if not to market it to people who haven't adopted it yet? I mean, I can happily practice agile in my own small way without uttering a word about it in public. But if I want to expand the potential pool of employers, peers, and colleagues, I need to market agile.

Yegge, whether he knows it or not, is part of that marketing campaign. I mean, who the hell is Steve Yegge that we should care what he thinks about agile? But we, as a community, decided that the agile "brand" requires defense against attack, lest we lose share. Sounds like marketing to me.

I'm not suggesting that agile enthusiasts could have done anything different. It's natural for humans to want to promote something they feel passionate about. But I can't help but feel we're simply victims of our own success. Congratulations, we've succeeded!

What Steve is describing can't really be applied to other companies and organizations. Google is an outlandish corporation completely different to others. Their project selection and development process isn't entirely transparent, but from what I can tell, it doesn't seem like any other since they don't have a paying customer with requirements and schedules.

What do we know then?

Since you are reading this, there is a great probability that you are paid by a customer. It can be an external organization, internal IT or your soccer club.

For 99% of you this is a fact, and this comment is directed at you. Yes, you.

Your job is to provide the best solutions for your customer. This is where XP and Steve fall short.

XP's business perspective is limited to the on-site customer. This is generally not feasible and not desirable. The domain experts at your customer probably have other things to do, like running a business or selling cars. What YOU need to do in this case is not limit yourself to forcing the customer to write small papers with user stories or guessing what they might want from you. You need to set up a working environment in which the customer can express their requirements in the best way possible. This might be Word documents or papyrus paper. Make sure they understand the different options and are able to choose what's best for them. Use a governing board? User representatives combined with business analysts? One customer on site is probably not going to cut it in most cases.

XP dictates sound engineering principles like iterative programming, TDD and frequent delivery. Is that all? Are we done there? Of course not. There is much more to do. In your professional toolbox you should have both good engineering practices and things that could be useful for your customer like business prototypes, usability testing and workshops.

This discussion does not stem from our raison d'etre and thus does not help us make better systems. We need to constantly revise our methods and processes in order to become more efficient. Having holy cows and not being able to hear criticism is not helping.

Regards,
Mikael

Your comments touch on something that I believe is very important, and is the piece that is most often missed by the anti-agile crowd: when we write code, someone, somewhere is signing a check. Steve Yegge wrote:

You can't predict the delivery or quality of great art... But prediction is what half the Agile folks claim to stand for. Ah, prediction. How we look to our psychics, our soothsayers, our bookies. Now, yesterday, tomorrow, forever. We all yearn for prediction. But when you fall for that crap, you've fallen, like a star from the sky.

Yes, I noticed that too in Yegge's comments.

Really, the picture he paints of the environment at Google seems a little, er, unreal (surreal?). Or am I jealous?

I remember 15 years ago when I was introduzed to OOAD, almost everbody was selling that as The Solution for all our software problems.

The hype went forth and back two or three times that I remember, high promisses, a lot of deceptions, but 15 years later, I can work on an C++, .Net or Java project and nobody looks to me strange for that, 15 years ago in countries like Argentina or Brasil I was a freak.

Certainly the great majority of average projects doesn´t use OO at its full potential, yet they say they use OO because it´s Java or C++ or .Net! Even they strugle mixing OO with structured programming, not to say that most mix OO modeling with Data modeling and use UML tools as a data modeling tools no abstraction, no inheritance, no nothing, just plain data structures.

Now because of Agile buzzword I meet a lot of people that had arrived to some of the hard learned lessons I learn in real life projects. Now we had some common values, I could learn more, some visibility was gain and is making my life a lot easier, people that would not be interested in learning or taking the pain of introduzing it to their organizations, now are doing it. This is great!

For some people i´m still a freak for not going the CMMI, PMI or rigid RUP implementations way when everybody else in this industry, at least in latin america, is going into that direction, or at least pretending they are going.

But in some years a lot of people will be strugling with agile methods, and agile merchandise, but I will not be a freak anymore.

As myself a lot of other agile practitioners will not be fougth by their beliefs, values and principles, even than the majority will not reap the benefits of it.

Agile word may go thru a semantic diffusion as OO went too, but is there something we can do about it?

The only thing I can think is just do your job as best as you can to aply what we already know and give concrete results, then show the facts.

A lot of people is in search of magic recipes for their software problems, with that never ending high demand some may start actually selling some Agile pills.

The term Agile has become completely meaningless. For it's detractors it's simply a nice label of "unrealistic drivel" that they can apply to a number of different practices that often aren't "agile" at all when you delve into them. For its fans, it's meaningless because a lot of Agilists can't agree on what exactly makes a project Agile. The term is simply too vague and is too liberally applied.

The leaders of agile methodologies need to take control and set clear definitions for what "agile" is. You know it's out of control when the premise of the argument changes because the people who are arguing can't even come to a conclusion of what is agile. It's become a joke, frankly. I'm a fan of the Agile movement but I cringe everytime I bring up the term in discussion with others in my industry. I have no idea what they think "agile" is and as a consultant, that's kinda dangerous.

And as much as I HATE the idea, I think there needs to be some certification process for methodologies that claim to be Agile and for people who claim to be coaches of the material. This should be set up NOT as a money making scheme like Scrum is, but as a legitimate system for managing claims. I honestly don't know how to do that. I just know it needs to be done. People like Schwaber who talk down to others, simply destroy reputation. It's no wonder that so many are coming to think of agilists as a bunch of elitist assholes. Consequently, certification needs to be revocable as well. Putting forth a new version of agile without such protections will likely result in a repeat performance. (To all the scum fans who just got their feathers ruffled...relax, I think Scrum is a good thing. It's the leader that's the problem.)

Finally, I think the name should be tossed as part of this whole drill and a new name created. The term "agile" has been forever scarred. One day, I think the term "agile" will be used as an adjective to refer to anything that is so vaguely defined as to be meaningless.

The term Agile has become completely meaningless. For it's detractors it's simply a nice label of "unrealistic drivel" that they can apply to a number of different practices that often aren't "agile" at all when you delve into them. For its fans, it's meaningless because a lot of Agilists can't agree on what exactly makes a project Agile. The term is simply too vague and is too liberally applied.