Avoid Arguing About Agile

Arguing about Agile is like trying to run in quicksand. You can’t. You’ll just get sucked down into the bog.

There are two big issues at play here: clarity and scope. First let’s talk clarity.

We all agree we need to be “Agile.” The problem is, what does that mean? The Devil is in the details, which Agile doesn’t provide. In a way that’s fine. It didn’t seek to, but as Spencer Pitman recently put it, Agile is so vague a notion that it’s hard to even have a meaningful debate about it. I agree.

This is reminiscent of Charles Betz asking whether Agile might possibly be an “essentially contested concept,” a term the proper use of which cannot be resolved by discussion or debate. Well, if it can’t be defined, then what’s the use discussing it?

And yet we can’t stop talking about it.

Agile dialogue has started to remind me of Karl Popper’s assessment of psychoanalysis. If every instance of it not working is explained away while every instance of it working counts as confirming evidence, then it’s not a falsifiable concept.

And this is the pattern we see time and again: If it “works,” then no matter how custom it is, it’s “Agile.” If it makes things worse, it’s “Dark Agile.” But that’s circular. So again, why bother discussing it?

I recently discussed how several of the Agile Manifesto coauthors don’t even agree on what the word “iterative” means. Jeffries says it means to repeat a process cycle and produce another increment. Cockburn says it means to revisit work already done. Fowler gives yet another definition(!), which is to complete all activities for a feature before moving to another.

Backing up an argument about Agile then by referencing a Manifesto author also isn’t helpful, because they also don’t agree on things.

Ok. Let’s talk scope.

The Agile Manifesto was about software teams, but we’ve long since moved past that. Software teams are often not the constraint in the system. A bigger problem is how decisions get made in the org. Agile, however, excluded design and punted on discovery.

Agile rested too firmly on the fallacious assumption that users can simply tell us what to build. If the “customer” (another loaded, nebulous term) says it’s value, then presumedly it’s value, despite the fact this has little bearing on whether it will lead users to change their behavior in the ways the business actually needs.

There does seem growing appreciation that building iteratively is helpful, yes, but more in the sense of discovering better paths up the hill we’re already on. It’s not as helpful in vetting whether we’re climbing the right hill—that’s a design question.

Design is more about discovering the best problems to solve, something that was outside Agile’s jurisdiction.

Agile was all too happy to let such questions be settled by someone else’s fiat, which sparked the long-running tradition of designers kvetching about Agile.

It’s understandable though. Paraphrasing Boris Anthony, designers have for years now been gaslighted in the name of Agile processes. “Sure,” designers are told by managers and developers, “design is important…it just doesn’t mean what you’ve always thought.”

Also regarding scope, if Agile was about software teams, then what’s all this talk about “org agility?” It’s important, but it’s revisionist history. Not only was Agile never about “business transformation,” but Agile never even provided a viable alternative to the “Waterfall process” it sought to supplant.

These are two of the big reasons why SAFe won The Agile Wars.

First, it offered orgs a viable alternative to their existing process. Second, it actually bothered to define its terms.

OK, there’s a third reason, and it’s part of the sickness Agile should have helped cure. SAFe offered a cookbook, which we desperately desire, whereas Agile, in my opinion, was more about throwing cookbooks out the window.

Tell us what the process is, and spell it out in detail! Marty Cagan famously called SAFe “The Revenge of the PMO.” One might instead call it “Process Strikes Back.” Come what may, you will bend the knee to process. Dealing with this sentiment might be the next big challenge.

Interestingly, Ron Jeffries recently suggested to me that maybe Agile isn’t meant for large orgs in the first place.

It’s an eye-opening remark and parallels something Rob England has said: The challenge isn’t about scaling Agile to the org; it’s to scale the org in order to improve it. The challenge is to change our thinking about what it means to be an org in the first place.

Again, though, here we’ve already moved beyond “Agile.” Instead of perpetually redefining it in attempt to keep it pertinent, we should instead shift the focus to continuous improvement. We need, to borrow a phrase from Dean Peters, less “Scrumfundamentalism” and more “discovering better ways.”

This will shift the focus to the system constraints in place, to how best to provide teams the autonomy and authority they need to make smarter bets to move the needle on target value metrics.

John Cutler has long noted that the teams that are really killing it today don’t sit around talking about Agile or UX or Lean. They just do product work. That doesn’t mean there isn’t any Agile or UX or Lean. Far from it. It got baked in and they had the sense to move on.

So what will happen?

Fashions change. The goodness Agile resulted in will remain. The cottage industry of cert selling will fade.

As orgs move on from spending money on cargo culting practices in the name of “Agile,” discussion of Agile itself will start to wane.

Once something shifts the Overton Window, it’s no longer watercooler talk. As for me, I will help people create value, but I will not argue about “Agile” anymore.

It’s wasted calories.