"'Show me someone who understands both product strategy AND delivery execution,' an executive challenged me. 'They're fighting over handoffs instead of collaborating on outcomes. How do I fix this without hiring an interpreter?'"

This conversation captures exactly what's wrong with our industry. While certification bodies debate methodology purity, executives are dealing with the real cost of siloed thinking—teams that can't collaborate across the product-delivery divide.

The Reality Check

While certification bodies debate methodology purity, organisations are asking simpler questions:

• Can we plan releases without three-month ceremonies?

• Can we deliver predictably without religious adherence to frameworks?

• Can we focus on customer value without joining a methodology cult?

The Pattern I Keep Seeing

After speaking with hundreds of change program sponsors and agile practitioners, I hear the same story repeatedly. There's a dangerous categorisation happening: humans quickly box people as "purist agile" or "not properly agile."

Most sponsors are genuinely worried they'll be called out for "not being properly agile." They become hesitant to bring in help, fearing dogmatic adherence to immutable agile laws. So they waste time, money, and staff goodwill politely waiting for the agile evangelist to finish their transformation sermon, then continue searching for what I call "the middle way."

For capability leaders: You're caught between executive pressure to both improve productivity and uplift staff engagement, while dealing with teams seeking autonomy, workplace flexibility, and purpose. You need training that delivers results while engaging your people, not compliance theatre that satisfies no one. Your teams need skills that work in your organisational context, not textbook examples that assume you can redesign your entire operating model.

The Middle Way Opportunity

The extremes of opinion often obscure the truth: the best, most appropriate solution to organisational delivery challenges usually lies between the extreme propositions. Not pure framework installation, not complete methodology rejection—but thoughtful adaptation.

I've built my business in this middle ground. It's pragmatic, prudent, and respects where people actually are. We start there and journey forward together, looking ahead as far as they can see in this moment. (This is exactly the approach we're taking as we build something different - integrating product and delivery skills without the framework dogma.)

This sounds like common sense, so why hasn't it caught on?

Why Frameworks Became Popular (And Why They Don't Always Work)

Let's be fair: SAFe and Scrum gained traction because they solved real problems. Scrum brought discipline to chaotic development processes. SAFe provided enterprise-scale coordination that waterfall couldn't deliver. Many organisations genuinely benefited from adopting these approaches.

The challenge? Success bred orthodoxy. What started as helpful frameworks became rigid prescriptions. "Do Scrum properly or you're not agile." SAFe's answer to scaling agile became "launch an agile release train and conduct PI planning."

To be fair, this isn't the framework owners' fault—it's how they're implemented. But I'd argue there's a better way to avoid these framework problems: don't use a framework at all. Build competency instead.

The Framework Dogma Problem

Because of rigid adherence to framework orthodoxy and a shortage of experienced, agnostic specialists who have actually tried, used, and worked across multiple frameworks. Most practitioners haven't developed the lived experience to pull selectively from each approach and apply chosen elements into bespoke solutions that fit current context.

What Each Approach Actually Delivers

SAFe Reality:

• Promises: Enterprise-scale transformation

• Delivers: "Install our 200-page operating model"

• What organisations get: More meetings, same results

Scrum Alliance Reality:

• Promises: Team agility and customer focus

• Delivers: "Do our ceremonies or you're not agile"

• What organisations get: Zombie scrum or agile theatre—the "hard" decisions avoided

ICAgile Difference:

• Promises: Competency-based thinking that adapts to your context

• Delivers: Skills that work in your actual organisational reality

• What organisations get: "Finally, a pragmatic approach to delivery that doesn't require me to join a cult"

Here's the truth: any framework can deliver great results. But I would argue an expert-level agnostic change agent/consultant is mandatory to get the best out of any framework—or an ICAgile approach. Because even if you take SAFe as your end state, you still have to start where you are and work forward.

Why we chose ICAgile over frameworks: ICAgile teaches competencies, not prescriptive processes. Instead of learning to implement someone else's operating model, you learn to think and adapt. The difference is whether your guide understands multiple approaches and can adapt the journey to your reality, or whether they're religiously committed to one path regardless of your context.

The Practical Truth

Most organisations don't need perfect methodology compliance. They need professionals who can:

1. Identify what's worth building (product thinking)

2. Plan it reasonably well (delivery discipline)

3. Hit dates they can defend to leadership (predictable execution)

4. Adjust when reality inevitably intervenes (pragmatic adaptation)

Why This Matters Now

The market has moved beyond framework wars. Organisations want delivery professionals who can blend product strategy with execution rigour—without requiring organisational transformation to match their certification syllabus.

The Bottom Line

Your career won't be built on perfect framework implementation. It'll be built on consistently helping organisations deliver value with reasonable confidence and minimal drama—starting where they are, not where frameworks think they should be.

We're building the training we wish existed - product thinking + delivery discipline, no framework dogma required. Want to see how it's taking shape? [See what we're building].