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.