The 4-isms of Agile Failure

There are three anti-patterns the Agile hates, a fourth that is detestable. Below I describe each, and their telltale signs.

I’ve observed no small amount of digital ink this past year fuming with frustration about the failure of Agile. 18 part tweets, ranting podcasts, and War and Peace sized blog posts leading me to hypothesize that many of these failures have some or all of their basis on the following four Agile anti-patterns:

Cargo-cultism

This is the least mature of these destructive behaviors whose concept and name is derived from a 1957 article by Judy Inglis in Oceania titled “Cargo Cults: The Problem of Explanation.”

Refactored for Agile, cargo cultism is a belief system among relatively inexperienced software development organizations characterized by the blind inclusion of artifacts and activities without understanding the reasons behind them.

How do you know if you’re part of a Cargo-cult?

One example might be the insistence of a four-hour Sprint planning session for a two-week Sprint for no other reason than the Scrum Guide suggests “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint” as if the time box facet of this gathering is the key to planning success.

Another example might be organizing only in 6 member developer teams — regardless of need — because the Scrum Guide suggest “Fewer than three Development Team members decrease interaction and results in smaller productivity gains … Having more than nine members requires too much coordination” as if splitting the difference is the key to a highly effective team.

One final example is in those organizations that ‘install SAFe®’ in the hopes that its ceremonies lead to “… early and continuous delivery of valuable software.”

Hyperscrumdamentalism

Second on the Agile immaturity anti-pattern scale, hyperscrumdamentalism differs from cargo-cultism in that it afflicts experienced Aglistas who replace naiveté with religious zealotry.

For example, while hyperscrumdamentalists understand the reasoning behind various rituals and reporting, they’ve lost their way in that they now only see Agility happening through the devout practice of Scrum. Some go as far as to call those engaging in Kanban, Crystal Clear, or XP as heretics who should be shunned from any further contact with their teams.

How do you tell if you’ve been afflicted with Hyperscrumdamentalism? Here are just a few of the revealing symptoms:

• You pitch a royal fit if a developer doesn’t create a task in JIRA to fix a typo in a README.md.
• Your place blue painter’s tape on the floor with team member’s names on them so that stand-ups are consistent and orderly.
• You hear yourself name-dropping ‘Bob Galen’ or ‘Alistair Cockburn’ as one might cast a spell or invoke a magic incantation.
• You find yourself in HR after freaking out because you ran out of powder pink PostIt notes used to demark a DevOps related story.

Command-and-Controlism

This is yet another anti-pattern sometimes born out of equating Scrum with Agile or leaning on orthodoxies such as SAFe® because of their appeal to those comforted by Waterfall or RUP-like rituals and traditions. Such circumstances resulting in the unintended consequence of canonizing a self-destroying ‘crack-the-whip’ power dynamic.

Regardless of how it comes about, when it happens self-organization can no longer occur because the practices preached and codified in certification mills that focus on optimizing along complete and total resource utilization or upstream performance monitoring. A highly descriptive analysis of this is found in the blog post of yet another Agile signatory, Ron Jeffries, titled ‘Dark Scrum’ where he writes:

“Fortunately, Dark Scrum has power holders, Product Owners, and stakeholders for this effort. They make sure the programmers are made fully aware of how badly they’ve done. That will surely inspire everyone to do better next time. To help with that, we have the Sprint Retrospective!”

What are some other signs of Command-and-Controlism?

• Definition of Doneness that goes well past the recommendations of the Scrum Guide, and instead takes on the appearance of an IEEE Standard 830–1993 Software Requirement Specification.
• The insistence that multiple teams of varying skillsets and geography all size stories along a common standard; one that is usually based solely on time. Moreover, never, ever, EVER discuss nonsensical notions such as #NoEstimates when it comes to story sizing.
• The treatment of product roadmaps as Gantt and PERT charts, with supporting backlogs taking on the appearance of a WBS.
• Finding more value in processes and tools than in individuals and interactions.

Agile Scapegoatism

The highest level — or perhaps we should say lowest — of failed Agile-ism anti-patterns is the one that rears its ugly head to blame others. Sometimes this is a result of an organization, teams, and/or individuals having experienced its way through the prior three dysfunctions. Sometimes it’s just easier to toss Agile under the bus by blaming it for systemic issues that are outside of the practice of Lean, Design Thinking, Scrum, or any other associated framework or approach; such as pride, envy, wrath, sloth, greed, or gluttony.

Some examples include blaming agile when it’s …

• … the product person who fails to support the question “What outcome can be delivered in the increment resulting from the upcoming Sprint?”
• … the team who fails to answer the question “How will the work needed to deliver the desired outcome be achieved in our next increment?”
• … everyone who thinks it’s someone else’s job to write stories, test features, and/or facilitate rituals.
• … the managers who treat sprint commitments as one would an old project plan, demanding detailed explanations or RCAs to let the team know that failure and schedule slippage will not be tolerated, regardless of learning, dependencies, or unknown knowns encountered by the serfs at the ground level.
• … the stakeholders and sponsors who fail to equip their organization with the tools needed to “… uncover better ways of developing software by doing it and helping others do it.”
• … anyone who “blames the snake” of Scrum, SAFe®, Kanban, XP, .etc instead of actually engaging in emotionally intelligent self-retrospection.

The only cure for this is to quit blaming the hammer for those times you hit your thumb.

Thoughts?

Again, the opinions expressed on this blog are entirely mine. The observations above are based solely on several months of ingesting all sorts of “Agile makes no Sense” or “Why Scrum Sucks” type thinking on channels such as Medium.com, Slack, Twitter, and elsewhere.

As I’m of the personal opinion that the fastest way to change is to deal with the person in the mirror first, I’m hoping my enumeration of the 4-isms of Agile Failure will help us all engage in some healthy self-reflection and refactoring of what’s doesn’t work … while celebrating what does.

YMMV