Why Does Agile Fail?

Why Does Agile Fail?

It’s still not fashionable to talk about Agile failure. I guess those few of us who do win few friends by it.

Never mind. My motivations stem from trying to make the world of work – of knowledge work – a better place for the millions who suffer the consequences of ineffective organisations, day in, day out. I don’t expect much thanks for it, but there it is. Take it or leave it.

I’ve given up using deontological moral and ethical arguments in favour of utilitarian ones. Not that I expect any form of argument – be that rational or emotional – to have much effect. Normative (experiential) learning seems like the best – nay, the only – game in town these days.

Definition

For the sake of clarity, let’s define what I mean by “failure”. Failure, here, is simply the failure to realise the desired or expected results from adopting an Agile approach to e.g software development. People generally know – although not always explicitly – what outcomes or results they’re looking for.

Some Reasons

So, why does Agile fail? And fail it does, in at least 75% of cases. Maybe as high as 95% of cases. Reliable numbers are hard to come by. Especially with so many vested interests in the mix.

  • By design.
    As a local optimisation – because Agile was conceived as such – even when the Agile adoption “succeeds”, it only addresses some 10% of the problems with software development. The 10% the development team can fix themselves. Some 90% of the problems remain inaccessible to the team. Only when the wider organisation gets involved can those other 90% receive some attention. And without this wider attention, the rest of the organisation will assume Agile has failed. It’s a matter of expectations, really.
  • By mindset.
    Bringing a classical, command-and-control, analytic mindset to a software development effort is like bringing a knife to a gunfight. Without a collective mindset bent on enabling learning, discovery, innovation, self-organisation and cognitive function, results will remain poor irrespective of practices.
  • By time.
    Even when an Agile adoption succeeds, and even when the other 90% of the problems outside the development team get attended to, it’s likely that the solutions are not long for this world. Unless the question of Organisational Cognitive Dissonance is also addressed – whether by luck or intention – any short-term gains are hostage to the vicissitudes of fortune.
  • By cargo-culting.
    Many Agile adoptions consist of little more than adoption of a set of practices. Agile “by the book”. With little or no inspection and adaption, or understanding of the underlying principles. This can often happen when e.g. management see Agile as just another “software development method”.
  • By naivety.
    Software development is not a simple endeavour. Control and predictability are not possible, however much we might naively wish for them. Or believe we need them. Software development is about the dance between organising intent and countervailing entropy. Attempting to run a software development effort like it was easy or simple or manageable is simply asking for failure.
  • By mistaking the nature of the work.
    Software development is a kind of collaborative knowledge work. Mistaking it for something else – for administrative, repetitive or manual work – is another shortcut to the failure farm.
  • By bad luck.
    So many random factors can impact an Agile adoption. Let’s acknowledge that even when all our ducks are lined up, often things can just go awry. Sponsors and champions can change post or leave. Key players in the delivery teams can quit. Upturns and downturns in the organisation’s markets can distract and detract. Technologies can suddenly change. Regulatory constraints shift. New fads can overtake our plans.

Honestly, so many things can undermine an Agile adoption, it’s a surprise to me that any attempts actually succeed. And it’s not even that a successful Agile adoption means a big uplift in organisational effectiveness. Better to invest our limited time, attention, and money in something with a much bigger potential payback, if you ask me. Which you probably didn’t.

– Bob

Further Reading

When Does Agile Fail? ~ Craig Strong
Why Agile Has Failed  ~ Mike Hadlow

3 comments
  1. Jim Hazen said:

    “It’s a matter of expectations”, and that says it all. People think just because they are “doing” something that will solve the problems. They at times create new problems and have to be recognized, and then dealt with.

    Any type of “process” model, and Agile and its many variations are a process, needs to have “buy-in” by ALL involved. Otherwise it gets lip service and will eventually implode. The whole team has to believe in and support the process, even it means that people come before process. Agile doesn’t mean completely throw process out the window, it means to be smart about it and do things that make sense. Even if that means breaking the rules time to time. It is all about conscious decision making, and trying to take things in logical & manageable bites.

    Otherwise the expectation is that Agile will magically fix all the projects woes and things will happen as everyone wants it to.

  2. Paul Beckford said:

    Hi Bob,

    Kudos to you for coming out and using the “F” word. You’ve even defined what you mean by failure, well done 🙂 Using your definition, I think your 75-95% failure rate is about right BTW.

    What you didn’t do is define what you mean by Agile. I’m guessing you meant the noun, not the adjective. The brand name of a management theory which as now reached the late majority.

    Agile the noun is something different from Agile the adjective of course, as can clearly be seen by the dictionary definition of the word Agile:

    adjective
    1.
    quick and well-coordinated in movement; lithe:
    an agile leap.
    2.
    active; lively:
    an agile person.
    3.
    marked by an ability to think quickly; mentally acute or aware:
    She’s 95 and still very agile.”

    http://dictionary.reference.com/browse/agile

    The adjective is about what people do, rather then what they say they do (espouse) 🙂 In contrast Agile the noun is a grammatically awkward made up name given to a management theory, that has been touted by management consultants and suppliers over the last 10 years or so.

    The rise and fall of successive management theories over the last 50 years is well documented, and Agile (the noun) is playing out a well rehearsed cycle 🙂

    Interestingly this post is part of that cycle. At the tail end of the fad cycle, the once exulted management theory begins to attract negative press as the late majority fail to realise the benefits promised.

    The reason why Agile the noun is failing is because it is yet another Management Fad:

    http://www.researchgate.net/publication/4885139_How_to_detect_a_management_fad–and_distinguish_it_from_a_classic/links/0046352961ad50fe23000000

    Nothing to do with Agile the adjective and the collective insight of a group of able and respected practitioners. Everything to do with our prevailing management culture and its perennial search for a quick fix 🙂

    Paul.

Leave a comment