The death of agile has been discussed for years now, with a quick Google search showing countless articles saying that agile had died, was dying, or will die. Happily, or sadly for those dreaming of its brutal demise, it has continued with an increasing number of organizations adopting it or saying they are adopting it. A recent survey by HP showed that 67% of organizations either lean towards agile or are purely agile (51% leaning towards, 16% pure), even increasing to 91% if you include hybrid models. Viewing various surveys from Forrester, HP and the like over the past few years shows that Agile is gaining in popularity not decreasing.

Then why might we be hearing talk of its death? Well, I believe it fundamentally comes down to a distortion of expectations for what Agile is supposed to do versus what it actually can do. Can agile deliver software faster, for less money, and higher quality? The answer is perhaps in the short-term, however even if you’re in a Disney fairy tale over the long term you should not expect lower budgets, but rather more value.

With small teams it is possible to experience short term bumps where things are cheaper, faster, and of higher quality (if properly implemented), but this bump will inevitably be short lived if you work within a large or growing organization with more than a few agile teams. Beyond which the overhead benefits that you gain from the decreased oversight are substituted by needing full-time business insight, coordination, and guidance between many teams. Over the long term, agile saves organizations money by reducing failure rates not by simply needing fewer people (as is sometimes the hope).

The expectations for agile are often that it is some magic bullet for organizations with consistently late or over budget projects—it’s not.

It’s Not Simple

Often times it seems that organizations pick and choose the parts of agile that give management more insight and potentially more control while taking autonomy away from developers. That is not agile, that is authoritarianism.

I recently read a blog post from a developer by the name of Giles Bowkett where he described his experience of story poker which I believe is all too common:

“Literally always, as soon as every engineer has put up a particular number, a different, informal game begins. If it had a name, this informal game would be called something like “the person with the highest status tells everybody else what the number is going to be.” If you’re lucky, you get a variant called “the person with the highest status on the dev team tells everybody else what the number is going to be,” but that’s as good as it gets.”

When you implement agile in a way where power becomes concentrated in the hands of the few rather than dispersed through collaboration you will inevitably experience abuse. In this scenario story points should have been negotiated, there should be lively discussion if there is dispute and eventually trust developing to the point where no one person is afraid of disagreeing with the “high status” individual.

What Can We Expect from Agile?

We can expect more collaboration (if done properly), more self-organization (if empowered), and more insight into projects through rapid delivery of features. I believe in the best case scenario what we are currently experiencing is the brutal organizational change process with companies going “agile” and experiencing the pain that is involved. In the worst case scenario, we will eventually come full circle back to the traditional waterfall projects, it will take courage from the people in those scrum teams and those in top management to ensure that we don’t simply have an agile façade.