Practices That Fit Your Organization — Not Forced Frameworks: A Better Way to Think About Agile

There's a version of 'going agile' that most organizations recognize: a consulting firm arrives, runs a SAFe training, renames everyone's roles, adds ceremonies to the calendar, and declares the transformation complete. Eighteen months later, the teams are more exhausted, the ceremonies are dreaded, and leadership is wondering why nothing actually changed.

I've seen this pattern dozens of times. And in almost every case, the problem wasn't the people. It was the approach.

Agile works. But 'going agile' the way most organizations do it doesn't — because it gets the order of operations exactly backwards.

The Framework-First Mistake

Most agile adoptions start with a framework. Scrum. SAFe. Kanban. LeSS. The organization selects a methodology, trains everyone on it, and then attempts to change how work happens by imposing new roles, ceremonies, and artifacts.

The implicit assumption is: if we adopt the practices correctly, the culture and outcomes will follow.

They rarely do. Here's why: frameworks are designed for specific contexts. Scrum was developed for small, cross-functional product teams working in short iterations. SAFe was designed for large enterprises coordinating multiple agile teams. When you apply a framework to a context it wasn't designed for, you get compliance theater — people going through the motions of agility without any of the actual benefits.

A Scrum ceremony you perform because the methodology requires it — not because it helps your team do better work — is not agility. It's bureaucracy with a new name.

The Outcomes-First Alternative

I believe deeply in agile values and principles. The focus on customer value, continuous improvement, collaboration, and adaptive planning — these are not just methodology features. They're better ways of working, full stop.

But the path to those outcomes is not to install a framework and hope culture follows. It's to understand your current ways of working, identify the specific friction points and opportunities, and introduce practices incrementally — the ones that address your actual problems.

This is the approach I use with consulting clients: Understand, Align, Experiment, Sustain.

Understand

Before recommending anything, I want to understand how work actually flows through your organization. Not how it's supposed to flow — how it does flow. Where do things slow down? Where does quality suffer? Where do teams lose alignment with business priorities? Where is leadership unclear about what's happening and why?

This is data collection and listening — interviews, observations, workflow mapping. It's not glamorous. But without it, you're prescribing treatment before diagnosis.

Align

Agile adoption fails most often not at the team level but at the leadership level. If leadership hasn't genuinely internalized what agile ways of working require of them — including tolerating uncertainty, trusting teams to make decisions, and measuring outcomes rather than activity — no framework will work.

Alignment sessions with leadership aren't about convincing people to be agile. They're about understanding what success looks like, surfacing the organizational behaviors that will need to shift, and building shared language and expectations.

Experiment

Rather than a big-bang transformation, I favor targeted experiments: specific practices introduced in specific contexts, with clear hypotheses about what should improve and a defined period to evaluate.

A team running a two-week sprint for the first time isn't committed to Scrum forever. They're testing whether shorter planning cycles improve their ability to respond to change. If it does — great. If it doesn't, or only works with modification — that's data too.

Sustain

Agile practices that don't have internal champions don't survive. Part of my work is identifying and developing the internal coaches, facilitators, and leaders who will carry the practices forward after the consulting engagement ends. Dependency isn't transformation — capability building is.

What Agile Actually Requires of Leaders

Here's what most framework vendors won't tell you: agile works when leaders let it. And letting it work requires some things that are genuinely hard.

It requires trusting teams to make decisions within their domain — and resisting the impulse to override or second-guess. It requires measuring teams on outcomes rather than activity. It requires tolerating the discomfort of visibility — because agile makes work and problems visible in ways that traditional project management doesn't.

None of that is about frameworks. All of it is about leadership.

If your organization is considering an agile transformation — or is in the middle of one that isn't working — I'd be glad to talk through what's happening and what a different approach might look like. Sustainable improvement always starts with understanding what's actually going on.