Feb 212012
Ed Sumerfield and Chris Nelson of Gaslight Sof...

Ed Sumerfield and Chris Nelson of Gaslight Software presenting "Why Agile Fails" (Photo credit: RubyNuby)

The other day, Travis (@tdietz) and I were talking about how, in the Kansas City market, there are several software outsourcing/staffing companies that claim to be agile. However, upon examination, one finds that they’re about as agile as an iceberg and with similar long-term effects. At the same time, these companies are not being disingenuous; they honestly believe they are “agile,” it’s just that agile to them denotes things that their company does that they consider to be agile.

“We don’t document anything! We’re agile!”

“We don’t have middle managers! We’re agile!”

“We work overtime to get the project done before deadline! We’re agile!”

“We have a well-defined change management process! We’re agile!”

Businesses, of course, have no real way of knowing if the company they choose to work with is actually agile or not, unless they just happen to have someone on staff who knows what’s up. Companies that latch on to this buzzword inevitably deliver an experience roughly the same as every other software company – bad. The business finds another “agile” company, and the same thing happens.

Eventually, being “agile” ceases to mean anything. It appears to businesses to deliver no qualitative difference, because software companies are basically doing what they’ve always done (although maybe real real fast) and calling it agile. This problem is pervasive in the Kansas City market, and it makes it a hard sell for the select few companies actually doing agile development, because it’s very hard to convince a business owner that the reason Agile Company X failed was because they weren’t doing it right.  Oh, and neither were Agile Companies Y or Z. But we’ll do it right. Trust us. Seventh time’s a charm, etc.

Compounding the problem is the mantra that being agile is about principles, not practices. This is 100% true, but the problem is that people assume “agile principles” covers every vague notion they have about improving efficiency. You might do Waterfall, but you limit the Requirements Phase to two weeks, maximum, so now you’re agile, because agile is about principles, not practices, and you just… you know… went faster.  This is also where you refer to the Agile Manifesto, which you have not read, because if you had, you would realize that there are some fairly specific ideas what does and does not count as a principle of agile development, and you’re not evaluating your practices by those principles.

“Principles” becomes a blanket that you pull and stretch, trying to cover all sorts of practices. This article in Forbes demonstrates that you can call just about any company agile if you play with your semantics enough and have no real concept of what you’re evaluating against.

It has been suggested more than once at my company that perhaps the term “agile” has outlived its usefulness in distinguishing our company, and I have often argued that it is still useful. I don’t know, though; I think I might be ready to wave the white flag and just come up with some other term.

I’m thinking: Punctual.

  8 Responses to “Agile Means Nothing”

  1. Thank you. After spending the past several years studying agile ‘principles’ and methodology, working with companies to help them adopt these methodologies, and then seeing how similar the “right blend” is for those companies, I’ve come to the conclusion, as you have, that agile is a less-meaningful word. In reality, EVERY software development methodology worth using is somewhere along the continuum of methodologies between the hardest/strictest waterfall on the one end, and the most “agile”/free-form/collaborative development on the other end. Perhaps the word “Planned” is more what we are looking for? 😉

  2. Dave,

    I have said for years that Agile makes the customer happy about what they are not getting. The Agile practices are referred to as principles, therefore giving it the quaint perfume of religion – believe or else. Rubbish. Every Agile exercise I have witnessed, or heard of, has had a hard delivery date towards which the iterative Agile Death March is whipped. The upside is that everybody gets their daily dose of adrenline. The only way Agile works is if everyone involved is a SME and the end state vision for the project is grasped by all from the beginning – meaning it’s a relatively small project. Otherwise, it is doomed; you have rolled the bones and your fate is a bowl of maggots. Quality is treated like a four letter word and Risk actually is, but both are addressed with a yawn and a whatever. I actually heard an Agile advocate say, “the code is self-documenting.” => Personally, I always feel better about myself when I have someone to pity. That was the mantra about COBOL in the 70s! Learning is so boorish…

    – Myron

    • My name’s Phil, actually, but other than that, I’m sympathetic to your experiences, and that’s why I tend to get frustrated.

      For me, being agile boils down to some basic principles (i.e. Agile Manifesto stuff), and practices can be evaluated against that. Some practices support those principles better than others. But whatever practices you want to implement, they have to be implementable.

      I see a lot of badly implemented agile way more often than I see decently implemented agile. On the other hand, the market seems flooded with self-proclaimed agile experts. So, how does this happen? How can you have so many “experts” on the one hand, and so much sucking on the other?

      I realize my experiences are just my experiences, but I can’t help but think a lot of these companies and individuals proclaiming themselves to be “agile” are pretty much just as lost as everyone else.

  3. […] he really ought not to be the flagship representative of it.  I have mentioned this in passing, before, using his example of calling Apple an “agile” […]

  4. How would you feel about a company to build your house in an agile way, if you were living in an earthquake zone? Just give you a table and no roof nor bed for a few month and when the roof arrives, maybe fall on you, because there were no walls?

    How would you feel about crossing a bridge built in agile fashion.
    How about eating food cooked in agile methodology? Cooking the crust first, then maybe same salt but we give it to you to taste it without salt? You see, we tested the crust first, you should be happy without salt for a few sprints. If you wanted with salt, we would give you only salt for a while.

    Any programmer knows that agile is a joke. It is there just for the bosses to put programmers work 14-16 hours a day.

    • Ok, I don’t laugh out loud very often, but I made an exception here. Agile is a joke. Yes, none of my teams for the past eight years have developed any software. My life and the lives of many of my colleagues have been an elaborate illusion. Kind of like Fight Club.

      The reason your analogies don’t match what really happens is because you used deterministic processes for your examples. It would be like if I said, “How would you like someone to perform CPR according to Waterfall? First, you comprehensively document what has to happen in the CPR process and sign off on it. Then, when all the stakeholders have signed off on what needs to happen, then you need to document everything you’re going to do to achieve that outcome and get sign off on it. You also need to predict how long each phase is going to take. When you’ve got that done, then you can start implementing. You’d be dead.”

      You would rightly reply, “Well, software development isn’t much like giving CPR.” Software development isn’t much like building a house or eating a pie, either. The fact is, unlike pies or houses, software is highly mutable, easily changeable, and can bring value without every feature being complete. As systems can be decoupled, they can be deliverable iteratively. I can drive my car without the stereo being done, because the stereo is decoupled from the engine. This is how software development works.

      “Any programmer knows agile is a joke.” Hilarious. Bad programmers think agile is a joke because their code is deterministic and tightly coupled, and are much more like houses and pie in that respect.

      • Pledgerwood,
        The CPR example you give shows you have no clue about what the waterfall or what a methodology is and how to use it. This is the worst use of the waterfall and wrong use of a methodology. This is just a caricature of the reality.
        But this is what Agilists like to spread around to justify their religion Agile.
        Reading Agile stuff, over and over again I observe, that Agilists do not understand the real software development endeavour. They are like teenagers who dump thing, just because they find it annoying or don’t see the value of it. They just don’t understand the real nature of the endeavour and don’t understand the causes of the problems they cite. Critical thinking is far away.

        • Since you didn’t make any actual arguments, I’m not sure how to respond.

          You have to understand that it’s a little hard to take this seriously when I’ve helped several organizations now transition from phased-gate approaches to agile and lean approaches and have empirical, metrical evidence of their improvement. If I don’t understand how software development works, why are they improving? Am I just lucky? Are they improving in spite of my lack of understanding and, if so, why weren’t they improving before?

          Do you have empirical metrical results showing how you improved an organization’s software delivery by replacing their agile methodologies with Waterfall? If not, how do you know Waterfall is superior?

          And what is the “real software development endeavor” that people like Ron Jeffries and the other Agile Manifesto signatories don’t understand, but you do?

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>