Why does Agile fail?

A few days ago, during a training session, someone asked me why Agile projects fail. While apparently simplistic, the question is a loaded one. Agile failure can happen in two scenarios:

Project level failure - when a project following the Agile philosophy does not reach the project goal
Enterprise level failure – when despite having a few successful Agile projects, there is a failure while broad-basing the philosophy at an enterprise level

Interestingly the success or failure of the above two, are not interrelated. Today I’d like to talk about the first instance.

In my experience, failure of Agile at a project level typically occurs when people start applying the Agile philosophy like another SDLC (software development lifecycle) process without understanding the intent behind it. The Agile philosophy is all about delivering early value while retaining the ability to react to change. Typically frameworks like Scrum, FDD, XP, and Kanban help in delivering this philosophy. The problem occurs when one starts to follow the process, without looking at how the value can actually be delivered earlier and how the organization can reacts to change.

So you will hear people saying things like – we do daily stand ups (which run for over an hour), we have retrospections (where items never get tracked for closure), we have stories (which get delivered over 2-3 sprints). The failure arises as teams don’t adopt these practices properly and don’t build in agility. The inability to adopt the practices in the right way results in issues such as:

Hour long stand ups where people try to resolve an issue then and there
An estimation where the team is still not involved and client just ‘gives’ the expected output
Planning meetings which take place without the entire Scrum team participating.

The inability to build in appropriate agility results in and is also a result of weak engineering practices. This leads to issues such as:

Limited automation (especially for testing)
Absence of vertically sliced stories which can be delivered with 2-3 days
Absence of a strategy around continuous integration (I am not even bringing continuous delivery into the mix)

Teams often follow a waterfall-model of working, but claim they are Agile as they have closed something within 2 weeks. E.g. some part of HLD is closed in the 2 week sprint, or code for 1 feature is written within the 2 week sprint. We usually tend to call this Scrum-Fall, Water-Scrum-Fall etc.

To avoid project level failures, it is a MUST for any project team who is adopting the Agile way of working to get coached by an expert practitioner. Incorrect adoption could lead to the initial goals not being met and instead Agile being blamed for the failure.

Have you faced a similar scenario while trying to implement Agile in your projects? How did you address it? Write in with your views and come back next week where I will share my views on why Agile adoption fails at an enterprise level.

About The Author

Rituparna Ghosh, a General Manager with Wipro, has about two decades of experience in areas of Continuous Improvement. She leads the Lean, Six Sigma and Agile transformation initiatives across the organization. She and her team work closely with accounts to drive Agile transformation and Agile training.

Rituparna, a graduate in Economics, has done her MBA in Marketing and Strategy. She is a certified Black Belt in DMAIC and trained in Lean, CMM, ITIL and Agile. She can be reached at rituparna.ghosh@wipro.com.

Service Offerings

Service Offerings

Client Themes

Client Themes

Why does Agile fail?

About The Author

Service Offerings

Industries

Cloud

Cybersecurity

Digital

EngineeringNXT

Holmes

Contact Us

About Wipro

Careers

Location

Leadership

Investors

Innovation

News and Events

Insights

Analyst Speak

Products & Platforms

Partner Ecosystem

Sustainability

Contact Wipro