Agile - Reasons for failure

3 minute read

Agile (SCRUM) is a very good process for software development, not only i say it but most of the companies worldwide say it and have adopted it. But everything that is good without proper monitoring can easily turn worse.

I have been part of some really good and successful agile teams and also have been part of other teams. So when i retrospect what was the reasons for the failure of those teams or products i came up with the following.

Overly and early modification of Agile Process.

If you have heard any of the Agile practitioner or trainers they would have mentioned that you need not follow what’s in the book. This gives anybody the freedom to manipulate the process. This is where most teams coming from SDLC, waterfall, CMMs falter. They try to do a hybrid agile which fails 9 out of 10 times.


Start with text book agile, you have retrospective meeting to discuss if you should improve the process or if the textbook works for you.

Moving target.

Change is Constant hence we have agile. True but if you have a constantly moving target you will never hit the mark, ever!!!. Product owners or the stake holders keep changing the vision of the product.


The team should be constantly be monitoring the backlog and should be informed by the POs about the moving target. If there is a change within the sprint/iteration its the duty of the scrum master to ask the PO to get the hell out of there.

No Automation

If the company doesn’t invest in automating the testing, its not agile. Agile is all about shippable product at the end of each sprint and if there are not automated testing, you can imagine the amount of time spent on regressing the software after each iteration and also the quality issues that could eventually creep in.


Add automation as an integral part of the team, they should start writing automation scripts as soon as the developer starts coding the story.

Agile team is not a Story factory

Yes they are not. Even the Airbus 380 engines need to cool down once they have done a 20hr sprint, we are just humans. The team needs motivation, personal skills development and some time to really have fun. All work no play makes Jack a dull boy, something like that.


At the end of each release (not sprint), team should have a stabilization sprint, i know its oxymoronic. This is the time when team can cool off, learn something new while the system is continuously being stabilized (definitely wouldn’t take all day to fix bugs esp. with high quality automation).

No Team Charter

Team charter is a contract between team members. If the team doesn’t do this when the team is formed this helps develop mutual respect and trust amongst the team members.


Please do the team charter before the team is formed. Its not more than 1hr meeting but vital for success.

Customer feedback

After each sprint a demo must and should be given to a customer who is willing give his valuable feedback. The team should be present in this demonstration. Any kind of appreciation really motivates the team and also at the same time if criticised must be met with same enthusiasm. Most projects do not even have a customer or prospect to give the feedback.

These are only few of the items but there are many other factors for failure of a team. But the stakeholders should monitor the team on a regular basis and help the team by removing the impediments. Same applies to the Product owners they should constantly receive feedback from the customer and groom the backlog.

One final note, if you are working on a product using Agile and plan to go to market or get customer feedback after 1 year, you are definitely heading for failure.




Leave a comment