Why Agile Fails?

Let me share some insights based on my personal experience and observations and answer this nagging question (from my point of view).

Observations From My Career

Over the last 10+ years in IT, every time I joined a project or a progamme – whether taking over or kicking one off – I’ve had to either improve the Agile process or coach the team on Agile best practices. This raises a question:

Why do so many professionals, even those experienced in software development, still lack familiarity with Agile principles and fail to understand the reasoning behind them?

• In one project, retrospectives weren’t happening on a regular basis. When I asked why, I was told there was “no time” to conduct them regularly, so they were held every 2-3 months at best.
• In another project, the daily stand-up involved 25 participants.
• On another team, planning sessions didn’t exist. Teams were regularly failing to meet their commitments and business expectations and they coudn’t figure out why.
• One project had plannings every 2 weeks and 1 call named “daily”, which was conducted once per week. User Stories were created as tasks, were xonsidered as a personal to do list and rolled over from sprint to sprint.
• Some projects I joined had all the required ceremonies, but the implementation was hollow. It felt as though the terms “Scrum” or “Agile” were being used as labels, devoid of any substance.
• In some other cases, customers imposed delivery models riddled with Agile antipatterns.
• In some teams, scaling concepts were nonexistent. Instead, they tried to copy existing frameworks without adapting them to the project’s needs.

These real-world examples and observations left me wondering if there is a pattern of widespread misunderstanding, misinterpretation, and misuse of Agile.

The Core Problem

I’ve concluded that Agile, Scrum, and scaled frameworks are no match for incompetency and misuse. Why? Because knowing how Agile works on a surface level doesn’t mean it’s truly understood.

Here’s how it typically happens:

• Agile antipatterns are allowed to take root.
• Inexperienced team members and leadership see these as the norm. They take this “knowledge” with them to their future projects and spread it among others. The usual rhetoric about this is:” I’ve worked on multiple projects before, I’ve seen this done this way before and it was working just fine”.
• Over time, these “practices” snowball into deeply ingrained habits, perpetuated across projects.

In the best-case scenario, if team members are open-minded, a competent professional might step in and course-correct.

However, more often than not, the opposite occurs: Incompetent individuals dismiss the competent ones, resisting change, and the cycle continues.

Incompetency breeds incompetency.

Why Does This Happen?

Several factors contribute to Agile’s failure in many environments:

1. Business Over Process: Many companies prioritize revenue over establishing sound processes. While business goals are important, quality delivery is what creates long-term value.
2. Lack of Leadership Education: Managers and leaders often fail to educate themselves on why Agile practices matter, leading to superficial implementation.
3. Certification Without Understanding: Certifications are sometimes pursued for their resume value, resulting in certified professionals who lack practical knowledge or deep comprehension.
4. Ego and Resistance to Help: People often resist acknowledging their incompetency and refuse to seek advice or accept help.
5. Unchallenged Status Quo: Many accept the current state as “just the way things are,” avoiding the effort needed to challenge or improve it.
6. Following the Path of Least Resistance: It’s easier to “go with the flow” than to address systemic issues, even when they undermine long-term success.

A Case Study

Let’s now dive deep into specific case study, gathered from my own experience.

Story Time

In one project, a group of leaders decided to discuss and align on how Scrum teams should schedule their ceremonies. Under their directive retrospectives were placed after the planning sessions – a classic Agile antipattern. When the Scrum Master raised a valid concern, the feedback was provided with comments like these:

• “It doesn’t really matter. It can work either way. Not every retrospective session will have action items for the planning session ahead.”
• “We’ve seen this done before in multiple projects successfully”.
• “We shouldn’t strictly stick to the Scrum `Book. It does not exist”.
• “Conducting Planning on the Last day of the sprint and Retrospective on the 1st day of the Sprint actually “saves time”. Teams can start 1st day of the sprint with already planned work ahead and not waste their valuable time”.
• “We need to accommodate the needs of every stakeholder to be able to participate in the events, so this is a preferred way for everyone”.

The Problem and Its Consequences

The approach of swapping retrospectives with planning fundamentally undermines the purpose of retrospectives, which may lead to the following issues and consequences:

1. Lost Value of Retrospectives: Retros are designed to identify areas for improvement and feed those insights directly into planning. Switching their order removes the opportunity to incorporate those learnings into the next sprint. The team may carry unresolved issues and inefficiencies practices into the next sprint. Since planning was already done, there was no capacity allocated for potential improvement.
2. Lost Context and Relevance: Retrospectives are meant to reflect on the previous iteration. If held after planning, the team may have already shited focus to the next sprint, making it harder to recall and analyze past events accurately. Discussions and improvements may become disconnected from actual improvement opportunities.
3. Decreased Team Engagement: teams might see the retrospective as an afterthought rather than a critical activity. Their engagement and participation may decrease, leading to a less effective process.
4. Risk of Planning and Delayed Problem Resolution: Without reflecting on past successes and failures, planning may rely on inaccurate assumptions or overlook recurring issues. problems or blockers from the previous sprint remain unresolved, potentially snowballing even in larger issues. This may all lead to unrealistic goals set in planning, unaddressed issues and risks, lower productivity, and team frustration.
5. Long-Term Consequences:
   1. Fixing this later will require extra effort and time to re-educate and realign the teams.
   2. If unaddressed, this antipattern becomes normalized. Teams take this flawed practices into future projects, perpetuating dysfunction across organizations.

The Outcome

This situation ended up with a good resolution. A discussion took place, and after the Scrum Master explained the reasoning behind the recommendation not to follow this approach, gained support from other Scrum Masters and stakeholders, the agreement was reached to revert to the proper sequence and “get back to normal”.

How to Make Agile Work

Agile doesn’t fail because the methodology is flawed—it fails because of incompetence, misuse, and resistance to change, learn, and understand. Under such conditions, even the best frameworks can’t survive.

For Agile to thrive, we need:

• Leaders who prioritize both business goals and process integrity.
• Teams willing to challenge the status quo and embrace continuous learning.
• A culture of humility, where seeking advice is seen as a strength, not a weakness.

Until then, Agile will continue to struggle under the weight of its own misapplication.

---

Want to hear more insights about Agile, Scrum and Project Management? Join my newsletter using the form below 👇