Do your stakeholders feel a need to declare that ‘Agile is Dead’ on a monthly or bi-monthly basis? The death of agile has been declared across multiple boardrooms as frequently as businesses pivot! Here is a Google trend on the term ‘Agile is dead’:

So has Agile died? Is it on its deathbed? I beg to differ here. ‘Bad Agile’ or ‘Pseudo Agile’ or ‘Playing-to-the-gallery Agile’ has died a thousand deaths — only to be revived in the next eager, digitally transforming organization with a weak understanding & poor implementation of Agile & its’ practices.

Before we go on to identifying the 5 reasons why Agile fails in your organization, I must point out that Agile is not a ‘Framework’ or ‘Methodology’. It is a value system — a paradigm on software development that needs to be understood equally. It is vague — allowing for as much variation you deem fit for your organization. It is often confused with SCRUM (which is a Framework for development). Agile does not dictate daily stand-ups or sprints. We’ll continue to remain under this confusion for this article, breaking apart where needed.

1- ‘Why can’t we launch in 2 days? You are Agile right?’

There is a lot to unpack with this statement from business stakeholders. When they throw this statement, there is a fundamental issue in understanding Agile or SCRUM practices. Agile is not random delivery of products! If something is to be done in 3 weeks, it needs to, one — align with the sprint releases and two — align with the business goals. Assuming that being agile gives the business the flexibility to launch whenever creates a strained relationship between the stakeholders and the delivery team.

What can you do?

When you come across statements like this, it is clear there is a misunderstanding of the process. Remember, Agile methods have a process. The manifesto dictates that people are valued over processes, but that doesn’t mean the process is dead.

Adopt the following method:

1. If the business requirement is to launch in 2 days, understand why it is so… check with the team if it is feasible.
2. Explain to the stakeholder that it is possible (or if not possible, when it is possible), however, it’ll come at the cost of de-scoping other things. If the development team is in the middle of a sprint, discuss the impacts of canceling the sprint.
3. Coach them on the delivery pipeline, and how the team functions. If your stakeholder views your team as a service (developing the products), you need to change that — your team is a tool — use it effectively to get the right output, best for the customer & business.

2- ‘I want to know when we can launch. Agile doesn’t tell me that!’

This one is on us, partly. Skilled Agile practitioners will tell you that the only reporting in SCRUM is when the daily and the sprint review sessions take place. For a new implementation of Agile (or transition to Agile), it takes a while for the team to mature into a predictive role. The PO is responsible for ensuring efficient use of the team — delivering the right scope within the given time. However, not having visibility hampers businesses’ ability to allocate resources to releases. E.g. if you’re launching an app in a new region, there are a considerable amount of operational and marketing resources that need to gear up — a traditional project plan captures those, while the Agile Sprints plan doesn’t.

What can you do?

It falls on the product manager to provide visibility. Remember, predictability comes through empirical data — your teams’ past output determines future deliverability. Keeping that in mind, here are the steps:

1. Understand that this project, being the first, will determine your teams’ velocity and the stakeholders’ way of working.
2. With the scope known, get an estimation from the development team for the launch date, understanding the caveats involved (scope doesn’t change, technical understanding remains the same).
3. Provide sufficient buffers to come to a launch date.
4. Go the extra mile to add sprints for non-technical activities — understand the scope of work from various stakeholders and help them with their ‘sprint’ planning — giving them a flavor of SCRUM to better appreciate the practice. E.g. if there are operational activities that need to take place, include them in separate parallel sprints with goals
5. Align all the sprints (as shown below) to give the perfect visibility. Remember that you must ensure the success of the product, and it can only succeed when everyone is aligned.
6. Identify key deliverables from each sprint and map out dependencies with the other stream — these are non-negotiables that have to be released for testing for the subsequent parallel streams to start.
7. Involve the lead stakeholders (from operations/marketing roles) in the daily standup, so that they know the decisions and the pace of work.

I’ve found the more you involve stakeholders in your process, the more likely they’re to understand the concepts of Agile. Agile is learned only through practice.

3-‘Team X will work on launching everything by date X. Implement your project in Agile’

This is what I call ‘Agilefall’. Agilefall is Agile in a Waterfall environment. Everyone else works in a waterfall model, while the development team works in Agile. Sometimes, some development teams work in Waterfall, while some teams are ‘agile’!

This is one of the most common problems with Agile implementation — Agile-in-silo. And it is bound to fail!

What can you do?

The fundamental problem here is company culture. Maybe this is the first time you’re implementing Agile in the organization, and the second team isn’t confident of Agile methods. If that is the case, you’ve to protect Agile practices by exposing the flaws right away — you cannot achieve complete predictability with this system as changes in scope will impact the timelines right away. And the delivery timeline will stretch with integration issues!

Clearly communicating, not harshly, at every stage of scope change and delays the reasons for failure in the combined practice will ensure that the next project is undertaken as a product.

4- “I’ve spoken to the developers. They can deliver the feature in 10 days”

The unempowered PO. The backdoor command & control. These are some of the things that cause the above statement to be the straw that breaks the Agile camels’ back.

While I’m not saying that the development team needs protection from stakeholders (to be fair, the stakeholders need protection from the development team), stakeholders should consider estimates from the development team as non-binding. Estimates are, almost always, given in silo, not taking into account the dependencies and the current backlog commitment. The PO holds the central responsibility to ensure efficient output. 

What can you do?

Years ago, when I faced a similar situation, I out-right banned the interaction between developers and stakeholders. Big mistake. This caused a lack-of-faith in the team which severely impacted the outcome — the stakeholders’ confidence in the team to deliver dropped, the faith in my ability to deliver the right solution fell and there was animosity between teams. In hindsight, it would have been better if I encouraged the interaction — the stakeholders should be made aware of the time it takes to develop things. They should also be made aware of the current commitments and then asked to weigh in on the priorities. A strong PO does exactly that — she has to get the consensus on the priority.

Here are the steps:

1. Have regular meets with the stakeholders — especially the pushy ones.
2. Explain the importance of having the delivery pipelines.
3. Imagine with them the impacts of changes in sprint scope. If you have data, compare and contrast the various options and revenue earnings.

The key point here is to encourage friction — don’t shy away from friction. Friction creates conflicts that lead to communication and that leads to happier teams!

5- ‘We’ve launched projects using waterfall methods and it worked! Agile is dead’

Ah… the critic. There is always someone who is either too demanding (‘Agile teams are supposed to deliver whenever & whatever the business wants’) or outright conflicting (‘Agile is dead! We should use waterfall. We can plan better with waterfall’). Silencing the critic is hard, especially when they hold senior positions. Before you go and do that, understand the following:

1. Is your organization mature enough to handle Agile? Remember, Agile is first about “how you think,” and then about “what you do”. Getting people to change their ‘way of thinking’ is far more difficult than getting them to change ‘what they do’.
2. Is there enough support for Agile transformation within the senior stakeholders? Lack of management support is the #3 reason for Agile failure (source).

If the answers to both the questions are Yes, then you can adopt the following:

1. Engage with the critic and understand where there are issues with the current implementation.
2. Identify points of change, bringing equal opportunities on both ends — may be the SCRUM team needs to get better at estimation, while the stakeholders need to get better in knowing what they want.
3. Implement the changes, even if it means there is a slight departure from the values. Remember, we’ve to be flexible if we’re to achieve the ultimate goal. Critics need to be heard. They need to be shown that what they say has importance and they need to also effect a change. The ‘Yes, and…” method of improv works well when dealing with critics.
4. Slowly inch towards bringing in a process that works for everyone.

This process will take months, if not more. Remember to be patient.

The death of Agile is a part of the journey for you and your organization. Agile has to ‘die’ many times before it rises again, in a new way to fit your organization’s mindset. It’ll die a thousand deaths but rise, again and again, each time bringing in incremental change. That is the philosophy of Agile. That is its essence.

Thank you for reading! Has your organization proclaimed the death of agile, yet? How have you tackled it? I’d love to hear your views and thoughts on this!

Learn more about the steps to take for digital transformation here.