Avoiding 4 Common Failures in Agile Transformation Projects

According to the 2021 State of Agile Report, companies typically start an agile transformation project to enhance their ability to manage changing priorities, accelerate delivery, and increase team productivity.

The benefits of agility are clear. So as companies get started, many begin with one of two scenarios: 

1. An isolated tech team runs an agile transformation project to adopt a framework (e.g., Scrum, Kanban, DevOps).

2. An organization runs an enterprise agile transformation project to rollout a scaled agile framework and/or agile team structure model (e.g., SAFe, LeSS, Scaled Scrum).                          

However, agile transformation projects often fail. Failure rates range from 47% to 96%, and 67% of these failures end catastrophically—either in takeover or bankruptcy.

This article explains four common causes of failure during agile transformation projects, and introduces two tools to help support business agility. 

Four Points of Failure in Agile Transformation Projects

Now let’s dive into the common failure points in agile transformation projects: 

1. Working towards agility with a project mindset.

The first point of failure happens when organizations or isolated teams take a project approach, meaning they utilize fixed roadmaps and preconceive what the resulting practices and frameworks should look like. This approach frames the effort in an anti-agile mindset. 

Instead of having fixed metrics, companies need to remain flexible. Customers and markets are always changing, so companies must keep pace and recognize that agile is not a result. Agility is something we work toward, a moving target. We stay on target only when we continuously learn and observe what works and what fails and adapt based on those lessons. We need to understand that we are on an agile journey.

2. Rolling out a one-size fits all agile framework. 

When organizations simply roll out a framework (e.g., Scrum SAFe, LeSS, Scaled Scrum, etc.), we cannot expect it to fit with every team or company. Every organization is a unique, complex system, with specific problems and opportunities. We must form and adapt frameworks and their practices to meet the unique needs of each company. 

Let’s use Spotify as an example. They did not simply pick a model and roll it out, they experimented to form it. Spotify continues to constantly adapt their behavior and practices to meet their complex problems. They realize their needs will not be met by complacently using a practice. 

3. Human experience bias.

Experience bias is another root cause for failure. We will use the organization-wide rollout scenario to illustrate experience bias. Consider a leader who has always worked in a highly structured environment. When they are put in charge of rolling out an agile framework, they may see each pitfall as a process shortfall, which they would solve with increased process. This leader’s experience bias will result in a hard to use, heavy process. In turn, the workforce trying to use the process will quickly resort to their experience bias, subverting, or circumventing the process. We need to learn to recognize and replace our experience bias with situationally appropriate responses.

4. Isolated effort. 

For our last common failure, we will consider the scenario of an isolated tech team adopting an agile framework. 

The tech team independently controls and executes their engineering lifecycle. The team may choose and adopt a good agile framework (e.g., Scrum, Kanban, DevOps), and yet not see the expected benefits. 

The failure becomes clear when we accept that the team is not independent, they interact upstream and downstream to define, build, and deliver solutions. In a complex system, all interrelations must be considered because an “organization will only become as agile as its least agile function.” To move toward agility, the organization must journey together.

Two Tools to Support Agility

Understanding and applying two tools, Cynefin and business agility, can significantly help an organization avoid the four failures and undertake a more successful agile journey.   

Tool 1: Cynefin for Agile Transformation

Cynefin (Khu-NEV-un) is a Welsh word roughly meaning “a place of your multiple belongings and experiences that subconsciously bias how you think, interpret and act.” 

Designed in 1999 by Dave Snowden, his use of an unfamiliar word is intentional. The word makes us curious, forces a narrative and exercises our learning muscle. Remember, on this journey we are continuously learning!

Cynefin is a sense-making framework. It makes sense of reality, showing us what we are “operating as” across a set of domains and showing us domain-specific responses to our problems. 

Watch a video explanation of the Cynefin framework. 

Understanding the model, and in particular two of its domains, helps us understand the four common points of failure.

1. Complicated: We know the problems and that they may be difficult. 

Response: We can choose from several existing good practices to solve the problems. As an example, to execute QA, either behavioral-driven development (BDD) or test-driven development (TDD) would succeed.

2. Complex: We have many unknowable problems and many interactive elements impacting our way forward, and issues will surface that we cannot foresee. 

Response: We must use exaptive practices; we form practices as we need them, through cycles of experimentation (problem, solution hypothesis, experiments, review results, and adapt).

Recognizing that an organization operates as a complex system, and knowing the appropriate per-domain responses helps us fully understand and avoid the four points of failure.  We can also use Cynefin to enable more successful outcomes.

1. Instead of approaching agile as a transformation project, with endpoints and preconceived expectations, try ongoing experiment cycles

2. Instead of resorting to experience bias, try using domain-based responses to solve problems

3. Instead of a one size fits all rollout, pick a framework and expect to adapt it over time, including jettisoning what is less useful for your organization

4. Instead of thinking a specific team is isolated and only operating as a complicated system, consider all the ways in which they are part of the organization’s complex system 

Tool 2: Business Agility for the Agile Journey

The second tool, the business agility model, supports complex adaptive systems and their journey toward agility.

The model defines 12 domains spanning four dimensions and the model drives focus toward five mindsets, that ensure a cohesive approach to agility when adopted by every employee: 

1. An obsession with creating timely customer experiences that fulfil real needs.

2. Actively engaging and aligning as a workforce.

3. Empowering management and catalytic leadership.

4. Unified business functions, processes, and policies.

5. A culture of respect, trust, learning, and autonomy.

“At its simplest, business agility is the capacity and willingness of an organization to adapt to, create, and leverage change for their customer’s benefit.” (Domains of Business Agility)  

Unlike an agile transformation project, focusing on business agility is not about rolling out a framework or complying with agile practices. Business agility is about individual behavior and recognizing that an organization is its people. 

Every person involved in a company affects the system. By having each person support and evolve the culture, people, and skills, and by sharing the same agile mindset the organization becomes increasingly adaptive and responsive. “The adaptability of an organization is directly related to the adaptability of the people.” 

Stop “Doing” Agile, Start Learning to Exercise Agility

Cynefin and business agility can reframe how we think so we evolve realistically, systematically, and pragmatically. Using these tools, we can take the first step to ignite workforce enthusiasm, achieve desired outcomes, and create useful solutions with our customers.

The only way to fail on this journey is to stop learning.  

If you’re interested in taking your next step in building agility at your organization, reach out to us at findoutmore@credera.com.

• Agile & DevOps Transformation
• Agile Adoption
• Agile
• Agile Development
• Agile Methodologies
• Agile Methodology
• Agile Process
• Business Transformation
• Transformational Change