Agile Suicide

Here's something that doesn't occur often in project management blogs: exploring the potential pitfalls of Agile.

Agile itself is not inherently a flawed methodology... that much should be consensus amongst self-respecting product and project managers alike. In fact, Agile's greatest drawback may be its own success. Because the benefits are (supposedly) painfully obvious, some organizations find themselves looking to adopt Agile with blind faith, perhaps while lacking the reasoning behind it.

While the intentions behind adopting Agile and Scrum methodologies may be admirable, a poor understanding of why these philosophies work can cause the unspeakable: death by Agile.

Circumstances for Failure

The success of any project is dependent on the balance of the big three. Of course, this is referring to the holy Triforce of project management: scope, cost, and time.

As you already know: Scope covers what must be done, Cost refers to a budget and/or resources, and Time can be interpreted as the end deadline.

Companies which experience problems with Agile almost always suffer a deficiency with 2 or more of these 3 pieces. The most common recipe for failure looks something like this:

• An external marketing campaign has determined that the project has a hard launch date (time)
• The company has a fixed number of employees, and can not make a case to allocate additional dollars to the project (cost)
• Stakeholders have agreed behind closed doors that nearly all features must go, with no room for negotiation (scope)

Being completely unable to budge on all 3 fronts is a concern for any development project, but is a nightmare scenario for Agile projects in particular. That's because being locked in to all three parts inherently defeats the purpose of agile, and renders the methodology useless in it's potential benefits, regardless of how hot the phrase is on industry job boards.

Defeating the Purpose of Agile

Running Agile should be a conscious choice to conduct iterative development based on feedback. This is the recognition that our world is unpredictable and changing; what may have seemed like a good product on day 1 will likely prove to miss the mark when it is released on day 14. Running Scrum effectively requires time to gather, implement, and test feedback, only to perhaps return to the backlog... if it remains relevant.

Nobody can predict user, client, or stakeholder feedback, which is exactly why testing in quick 1-3 week cycles makes sense. As an practitioner of Agile you recognize the complexity of human beings. That's why you chose to run agile in the first place. Thus...

It is mathematically impossible to determine what the full scope of an Agile project will be ahead of time, because we cannot anticipate what is coming.

Alas, we now have a team working towards a fixed deadline with an indeterminate amount of scope.

Things Get Worse

The stage is set: a looming deadline arrives, and our project scope has now been expanded to be defined as [originally planned scope] + [all sprint feedback]. What was originally impossible is now a cruel joke; not only is unreasonable to accurately estimate a project upfront, but the project only grows in scope over time as feedback rolls in.

This is where things must end.

In this case, iterative development has set a false precedent with stakeholders. Simply by selecting an Agile workflow, stakeholders are under the impression that their feedback will get implemented (as they should be), yet also believe their original scope is completely unfazed and feasible (which may very well be understandable, assuming the team may have 'agreed' to the set features ahead of hand).

Even without making a single promise, adopting an Agile workflow has set false expectations.

Avoiding The Problem

The exact circumstances outlined here are painfully common. The causes for failure seem obvious from an outside perspective, yet teams scratch their heads pondering "what went wrong" as they lay burnt out in the aftermath. Why does this happen so often?

Organizations adopt new development methodologies while leaving old business procedures in tact.

Most of our idea around locking down budgets and timelines stem from a time when Waterfall was dominant. If we change the philosophy of development without changing the philosophy of the business, we're left with two pieces which simply don't fit.

Take Saudi Arabia for example. The Saudis have a thriving 'economy' but the state itself is in turmoil, because the society necessary to maintain stability did not materialize prior to the accumulation of wealth. If your organization moves from waterfall to agile, yet retains the same processes of funding and green-lighting projects, your projects are going to fail. Worse yet, you won't be rich like Saudi Arabia; you won't be rich at all.

The upside to Waterfall is that the workflow somewhat protects hard deadlines. Waterfall ensures that the approved scope - and nothing more - will included in the release for the target date. The scope is determined upfront, signed off on, and cannot change unless there is an agreement to shift dates.

For this reason, large projects which require Scope X to be released by Date Y should gravitate to a more traditional workflow. Otherwise you're simply adopting Agile to keep everybody busy, without recognizing the devastating effects it has on beloved deadlines.

Final Word

Before setting timelines, deciding on a workflow, or getting estimates, please give full thought as to what you're doing. Is the scope defined by clear, concise tasks? Is there reason to justify an MVP, or quick sprints? Are tasks clear enough for developers to begin estimating?

Knowing the "rules" of product management is the easy part. The hard part is realizing that there are no rules. Every project is vastly unique, and there will never be a single methodology or issue scheme that fits all of them.