For most, Agile is synonymous with iterations and incremental delivery. For a select few, it’s just another way for team leads to hide their inability to deliver against a long-term plan.
Regardless of your sentiments towards this, Agile has been proven to be effective in project delivery. However, it does come with its disadvantages and knowing these upfront will save your team/organisation a lot of heartache. This post isn’t about the pros and cons of Agile, it’s more about why it fails.
So, why do Agile projects fail? There are countless reasons as to why Agile projects could fail but here are 3 reasons that I’ve personally encountered:
1) Shoehorning projects to make them fit – Some projects have no business being implemented using Agile
There are cases where regulations deem it necessary to run projects using the Waterfall methodology (sometimes called Traditional approach). This could be due to strict documentation policies, or mandatory regulatory audits/sponsor approvals between project phases.
In cases like these, Agile will not be best suited to run project portfolio.
2) Having all requirements upfront, set in stone, and not setting clients expectations – your client expects a polished product at the end of your delivery
Some of you might have noted that part of the title somewhat goes against the reason for using agile to begin with. I have been in organisations where senior stakeholders want the complete Agile philosophy adhered to from top to bottom and require that all projects be run as such. On the other hand, they would also like to know the earliest date they could deliver the full version of a new product.
With Agile, you deliver a Minimum Viable Product (MVP), then add functionality to it (usually based on customer feedback). Let’s face it, what’s the point in delivering a solution where your customers barely use 12% of the total functionality.
Without setting that expectation upfront, your client might assume you’re delivering the finished product at initial Go Live. This in turn means you will not meet your client’s expectation and the project fails.
3) Conflict and Resistance
By this, I’m referring to the conflict in organizational culture and this new phenomenon; the resistance when introducing the unknown to individuals who are proficient in their way of working; the inevitable pushback when those presenting this new idea are not themselves well versed in it – yes, that!
One of the biggest challenges of introducing Agile to an organisation is buy-in, or better yet, lack of it. Employees and management alike will always say “If it ain’t broke, don’t fix it”. They wouldn’t be wrong there.
Here’s a scenario: A company delivers a bespoke CRM solution with a 2-month turnaround. They can promise their customers that in 2 months, they’ll get their finished product. It’s difficult to convince senior management that agile would be a much better fit, especially with 2-week iterations that welcome change.
To persuade the management team to adopt this new process, you would have to convince them that not only would they not lose visibility over this self-organizing team, they would be getting rich up-to-date reporting (of agreed KPIs of course) that focuses on information that matters, free from all the traditional project bloat. Their customers will also be involved earlier on in the process, as well as all through till sign-off…and you know, all the other great things about Agile.
If the individual or team introducing Agile isn’t fully aware of what it is and how it would fit within an organisation, isn’t this new process destined to fail?