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. Let’s explore some of the reasons that these agile transformations fail, based on my observations of various transformations I have seen.
#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).
PMI encourages this thinking of agile as a process as it promotes hybrid agile approaches in its recently published Agile Practice 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 very like to lead to failure.
Without a change in 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 on to the existing organization.
#3 – Lack of Executive Leadership
Another common reason for agile transformation failure is lack of leadership support. 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 a MS Project Schedule or take some other action to undermine the agile transformation.
#4 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
Most agile 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.
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.
What is your experience with agile transformation? I hope you find this article and the reasons for agile transformation failure helpful. In my related post, How Agile Leaders Create Business Agility in 3 Steps, we explore what other organizations have done to succeed.
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 above on target?
This article was originally published on ProjectManagement.com.