BT

Reflections on the Growth of Agile

| by Kurt Christensen Follow 0 Followers on Dec 19, 2006. Estimated reading time: 3 minutes |

There is currently a vigorous debate happening in the software development community about whether or not agile development methodologies are being corrupted as they gain in visibility and popularity. On one end of the spectrum is Google employee Steve Yegge. Steve had previously written about the distinction between "good agile" and "bad agile," but Steve recently wrote a piece in which he ceases to even pretend to have any respect for Agile or its practitioners:

So, you know, just send all your disposable income to an Agile Consultant near you. Any one of them will do just fine. They all say the same thing: "You don't quiiiiiite get it yet. Cha-ching!"

Previous criticisms of Agile by Steve Yegge and Joel Spolsky have been discussed previously on InfoQ, and such criticisms aren't new. What is new is the extent to which the agile community itself is questioning the current direction of Agile. Martin Fowler recently wrote about the semantic diffusion of the word "agile":

Semantic diffusion occurs when you have a word that is coined by a person or group, often with a pretty good definition, but then gets spread through the wider community in a way that weakens that definition. This weakening risks losing the definition entirely - and with it any usefulness to the term... Semantic diffusion is a painful process to watch, particularly for those who find the ideas useful. At the moment I see signs of despair for [the term "agile"], some people in the agile world are talking of ditching the word agile.
Somewhere in the middle of the spectrum is Matt Heusser, who asks in a series of blog entries whether or not agile has "jumped the shark":  
The problem is that by saying "Embrace Change", we are also saying "Get over your fear of loss of control", and there are a whole lot of people in this world who don't want to. They want to be told that they can have their pie and eat it too. And they have titles like VP of Development, CIO, CEO, or CTO... This means there is a market, with money, who want to be told how they can have all this agile stuff and also have CMMI, or Architecture, or Portfolio Management, Long Range Planning, or a Crystal Ball... So we get Agile RUP and Agile CMMI and Agile Portfolio Management, Agile Issue Tracking and Resolution, Agile Systems Architecture, and get slowly pulled back into the world we were trying to escape from... The tent is too big and we've given credence to ideas and concepts that we should not have, to the point that it is very hard to tell "good Agile" from a bunch of consultants that can't ship software but know the right buzzwords.

To drive home the point, Matt quotes a prescient Bob Martin from three years ago:

The word "agile" will become meaningless. It will be hijacked by loads of marketers and consultants to mean whatever they want it to mean. It will be used in company names, and product names, and project names, and any other name in order to lend credibility to that name. In the end it will mean as much as Structured, Modular, or Object.

Elisabeth Hendrickson offers a more hopeful summary in her piece titled "Inside the Secret Fears of Agilists":

It is possible that somewhere along the line, the word “Agile” will lose all meaning.  But if that happens it won’t be the end of Agile.  It will just be the end of a buzzword.  The Agile community may eventually decide to come up with a new, more meaningful label around which we can gather.  Or not.  Either way, Agility by any other name would retain the same balance of discipline and flexibility, and that’s the truly important thing.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Good riddance by Bruce Rennie

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!

Failing to see the big picture by Mikael Berglund

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

Re: Failing to see the big picture by Kurt Christensen

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.
I wonder how happy Steve would be if he was having his house remodeled, and when he asked the contractor for an estimate, was told that you can't predict the delivery of quality.

Re: Failing to see the big picture by Bruce Rennie

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?

Is there something we can do about it? by Juan Bernabo

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.

Agile leaders - please fix this crap. by Marc Stock

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.

Re: Agile leaders - please fix this crap. by Paul Oldfield

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.

If there's one common misconception about Agile, it is that being Agile is an end in itself. People have this same misconception about money, and to a greater degree.

What we really want is to deliver value to our customers, efficiently and in a changing environment. Agility helps us to do this, much as money helps us to get what we want, when we want it.

You may look at this and say, right, that means Agile is a good thing to have, same as money is a good thing to have. True. You can't eat money, it's wasteful to burn it to keep warm, it's not very good at keeping the rain off. What it is is a flexible way to get each of these good things that you really need.

Like the pursuit of money, the pursuit of Agile can lead us to lose focus on what it is we really want. Like money, there are many folk out there trying to get us to give them money in order to get more of it for ourselves. Like money, some of these folk may be genuine, many will not. Like money, this is only happening because there's some real benefit in having it.

Errm... where was I going with this? Oh yeah. The important thing is to keep sight of your real goals. Re-launching Agile under another name won't help; if it's any good the same things will happen again. And if taking Agile advice, ensure the supplier can explain clearly and in realistic terms how you will get from where you are to where you want to be. An explanation may take some time, but if your advisor is any good he will be able to do this. If he can't, he's no good.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss
BT