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.
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?
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.