Fit-for-purpose means something is capable of meeting its objectives or service levels. It is often assumed that Agile is perfect for everyone in every situation, but that’s not true. Sometimes Agile isn’t what’s needed, or wanted, and forcing it can hurt more than help.

Let’s explore a few circumstances where Agile may not work.

Driven by Policy and Compliance

If you work in a sector (government, banking, insurance) driven by policy and compliance, you know that your hands are often tied. People outside of your business unit make decisions you must comply with. In some cases, it’s the law. You are told what to implement, how, and by when, at least for some things.

I know of an organization that updates its policy and business rules annually so its software systems must be updated to accommodate the once-per-year changes. It is what it is — the scope and timeline are fixed.

This organization is not allowed to deploy a change, get feedback, and make improvements with regard to what features are available or how the system manages the business rules. They might be able to tweak the user interface, but for the most part, the system remains fairly static for the policy year.

An organization in this situation does not need Agile, nor is it allowed to work in agile ways. They shouldn’t pretend otherwise. And no, breaking work up into sprints and increments, writing user stories, or having a continuous integration pipeline is not what it means to work in agile ways. Iteration based on learning is the heart of agile, and there’s no room for that here. And that’s ok.

Governed by Steering Committees

Enterprise IT may want to control the work being done across their organization. They will set up central intake processes to decide what teams should work on, how, and by when.

There may be a sense of strategic alignment governance and ensuring that solutions fit the enterprise architecture. Those are good things, right?

They are if the conversations focus on the problems and opportunities to pursue, but what about when the output of those steering committees is a plan for which software features to build, how, and when?

What happens when these steering committees dictate a delivery date and expect detailed delivery plans managed to with precision?

If your teams feel more like order-takers, accepting feature requests from “on high,” and they aren’t part of defining the problem and exploring the solutions through empiricism, Agile may not work there.

Planned vs. Actual Matters

If your organization, specifically the leadership and culture, puts a strong emphasis on how well it delivers to its plan, then Agile won’t be welcome. You’ll end up doing faux agile.

You may see this under the guise of “predictability,” which means delivering to the plan.

The Agile approach is empirical — do, experience, learn, and adjust. You cannot deliver as planned and iterate the product empirically — it’s a conflict.

You’ll know the importance of this measure by metrics that track planned versus actual. Planned story points versus actual story points delivered. Planned business value points versus actual business value points delivered. Planned features versus actual features delivered. You get the point.

Organizations focused on planned vs. actual as a measure of value delivered may not be delivering the value they think they are.

Predictability sounds like something you’d want, but the next right thing isn’t always the next thing in the plan. Agile is about quickly testing assumptions to learn and iterate. You can’t predict what that will be, so predictability is solely about delivering to the plan.

Who cares if you estimate doing 50 story points and you deliver 50 story points if what you deliver doesn’t help you achieve the business outcomes? It’s a watermelon metric — seems green on the outside, but likely red on the inside.

 

Forcing Agile Doesn’t Help

I know of an organization driven by policy and compliance that implemented the Scaled Agile Framework (SAFe). Let’s call them something clever, like Org1.

SAFe helped Org1 to be more organized and consistent in their projects. They chose SAFe to be agile. That didn’t happen (it can’t) but it did improve how they manage their annual changes.

I know of another organization, Org2, that has spent at least the last two years working toward a centralized intake process, complete with steering committees, to control the work that comes into its teams.

The teams can iterate on the smaller details but have no say in what big objectives they spend their time on. These teams follow Scrum, Kanban, and SAFe. Many can deliver several times per day — they call that agile. The budgeting process and the promises leave little room to deviate.

In the Forbes article, “Understanding Fake Agile,” by Steve Denning, he notes that, “There is a risk that SAFe is discrediting genuine Agile.”

Matthias Orgler writes that SAFe is not Agile, but it might still be useful. He notes that “SAFe seems to have been invented to get a foot into the door of these waterfall corporations: it appeals to them because it looks like the processes they’re used to, but at the same time it gives permission to sneak in a seed of agility.”

Matthias hits on a point I made in my book as well as my blog, “The Unintentional Intentional Distortion of Agile.” In getting that proverbial foot in the door, compromises are made, which become the norm. It’s faux agile.

 

Final Thoughts

Agile is probably the answer to most work. In most circumstances, we want to continuously pursue better ways to discover and deliver the next right thing. We may have cultural roadblocks, process issues, and a lack of technical building blocks, but that’s what Agile coaching aims to fix.

But let’s face it, Agile isn’t a fit for everything.

Sometimes fixed scope work needs to be done on a fixed timeline. You can write user stories, prioritize a backlog, and develop in sprints all you want, but you’re not being agile in that approach unless you can deliver increments for feedback that feeds adjustment (aka learning).

Once you do that, you’re no longer working from fixed scope, choosing instead to pursue the next right thing versus the next thing in the plan. But sometimes you don’t have that option, so stop forcing “agile” practices on that effort and calling it agile — it isn’t.