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.