Most Agile Transformations Will Fail

The sad reality is that though well-intentioned, most agile transformations fail. By fail I mean they are canceled, reversed or fall short of delivering the desired results.
To be clear, agile transformation success is different than agile project success. Success rates for agile tend to be significantly higher than those for traditional approaches, and there are plenty of data points to support that. Unfortunately, a lot less data is available on agile transformation success.
I do find that the majority of attendees to my training classes belong to organizations that have attempted some type of transformation. Most of them report limited success, and in many cases, a complete reversal of the agile initiatives.
Agile transformations are major programs of change and represent risk. Read on to learn more about the top 10 reasons that agile transformations fail. And download this handy diagram outlining those 10 reasons:

#1 – Agile Transformations Fail Because They Take Too Long

The primary reason that I believe agile transformations fail is that they take a long time. As humans, our expectations for things have dramatically changed over the last five to 10 years.
Today we expect things immediately. Amazon will now deliver almost anything, including groceries, to my home in two hours or less. We have become conditioned to near-instant satisfaction, and we are losing the ability to defer gratification.
In organizations, the challenge of wanting instant results is exacerbated by the short-term tenure of executives and a somewhat myopic focus on short-term results. The average tenure for a CIO is about four years.
That isn’t a lot of time to make a deep and lasting change like a transformation to agile. Executives find that they need to hit the ground running and deliver results fast. Most don’t have the patience or the time to take on an agile transformation. So they push for the quick fix, the one-time big bang transformation. And those big bang agile transformations are quite likely to fail.
A true agile transformation in an organization is anything but fast. Change takes time, for all organizations. Most people believe it takes three to five years. That is beyond the horizon for most executives.
Those transformations that get started will likely be halted mid-stream once the focus shifts to a different shiny object. Or the agile champion leaves the organization.

#2 – Agile Transformation is Limited to Process Change Only

Many people see agile as simply an alternative way of running projects. They view it as another tool in their toolkit, alongside traditional project management practices like those described in A Guide to the Project Management Body of Knowledge (PMBOK® Guide).
This view of agile as a process change misses the most critical aspect of agile, namely that it is fundamentally a culture and mindset change. Treating agile transformation as a process change alone is short-sighted and will likely cause your agile transformation to fail.
Without a change in mindset and culture, agile will become an empty set of rituals that fail to deliver the promised benefits. Pretty soon, the organization will snap back to its tried-and-true methods, like a rubber band that has been stretched.
Consider the example of FinTech giant ING. It invested heavily in agile development processes in 2011 and then further into DevOps.
Years later, it recognized that it didn’t get the benefits because it hasn’t fundamentally changed the organization structure and relationship with the internal business customers. It had simply bolted agile onto the existing organization.

#3 – Lack of Executive Leadership

Another common reason for agile transformation failure is a lack of leadership support. And not just support, actual leadership from the top. This frequently happens when agile was initiated as a bottom-up effort at the department, project, or team level.
Agile may have worked great initially for that department or business unit, and so the leaders agree to “do agile” and then sit by and wait it out. That is, they tolerate agile ways of working.
The bottom-up approach reminds me of a bunch of kids building a tent fort in the living room. They have had great fun and they believe that their parents are going to let them leave it up forever. They are somewhat shocked when mom and dad want to put the living room back the way it is “supposed to be.”
Like parents, managers and leaders may tolerate things being done differently, but only for so long. As soon as there is a bump in the road (and according to the Satir Change Process Model, there will be problems, see diagram below) they are going to change the priorities of the current sprint, pull team members to work on special projects, demand an MS Project Schedule or take some other action to undermine the agile transformation.

#4 You Don’t Get It – Lack of Agile Understanding

The root cause of the previous two items could be that there is a lack of understanding of exactly what agile means.
Despite the fact that agile software development has been around for nearly 20 years (and Scrum and other predecessors even longer), some people have not taken the time to really understand it.
I see this all the time. Invariably when I visit a new client, they tell me that all the leaders are onboard and they understand agile.
The problem is, they really don’t get it! Some do, of course, but most have only read about it or experienced a version of “agile” that wasn’t really agile at all.
Where possible, I strive to encourage them to learn about what agile actually means before telling their teams that they need to adopt it.
I often have to convince them that an investment in agile training to establish a common set of terms and understanding would be a good idea.

#5 – Copying Others Instead of Experimenting and Thinking

One of my personal pet peeves is when people mindlessly parrot the ideas of others without thinking too deeply about them. This is likely to cause an agile transformation to fail.
If you call your development teams “squads”, I am talking about you.
Transformations don’t begin in a vacuum. In most cases, someone from outside the organization brings in a specific set of practices that worked in their previous company.
Or they are a coach and they tell the organization what is best for them. Or someone in the organization reads an article about transformation at Capital One or ING, or watches a Spotify video; they use that as a blueprint for their transformation.

In its simplest form, agile is about thinking, running small experiments, and improving continuously. It is about building the muscle of learning. It is not about copying what another organization did and implementing it as a cargo cult.
[See my related article: There is No Spotify Model] This is one reason I insist my clients develop their own internal coaches and champions to help lead their transformation. It is exactly those people within the organization that can help drive change from the inside out. External coaches like myself can help to kick-start the change, but the people closest to the work need to own it and that includes making informed decisions about the transformation.

#6 – Lack of Compelling Why

Simon Sinek is probably best known for his book Start with Why. And with good reason. Before starting any change initiative, you have to know WHY you are doing it.
It isn’t enough to point at others and say that you want to transform because others are using Agile and Scrum. And a why isn’t “to Adopt Scrum”.
Organizations need some sort of burning platform if they are really going to engage and attract others to the change initiative. They need to see both how detrimental it will be to not change and have a vision for an attractive future state. Otherwise, people will be consumed with the urgencies of the day and not be compelled to change.

#7 – No Guiding Coalition

Change expert and Harvard Business Professor John Kotter says that it is imperative to have a group of committed people leading it. It is not enough to have one executive leader. And you can forget it if you only have a team doing bottom-up, team-level agile.
The coalition needs to have representation from across the organization, in different roles, and with different perspectives and skill sets.

#8 – Agile Everywhere

Some organizations go overboard with agile and there are zealots who believe it belongs everywhere.
Maybe.
More likely there are areas where it fits well – like product development or software – and others where it doesn’t work so well. In their book, Doing Agile Right, Daryl Rigby, and his co-authors call this Agile Everywhere.
Rigby goes so far as to call Agile Everywhere one of the three toxic mistakes that organizations make. They argue that agile ways of working don’t fit every situation and in some areas like finance or compliance, a more bureaucratic approach is actually OK.

The challenge in short is not to replace bureaucracy with agile everywhere but to find the right balance between the two.
Daryl Rigby et al, Doing Agile Right.

#9 – Agile in Name Only

This is so prevalent I should have put it right at the top! ‘Agile In Name Only is the term for those who simply rename the things that they are doing with agile names. Status meetings become standup meetings, phases become sprints…you get the picture.
This is dangerous for a couple of reasons. First, it reinforces the status quo. When you simply rebrand what you are doing today with Scrum terms, you keep on keeping on as they say.
Second, you eliminate the opportunity to learn what true agile means. By calling your existing project managers “Scrum Masters”, you remove the need for anyone to learn how to be an effective Scrum Master.
Agile and Lean Expert Craig Larman calls this out in his laws of organizational behavior. His first and second rules are shown below:

1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.
2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo.
Craig Larman, Larman’s Laws of Organizational Behavior

#10 – Waterfalling Your Agile Transformation

If you have a Gantt chart for your transformation, you’ve already failed.
Some organizations treat agile transformation as a waterfall project and they drive toward specific outcomes and timelines. That won’t work.
Transformation is an ongoing process of experimentation, learning, and improvement. It is not a fixed scope, fixed timeline project to hit a specific target.
Transformation expert Michael Sahota described this well in his Certified Agile Leadership training that I took a few years ago. Sahota provided the following image of what transformation looks like:

What Is Your Experience with Agile Transformation?

I am very interested in hearing from you about your experience with agile transformation. If you’ve been part of a transformation before or are currently involved in one, what have you learned? Are my observations about what causes agile transformations to fail on target?
An earlier version of this article was published on ProjectManagement.com.

Like this post? Check out our other blogs that have similar free downloads: