Agile: Embrace the Philosophy, Not Rigid Framework Rules

Staying strictly fixated on any Agile framework and enforcing written-in-stone rules by the book is inefficient.

“Pure Scrum/XP/Kanban is the way”

Well, not necessarily. While all these are valid methodologies, they are not the only way.

I’m a strong advocate of the Agile philosophy¹; however, Agile frameworks and the rules that come with them are just tools. The key is the philosophy, not the rigid framework.

In this post, I share my views on following Agile Frameworks from my experience, and why adapting is crucial instead of blindly following a set of rules that may not apply to every situation.

There’s No One-Size-Fits-All Solution - Every Team Is Different

No single framework can optimally solve every problem.

While there’s a foundational core that’s similar for all teams, there’s always something that differentiates one team from another. It could be size, the type of product they work on, the people involved, their setup, etc.

The execution process should reflect and adapt to these elements.

The rules should be strict enough to enable alignment but the teams should have enough autonomy to apply what works for them.

Evaluate Whether All Rules Are Valuable for You

I’ve been in the Agile game for a while now, and I’ve spotted some patterns that pop up when teams follow frameworks too rigidly.

I’ve seen this mostly with Scrum, but I bet you could find examples in all sorts of frameworks that can end up working against you.

Fixed, long, regular meetings

One of the biggest headaches I’ve seen (and felt) with blindly following Agile frameworks by the book is the fixed allocation of long regular meetings.

I’m sure for some it’s great, but for most? Not so much. Don’t get me wrong, setting aside time for time-boxing can be a lifesaver.

But sitting in a long meeting when you’ve got more pressing stuff to do, just because the framework says so? Not cool.

Process over common sense

“Write a ticket for fixing that 2 min typo commit in the README.md file”

Nope. Go ahead, arrest me, Framework police.²

The WIP limit is reached. We are now blocked by an external team. Let’s wait for two days until they fix it because the limit is exceeded.

Sigh

Unfortunately, this is far too common. Engineers can get fixated on the process and lose sight of when it makes sense to bend the rules.

I’ve fallen victim of this trap, and I’ve observed other people falling for this usually in the early stages of applying a new process or in their junior years.

This might sound philosophical, but almost every rule should be breakable under the right circumstances.

Experiment and adapt - Be Agile on how you follow Agile

In fast-paced environments, what you really need is the ability to adapt efficiently without messing up your team’s groove.

I’m not talking about total chaos situations where you’re constantly duct-taping everything - in that case, you’re dealing with something much more problematic.

Even in healthy business-as-usual environments, strict processes can be inefficient. Regular, long “proactive” meetings can break the flow and inhibit the productivity of the team.

Your execution process should also be part of a feedback loop.

1. Try the approach
2. Assess what’s working for you and what doesn’t
3. Adapt to your needs
4. Repeat

Beware! Be pragmatic, not a rebel

Whenever I share this opinion, I feel the need to set some boundaries. To avoid sounding like I’m saying, “throw all the rules out the window!” and to prevent others from doing that.

We’ve all had that one colleague who’s against any kind of process and always focuses on the negatives.

Master the rules, then break them

Being pragmatic and adaptive doesn’t mean working with no rules at all. You do need some rules.

Let’s be real, frameworks are extremely useful. Especially the ones that have been through years of research, experimentation, and real-world testing. They’re goldmines of knowledge, and there’s careful thinking behind each part of the framework.

Before you start doing your own thing, you need to really get why the rules are there in the first place. Remember, everything’s a trade-off.

Choosing to stray from the letter of the framework is way different from just ignoring it out of ignorance.

Don’t be the reckless cowboy. Please.

If your team has agreed-on rules, stick to them.

You can (and should) challenge rules you don’t agree with. But even if you’re not a fan, follow them while they’re in place.

Having everyone on the same page is way more important than you might think.

You’re part of a team. Doing your own thing in a way that goes against how your team works isn’t cool. Show why something’s not working, back it up with examples and data, but while you’re doing that, stick to the plan.

You might be missing something you don’t know about. Often, there’s a good reason things are the way they are.

Conclusion

Agile frameworks are great tools, but they’re not sacred.

The essence of Agile lies in its philosophy, not rigid adherence to a specific framework. To truly embody Agile, experiment, assess, learn, adapt, and repeat. Finding the balance between structure and flexibility is crucial.

Embrace the core principles, be willing to adapt, and remember that the ultimate goal is to enhance your team’s efficiency and effectiveness.

References

1. Manifesto for Agile Software Development ↩

2. Agile Project Management with Kanban By Eric Brechner, Book ↩