Blog

Typical Factors in an Agile Adoption Failure11 Jul 2017

There are a number of things that can be blamed for why your attempt to implement an Agile approach has failed. Let's take a closer look at the most common ones.

Too many risks taken:

1. Agile methods may support risk taking in short iterations, but this is a double-edged sword. While you do get to experiment and make bolder decisions regarding the product, it poses the danger of missed deadlines and wasted resource time.
2. Another common risk is using too different methods in production and testing environments - for example, the key quality testing and assurance teams are too distant from the production team and are following other procedures and approaches, which results in incompatibility of completed tasks and their tests.
3. A non-starter risk for Agile aspiring teams is failure to involve the customer in the process - there is a reason why this is a key Agile feature. Among other aspects - it helps to reduce the "disappointed client" risk.
4. Finally, bad or none project status visibility among the team - leading to misinformation, waste and most probably frustration is a risk that is possibly the easiest to avoid. Just implement an Agile-typical tool like Kanban, Scrum or Scrumban and get the team to collaborate in this way throughout the process. Kanban Tool comes in highly recommended by thousands of teams.

All of these risks can be minimised, by simply including them in the action plan early on: establish the same production / testing environments and approach, schedule regular meetings with the stakeholders and set up a visual process board that the entire team can follow and base their work plans on.
What else is likely to determine failure in trying to stay Agile?

Too long lead times

If the time between a concept and its monetisation is long enough to cause financial issues within the company, you should be alarmed. While all tests and assurances are indeed necessary for any product / service to be reliable, emphasis should be placed on getting them done as soon as possible, with the highest priority. Keeping things ready but not available to the customer is like burning money.
Ideally, the process should be separated into chunks (as in research, planning, building, testing, release and follow-up etc.) and the vital thing to keep in mind here is that teams responsible for each chunk need to be available to take them on board as soon as they arrive.
Should be doable for as long as the previous iterations went smoothly.
If they had not - it's advisable for the team that is not ready to pick up new urgent items to hand one of the workloads (the unfinished items or the new coming ones) down to a backup team.
Just as long as the process is not impeded, the lead times will stay reasonable and the business will remain Agile and organisationally healthy.

Exceeded expenses

Long lead times go hand in hand with overspending in business costs. Both a strong sign of failing to stay Agile. One Agile-typical way of staying on budget is building truly cross-functional teams. It's never easy, but when done well, it can save a lot of time, money and bother on finding specialist assistance for one-off issues all the time.

Culture clash or dismissal

Not all companies can adopt the somewhat specific culture that goes with Agile: there's not always enough room for respecting the organizational chain of command, not all people can work with the frequent re-prioritisation and rapid changes. A characteristic trait of Agile is that it allows for the actual stakeholder needs to take priority over the organisational and bureaucratic hustles.

We remain convinced that Agile can be adopted by most teams and organizations, if the right amount of effort, preparation and planning goes into it. Please keep the above circumstances in mind before you get your team to jump in, expecting effortlessly occurring miracles :)