Why sometimes Agile Transformations fail?

Based on my experience working in Agile environments since 2010, I did some research and general observations on the topic. Regardless of the business domains or product area, there are some common rules that may devastate your efforts towards Agility.

First of all, we need to underline that the Agile Transformation never ends. This is an ongoing process of continuous improvements, running inspection and adaptation. However, the outcomes might be insufficient in some cases.

Secondly, in some organizations, the process of Agile Transformation takes many years, yet still, the results are unsatisfactory. People related to this process might ask themselves:

“Why is that? What could happen? What went wrong?” but they often resign from striving for Agility, even blaming Agile (“We are different. Agile is not designed for us.”). Sadly, they do not retrospect.

Even if the current results are disappointing, the reflection process and then taking some actions are crucial in other organizations. This is the first step to a betterment.

What’s more, I observed the huge difference in Agile adoption in many companies depending on the department or product. It means that several products or whole departments have been working and acting with Agile in mind, where value delivered for customers was exceptional. Simultaneously, in other enterprise departments, they were stuck and didn’t see too many benefits from Agility.

There are several reasons I observed why Agile Transformation might fail or just creep. Interestingly, all these situations have a common denominator. The list I have created undoubtedly does not cover all cases. This file shows the most common reasonings that may impede Agility in organizations. Awareness, how the environment is set is the key to understand and make these impediments transparent.

Indifferent engagement of C-level, VP, senior directors in the process

The attitude regarding Agile adoption that is represented by top management impacts the whole process. Disengaged management is the most common reason in my ranking. There were only not too many examples in my career when the bottom-up Agile transformation was successful. Usually, top management is at some point aware of Agile activities in the company, Scrum adoption, although they leave it to the teams. One of the frequent reasons for this behavior is that top management is not acquainted with the understanding that Agility is beneficial for business, product, and the most important – customers/users.

They consider Agility, Scrum, and Lean as something that might improve delivery and teams’ productivity.

Let’s imagine the situation when a large number of Scrum Masters reported the same impediment. It becomes an organizational impediment. How would you resolve it when decision-makers are not interested in? How would be the impact on teams’ engagement and product delivery?

Active management that fosters Agility and empirical way, and actively participates in the whole process is a secret ingredient that makes the transition more realistic.

Low focus on value and customers

Another observation I have made is a strong focus on delivery, productivity, technology, effectiveness. It would be nothing wrong if we added to this list at the top value and customer-oriented mindset. We may deliver plenty of features, yet still not provide any significant value.

Hierarchy and culture

Hierarchy in the organization can harm trust, employee satisfaction, engagement, culture, creativity, motivation, self-organization, Agile Leadership, and transformation by the fear, pressure, formality, traditional management, lack of transparency, politics, negative consequences.

The company culture reflects the values and beliefs that are enacted. A company’s positive culture reflects better customer satisfaction, employee satisfaction, and revenue (based on research described in Harvard Business Review).[1]

Low understanding of empiricism

In complex environments, the only answer is empiricism. This means frequent inspection, adaptation, and transparency.

That concept is crucial to enable Agility in the organization.

Lack of support from middle-management

Sadly, the middle-management level attitude might be another reason why Agile transformation fails. Lack of support or even blocking ideas and changes is widespread. Often, this behavior is based on fear of losing a job or power or control. On the contrary, during the process of adopting the Agility, I regularly missed leaders. They are empowered enough to help remove impediments to enable Agile in teams, business, top-management, customers, and many more.

Project-oriented organization (instead of a product)

Projects and traditional, predictive mindsets are still dominative, especially in large organizations. There is a strong attachment or maybe a habit to conventional project management. Products are rarely defined. This approach leads to an iterative waterfall (scrumfall, wagile, etc.) as projects impose fixed time, scope, and budget, thus little opportunity to inspect and adapt and deliver the most desired value to customers.

Low level of transparency and trust

This is one of the most critical blockers on the way towards Agility and should be immediately discovered and revealed. In such circumstances, any change is tough to proceed.

Vague reasons why they want to implement Agility

Several companies I have met could not clearly answer the question: What is the reason you want to make a transition to Agile? Quite often, the reason is that they want to be faster to the market or other companies do so. I do not blame these reasons. I only want to make it clear that deliberated ones may cause your transformation more successful.

If Scrum, usually mechanically implemented and understood

Misunderstandings when it comes to the Scrum framework are often met in companies. There is a strong focus on velocity, story points, perfectly written user stories, outputs delivery instead of delivering valuable, potentially releasable Increment, and customer satisfaction.

A mechanical implementation of Scrum (versus empirical Professional Scrum) always leads to the so-called Zombie Scrum, which means that there are no benefits from Scrum; the organization is focused on outputs rather than outcomes.[2]

An organizational structure that makes delivery even more complex

How the company is organized, structured,  and how they define their delivery flow has a tremendous impact on many aspects. This is visible, especially in organizations where end-to-end product delivery must go through many departments and/or teams. This approach usually requires bureaucratic processes that are simply unnecessary overhead. Such organizations typically are focused on projects rather than products. A product-oriented structure could be a solution and dedicated teams focused on the same product (reducing context switching).

War between departments

Quite a prevailing situation is disagreement and blaming game happens between business departments and IT, in IT internally, in business internally, or other combinations. I have seen these situations several times and I considered them as a considerable impediment towards Agility.

Traditional contracts that shape the process

These contracts consist of the detailed, fixed scope, fixed time and budget. In such circumstances, particularly when the contract is signed up for a few years ahead, it is challenging to work in an Agile manner without strong customer engagement and agreement to change the way of cooperation.

Limited collaboration with customers and users

Occasionally, organizations prevent teams from direct cooperation with customers. They limit engagement, product and customers’ understanding, fast reaction to the market, users’ needs by blocking this close collaboration.

Low employees’ engagement in changes

Employees’ commitment to transformation, their willingness to work in the Agile environment is essential. The Agile transformation must be performed on all levels in the company. When the level of employees’ engagement in changes is low, this can ruin all your efforts towards Agility. Usually, the reason is in poor understanding of empiricism needed in the complex environment and implementation of the mechanical Scrum framework, however, it might also be caused by the general culture of the organization.

Teams self-organization is not welcomed

There is a deep reluctance and misunderstanding when it comes to letting teams self-organize. Usually, self-organization is considered as chaos or a fear of being redundant (losing power).

Inability to innovate

A huge technical debt, sporadic releases, lack of continuous integration, etc., might be another obstacle on the organization’s way towards Agility.

Low tolerance for experiments and learning

People are not allowed for any probing, then inspecting and responding. Even short (and low cost) experiments are not welcomed.

Impediments are not solved

Even if the organization is aware of generally known impediments that are serious obstacles, no one feels responsible for solving them.

I was hoping you could give me a detailed plan for the Agile Transformation

The Agile adoption process is also empirical. We need to have an important goal(s). A detailed long-term plan is not realistic as we learn more and more over time. We need to inspect and adapt frequently.

Reports from an Agile audit are ignored

Frequently companies want to be diagnosed. Having said that, this is often only the willingness. No changes are following the audit report and initials proposals. This attitude can be linked to the following reason.

Fear of change

Some people just simply do not like changes. Both in professional and private life. Others are afraid of a new organizational structure, new job responsibilities, and losing power or job. The agile transformation causes many changes in different aspects of the company. But they do not necessarily mean losing a job. Traditional empowerment may be converted into Agile Leadership.

Agile Consultants are not heard, Scrum Masters are not empowered

In most organizations I have met, Scrum Masters are perceived as teams’ secretary, facilitator, scribe, tool admin, etc. In fact, a Scrum Master provides service for teams, Product Owners and the entire organization. This last part is frequently ignored. More information on this topic you may find here.

Agile Consultants are sometimes hired to “heal” the organization, although their (usually in cooperation with Scrum Masters) ideas, proposals, experiments are not considered to try.


These reasons mentioned above are the most common in my experience from consulting and teaching in several countries and continents. You may observe different ones. Diagnosing what is the reason for failing Agile Transformation is the key. The remedy would be reversing these anti-patterns. Always remember about showing the real data. Talking about facts has a huge impact and you may avoid discussion about emotions, feelings and beliefs.

Despite many attempts to engage the top management to the Agile implementation, when I still observe a low level of their commitment, I share this fact transparently to them and impact the transformation. Sometimes it helps and may move positive changes towards Agility.

Agile Leadership, removing impediments, empirical paradigm, taking care of anxiety, engaged top and middle management, empowered Scrum Masters and Product Owners, lively culture and motivated employees, striving for customer value, measuring value, and making decisions based on facts are ingredients of the successful Agile journey for the organization.

[1] https://hbr.org/2015/11/how-company-culture-shapes-employee-motivation

[2] https://www.scrum.org/resources/blog/how-efficiency-mindset-leads-zombie-scrum

This article was written by a human, me, not AI.


Leave a Reply

Your email address will not be published. Required fields are marked *

More To Explore

output vs outcome title

Outputs or outcomes?

While working with organizations on defining their product value, I have noticed that outputs are often confused with outcomes. Products and companies are mostly focused on outputs and company impacts, while outcomes seem to be ignored.

Read More »

Key Value Metrics

Measuring Value is one of the most essential activities in product management. For instance, for Product Owners and Managers, this process is a background for making informed decisions about the future of the product and assessing the current value and state of a product.

Read More »
Roadmap decorative graphics

Product Roadmap at the Product Portfolio Level

Having a Product Roadmap for a single product seems to be a standard in Product Management. This visual aid helps with a general product overview without unnecessary details. Increases conversations with stakeholders and creates transparency and shared understanding.

Read More »