The Agile Anti-Framework: Crafting Your Own Path to Value

by Clair Meij

clairmeij@gmail.com

How does this agilist navigate the entrenched structure that is 2025’s world of agility while still believing that rules are meant to be understood well enough to know exactly how and when it’s safe to break them?

As unique and original as I like to think I am, it turns out that this mindset isn't some rogue notion; it's actually baked into the Scrum playbook and intrinsic to the Shu Ha Ri model. Or, more accurately, it's not in the playbook – because those blank spaces are there by design, inviting us to fill them with genuinely meaningful ways of working and delivering value, rather than didactically adhering to a rigid framework. I'll admit, it’s a little annoying that this part of my personal rebellion was, in fact, pre-ordained by someone else. But I digress…

So, here we are. We've cast off the shackles of Agile-As-We-Know-It. What's next?

It all boils down to the "why."

When you free yourself from the confines of a specific agile framework and instead align with the 'why' behind each practice you adopt, you empower yourself to build a stronger Software Development Life Cycle. You're able to leverage the most effective and applicable solutions for the problems you're tackling. And while the outcome will almost certainly be agnostic to any single agile framework, it's often more robust and resilient. Why? Because you’re crafting the framework to fit your needs, not contorting your business and technology teams to fit a one-size-fits-all model. This is precisely where an experienced, battle-scarred agile practitioner becomes invaluable. Someone who has wrestled with (and sometimes been forced into) countless different practices, frameworks, and yes, processes, can pinpoint which solutions truly apply to which problems, all while staying true to the agile mindset and delivering real benefits for both people and the business.

To dive deeper into Mike's "Slowing Down to Speed Up" philosophy, I’ll focus for a minute on the practice of refinement. This is a practice I've found utterly indispensable in every software delivery team I've ever worked with. While it goes by the same name from company to company, refinement should always be implemented in a way that provides measurable value and clear, tailored guidelines for the specific delivery teams it serves.

There's a common misconception that "just in time delivery" means we skip upfront planning. Quite the opposite! The teams that truly excel at "just in time" delivery are those who've done the crucial preparation work upfront, proactively clearing any apparent blockers to their flow. And no, that's not waterfall thinking. That's simply practicing excellent flow management and unleashing true agility within your teams. Slowing down here really does help you speed up further down the road.

A few years back, I worked with an incredibly talented team on a project that delivered a massive chunk of value across numerous, highly interdependent teams in a matter of weeks. How did we pull it off? By being meticulously prepared, excessively communicative, and frankly, over-indexing on proactively addressing anything that could impede our progress. That meant a ton of refinement sessions, full team retrospectives, a shared understanding of what "ready to work" truly looked like, and a healthy tension between Product, Design, QA, and Software Engineers. This ensured that everyone had what they needed to hit the ground running. And then? Then, they flew! It was truly magical to witness.

Refinement doesn't have to be a face-to-face meeting, but it absolutely demands full team and cross-role engagement and collaboration. I've seen this vital ritual performed asynchronously, in person, in small daily chunks, or as the more common regularly calendared meeting. The latter, I highly recommend for newly formed teams so that they can learn as they engage with the practice. In every single one of these scenarios, I insist that the entire delivery team is part of the practice. The 'why' here is straightforward: to ensure that work items are "ready to be worked." Removing blockers and fostering a shared understanding so that dependencies and test strategies are crystal clear can prevent endless additional research throughout the development phase. Using INVEST criteria to ensure that the work is understood, unconstrained, and testable. While many huddles during a development cycle can be helpful, they can also signal a team that didn't prepare together and now needs to slam the brakes mid-implementation to figure things out. Monitor this, evolve together! Don't ever stop striving to get better.

A clear and shared Definition of Ready (often affectionately called DOR) is yet another prime example of how aligning on a shared understanding can create a space that truly liberates smart people to do the meaningful work that we hired them for. This becomes even more critical with the rise of AI story mapping, where human refinement will be essential to ensure understanding and alignment of nuanced requirements that AI might miss.

Preparation isn't the antithesis of agile; it's what enables us to practice agility. It's what gives us the ability to pivot before we've sunk too much time and money into developing something that might not actually deliver the expected value.

So we don’t ‘do agile’ simply because we’ve chosen to work in an agile way. We use agility in ways that solve our software delivery problems. Rather than simply hanging process on frameworks because those are the rules, we deeply understand why those solutions work to solve the unique challenges that software delivery teams face.

Ultimately, breaking free from rigid frameworks isn't about chaos; it's about intentionality. It's about empowering teams to truly practice and benefit from agility, to adapt and optimize, and to deliver real value by focusing on the 'why' rather than blindly following a 'how' that doesn't always fit. Embrace the rebellion, understand the rules, and then, confidently decide when to break them to build something stronger.

Take good care, and let's keep iterating together.

Clair 

clairmeij@gmail.com

About Clair Meij: As an experienced agilist, my core mission is simple: deliver results and cultivate healthy, sustainably-paced teams. In our ever evolving world of software delivery, I firmly believe agilists must dive deep into the "why" of diverse frameworks and practices, then become truly agnostic. It's about expertly tackling business challenges, not rigidly applying a one-size-fits-all framework.

You can often spot me in my trusty Dr. Martens, a constant since '93 (fashion trends be darned!). Beyond my iconic boots, my life revolves around embracing growth, innovation, and positive change. My personal mantra? “If you haven’t changed a major opinion in the last 5 years, check your pulse, you may be dead.” (Often attributed to Galett Burgess)

Growing up as the eldest of four across England, South Africa, Malawi, the Seychelles, and Uganda gifted me a wonderfully weird accent and a practical education in dismantling and rebuilding. This journey instilled a deep love for improving systems and structures by empowering smart people to catalyze meaningful change. I'm always asking, "But why (not)?" and "What would happen if we just tried?"