Demystifying ‘Agile Police’: Empower Your Team Now!

“That wasn’t in the brochure”

In a world filled with unaccredited certifications, ambiguous frameworks and cult-like worship of prominent figures, it’s easy to get swept up in the confusion about what Agile is. Even worse, there are many people taking opinion as gospel and denouncing others for not walking the same path, including many prominent figures and thought leaders in the agile community.

Within a world of overwhelming complexity, there’s so much emphasis on following a script that we wind up handicapping ourselves from innovating and learning through our customers. But how can we break free from the mould and unlock our true potential when the ‘agile police’ seem to be constantly knocking on our door?

“I’m afraid I’ll have to write you up for refusing to provide an estimate for that user story.”

It’s dangerous to go alone!

One of the biggest things I loathe about agile frameworks like Scrum is the binary nature of adoption they propose. Contrary to the common belief that agile is a perpetual ‘journey’, there are entire communities of people who like to promote this notion that “if you’re not with us, you’re against us.” This fearmongering and conformity then causes a ripple effect in the wider audience that stifles innovation and breeds contempt. We hate where we are, but we’re not allowed to change unless it follows the ancient scripture, so we hate where we are even more.

This notion of being ‘all-in’ to a particular method or style also contradicts the very nature of work today. The Law of Disorder in thermodynamics tells us that we’re facing into an environment that will only ever grow more complex and uncertain. Agile itself was created to embrace this concept, and try to overcome it through constant iteration and improvement. This battle between long-term strategy and short-term tactics inevitably means experimentation and deviating from the norm, and if it works we call it ‘evolution’.

A rose by any other name…

Looking at the other side of the spectrum, there also exists this strange ‘anti-framework’ framework that companies seem to embrace, especially those trying to scale their practices. The Scaled Agile Framework (SAFe) is the epicentre of this trend; people love to hate on it, but they also love to cherry pick all the ‘good’ parts of SAFe and rebrand it to hide their tracks. We don’t run PI Planning, we instead run on a 90 day cycle! We don’t run Agile Release Trains, we have self-contained domains! It doesn’t matter what you call it, and the end of the day it all smells the same way.

However, yet again we seem to land ourselves at an impasse. Should we be honouring the legacy of Agile, and the forefathers that created it? Or should we be encouraging everyone and their mother to create their own fork from the original repository of knowledge? The need for consistency seems to go hand-in-hand with scaled agile, but the impracticality of ‘scaled consistency’ seems to drive it’s own set of antipatterns that leave us worse off than when we started.

There’s still so much to explore

The other-other side of this coin is also the worst-kept secret in the agile world; we’re all still trying to figure this thing out, and no approach is perfect. You only have to look at the Spotifys and INGs of this world to see that any attempt to broadcast a degree of success in the field of agility is met with scrutiny and cross-examination. Some of the greatest minds of previous generations, like Albert Einstein and Stephen Hawking, were forced to conceed that it is impossible to create a general Theory of Everything, and the same applies to Agile. We’ll never hold all the answers, and that’s ok (kinda).

There is, however, a lot of inroads to be made in Agile theory, and it doesn’t take a lot of exploration to pinpoint areas we can improve in as a collective. Practically all listed agile frameworks focus 99% of their model to the delivery aspect of business, and gloss over equally important topics like ‘how to implement a real customer feedback loop’, ‘iterative product design’ and ‘how to build a sustainable culture and team harmony’. Centre a framework around that and you’ll be on the cover of Agile weekly in no time. (Is that a thing? Probably)

In closing

If you find a technique or process that doesn’t conform to an existing framework but still adds value to your ways of working (customer satisfaction, continuous improvement and team harmony) then go for it. The agile police aren’t knocking on your door, they’re too busy arguing in the comments section on Linkedin.