Agile Gatekeeping

It's one thing when agile coaches pipe up with "that's not Scrum," and quite another when accusations of "fake Agile" are thrown around. I find the former irksome, but at least they have a leg to stand on with the 'End Note' of The Scrum Guide in their corner:

"Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." (emphasis mine)

This is why I've taken to calling any more pragmatic approach 'Notscrum.' After all, if they insist that Scrum is 'immutable' (like Plato's heavenly perfections), then clearly what I introduce to teams and use to coach them is a more mutable creature, one that adapts to situations to achieve the dream of Agile.

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

        Individuals and interactions over processes and tools

        Working software over comprehensive documentation

        Customer collaboration over contract negotiation

        Responding to change over following a plan

        That is, while there is value in the items on the right, we value the items on the left more."

                                                                                    — Manifesto for Agile Software Development

The thing is that, as you can see from the manifesto, Agile was made for software development and nothing else. That hasn't stopped it from being embraced beyond that field. In my current work a couple of directs (sequentially) and I have worked to bring archivists and streaming operations teams — as well as a few engineering teams — through agile transformations. All are Scrum...errr...Notscrum teams. They work in two week sprints on stories to which they've applied points and committed to completing within the time allotted. They meet daily for no more than 15 minutes to share what they've been working on and discuss blockers, and at the conclusion of the sprint they meet to close, carry out a retrospective, and plan the new sprint. The ops teams have no Review/Demo because they simply have nothing to demo, as such. They aren't delivering working software and the additional meeting would be of no use. So, it's Notscrum.

I'm sure if I thought about it I could think of more ways we've sinned against Scrum, but why bother? People are collaborating transparently, owning their work as a team, and getting better and predicting what they can reasonably accomplish in their sprints. They inspect, and they adapt. I'm comfortable with that.

Although Scrum, Kanban, Scrumban, eXtreme Programming (XP), Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), Crystal, and Lean Software Development (LSD) and Notscrum all share the Agile mindset, Agile is not limited to any one of these methodologies. So what do we do when someone alleges that something "isn't Agile"?

Ideas released into the world are subject to adoption and reformulation beyond the control of their originators, resulting in diversification that only increases over time. It's practically the same in principle as biological evolution in the natural world. Some of these varieties will be better than others in terms of effectiveness, and there will also be adaptations that live far longer than they should due to sponsorship and the bandwagon effect. This is true of Agile, and we've already seen the simplicity of the manifesto. There are also 12 'principles' included with the manifesto, and these serve as an elaboration on the core perspective of Agile.

Given that Agile was created with only software developers in mind, it's perfectly understandable that when the mindset is brought to other types of work it will take on new forms in its expression. Further, over the course of time, with changing technology and in encountering different office cultures the world over, how people interpret and apply the concepts central to Agile thinking will also vary.

That's why we need to be careful with the gatekeepers.

At the risk of oversimplifying, what I find time and again is that Agilists are divided loosely between purists and pragmatists. The former see Agile and a particular methodology as unchanging. These are the rules lawyers. Once I was describing to an agile coach at a meetup how one of my development teams had changed an aspect of their planning from a generally accepted technique to something novel that really worked well for them. I said it's what the team wanted, and they were happy and productive with it. He snorted and exclaimed, "I don't give a damn what the team wants...they'll do it the right way or not at all!"

Seriously...how do these people find work?

The pragmatists, on the other hand, range from those who are careful to only modify what they judge to be minor points of a particular Agile methodology, to those on the other extreme that slap the 'Agile' label on whatever they're doing, discrediting the whole way of thinking to the uninitiated.

I've encountered two unrelated vendors in the past few years that wanted the 'prestige' of saying they were Agile, and rather than actually learn and practice that mindset, they applied Scrum terminology to their existing processes. That's how I ended up sitting in a dismal project post-mortem called by one of the vendors, pulling in all the stakeholders, that they billed as a 'retrospective.' Oh, and their sprints had all been irregularly-sized, because they sized the sprints to fit the work, rather than the other way around.

And yet, such companies somehow stay in business.

We need a standard as a reference, which we have in such documents as The Agile Manifesto and The Scrum Guide, and well-versed Agile experts can help keep us honest. These are our polar star as we navigate the real world of business and innovation.

At the same time, the cat's out of the bag...and it's having a lot of kittens. While I'm dubious of the details of SAFe, for example, I see value in aspects of its attempt to solve the problem of the tension between the structure of business (often required by the demands of the market and/or industry/regulatory standards) and the fluid but self-coordinated Agile teams. Then again, I could be accused of bias, given my SAFe ® 4 Program Consultant certification. I'm sure I could find worthwhile elements in Nexus, LeSS, or DAD if I could ever find time to look into them in more depth.

Even the signatories to the Agile Manifesto lack sufficient authority to be the gatekeepers of something that is already well beyond their control. The success of Agile is an indication that they did very well in putting forward a statement of concepts that had been brewing for years in tech circles. Let's just not close our minds and fossilize our progress by making imperfect declarations into binding creeds.