The No. 1 Reason Agile Transformations Fail

At Polaris Solutions, we often work with organizations looking to become more modern and flexible in their software development practices. Many of them come to us after attempting an Agile transformation on their own and experiencing varying degrees of failure. In some cases the transformation was canceled, for others the initial changes were eventually reversed, and for others still the results simply fell far short of expectations. Over the years, we’ve been able to make note of several patterns for success, as well as many anti-patterns to avoid. Chief among those anti-patterns is one almost guaranteed way to make your transformation go sideways: not establishing a sense of urgency. 

Below, I’ll break down why urgency should be intrinsic to any Agile transformation, and offer up some recommendations for protecting a sense of urgency throughout the process. 

Why Embrace Urgency

When we consult on Agile practices, we’re helping clients adopt new practices, tools, and roles within their organizations. Scale (the number of people/teams affected) and scope (the degree of change involved) are the two largest variables that go into planning such changes. The bigger the combined scope and scale, the more effort that will be required in order to ensure that the change will stick and will maximize value. In order to be successful at Agile transformations you need more than Agile knowledge and experience, you need to be experienced at managing fast change.

As a methodology, Agile was born out of urgency. Exponentially increasing requests from users and customers during the digital age, coupled with expectations that the desired features be delivered faster and faster, has driven ongoing adoptions of Agile since the early 2000s. Organizations that resist or deny this change risk the same fate as a taxi business in Uber’s wake. But there’s another, more practical reason Agile transformations need a sense of urgency to succeed: CIO tenure. According to a recent study, the average CIO’s tenure across major industries is 4.6 years. In the big picture, that’s not a lot of time to explore an organization’s processes, get aligned on priorities, and lead a transformation. 

Where To Start

To avoid this common Agile pitfall, the first question to ask is why the transformation is necessary? Is it actually an urgent need? Does your team or organization feel compelled to change now or is continuing with standard operating practices considered generally acceptable? Before a team or organization is going to change, they will need to recognize the pain of not moving. It has been suggested that human beings change behavior only in response to pain (either emotional or physical), therefore, the greater the actual perceived or actual pain, the higher motivation to fix it. This is true for Agile transformations as well.

Providing a strong focus and making the case for an Agile transformation in the enterprise from the onset will pay off many times over. The following are some suggestions gathered from Polaris’ successful Agile coaching projects:

  • Ensure Awareness – I’ve seen too many organizations hope to enact change after two weeks of training and then never talk about Agile again. There are many degrees of education and experience you can provide to a team to illustrate the value of moving to Agile. Sharing awareness and knowledge can help make the case for Agile as it largely makes sense to most team members. “Early and often” is a good rule of thumb when communicating in larger organizations.
  • Identify Champions and Holdouts – The United States military prefers to ensure that it has overwhelming force when engaging in battles, and you should as well when endeavoring to change a company’s culture towards Agile. You have friends and allies who can be helpful; do not try to lead a change like this by yourself.
  • Communicate the Costs of Not Changing – Answer that question for yourself and for your team and organization. Perhaps the answer is “quality issues are causing us to lose customers or contracts.” You can use a combination of logic, reason, and emotion to communicate this concept, but I’ve found that if it can be tied back to metrics and numbers, most people will understand and align with you. The higher the value of the change, the more urgent everyone will consider it to be.

The points above arguably have more to do with an organization’s emotional intelligence and comfort level with change than technology. Those of us helping to lead transformational change need to consider these concepts if we want our Agile initiatives to be successful.