Why Agile Adoption Fails So Often

Agile is not what you do. Agility is how you do it – Dave Thomas

Agile devotees tend to insist that agile is the cure to all of your problems. When you have seen it fail, as it often does in execution and adoption, that battle cry becomes real annoying, real fast.

Have a look at this thread and you’ll find yourself nodding your head in agreement with most of the answers to the question,“In a nutshell, why do a lot of developers dislike agile?”

• I can’t tell you the number of managers I’ve seen that couldn’t manage their way out of a box — and adopt Agile as a way to wave their hands and talk a lot to distract people from noticing.
• Agile doesn’t account for the career needs of engineers at all, and that’s something that a good manager has to keep in mind when allocating work. Nor does it give engineers the ability to define or direct their own work in a meaningful way, and this repels senior talent and causes the Dead Sea Effect (most successful talent leaves most often) to set in.
• Agile is mostly micromanagement, just sold in a way that clueless young engineers might think of it as a good thing.

Notice a common theme? The concepts of the manifesto for agile software development are not the problem. The adoption and implementation of those concepts, however, is a major pain point.

Why does agile adoption fail so often? Why is there so much pushback? Because there is a fundamental misunderstanding of what “agile” actually is.

This is perfectly encapsulated in a talk given at a conference in Amsterdam from 2015, called Agile is Dead, from one of the creators of the manifesto, Dave Thomas.

It’s 40 minutes, and it’s absolutely worth your time. TL;DR:

Instead of a mindset and a way to better develop software, over time, agile software development became Agile™ – a set of rules to follow in order to ‘do Agile’ correctly.

According to Mr. Thomas, in order to be agile you need to do the following:

• Find out where you are
• Take a small step towards your goal
• Adjust your understanding based on what you learned
• Repeat

Those four notions above point to changes that must happen at the macro level of a business.

Conversely, Agile™ has left us with a bunch of different methods (scrum, lean, scrumban), terms (velocity, epics, backlogs) and roles (Scrum Master, product manager, etc) that are often cherry-picked and then presented to teams and individuals as the ‘right way of creating software’.

These are not bad things! But they are micro-level changes.

And when they are cherry-picked and presented as the silver bullet to solving quality and deliverability issues, the problems begin to appear. Adoption failure usually isn’t far behind.

True agile adoption means changing the way you think about your company culture, how you do business, how you deal with employees and clients and, yes, how you develop software.

Taking Agile™ and then expecting it to solve all the issues at your company is a recipe for failure.

If you want to take on those issues at your company, you need an entire mindset change, which is, at it’s core, what agile development is all about.

Want a truly agile development team to help bring your awesome idea to life?