Agile doesn’t feel intuitive in many settings because Agile is, focused on sustainability and long-term viability. The benefits are not immediate, and in the short term, you’ll likely experience some discomfort and dissonance. If short-termism is your thing (and to most humans it is), a deep focus on Agile isn’t your best hammer (but some blind sprinting may be).

Agile Makes No Sense

Astute observers quickly realize that agility on the team level is but one part of the puzzle. Even when Agile on the team-level makes sense, you need that other part to make sense. The rest of the org was probably the blocker in the first place.Once you come to grips with the idea that Agile makes no sense, you can start doing a better job of advocating for experimenting with well known Agile patterns.

The challenge of whole-org agility

What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.

Action Time

<img alt="John Cutler" src="https://miro.medium.com/max/500/1*HP7zJEnq-tuDbekIvZvoJQ@2x" width="48" height="48">I’ve spent a good amount of time learning why Agile-inspired patterns “work” — mostly the “hard way” (doing), but also through individual study, group study, conference going, participating in the community, and learning what most decidedly does not work.But it dawned on me recently that to any sane person — without lots of practice doing this stuff in real world settings and seeing it work — Agile makes no sense. Pair? Are you kidding me? Mob? OK, now you’re truly crazy. Release a crappy but usable version of the product in a week? Why? Figure out a near term goal and go — without lots of documentation and planning? That’s insane. Invite customers into the process? They’ll freak out! Let teams self-manage, self-organize, and decide where to focus continuous improvement efforts? Is this Lord of the Flies? Team goals, not individual goals? Are you a socialist? On and on.<figure><img alt="" src="https://miro.medium.com/max/500/1*CQc_XVCqX5TtOgxYQHT0dQ@2x" width="632" height="420"></figure>If it made sense, everyone would be doing it, right?We assume this stuff is obvious and intuitive. It isn’t, unless you’re talking vague high-level/nod-worthy ideas. Take phrases like “Individuals and interactions over processes and tools” and “Make safety a prerequisite”. Both sound reasonable — awesome even — but one person’s lightweight process and “open culture”, is another person’s bureaucracy and culture of fear/intimidation. So you have the challenge of slippery big words.Agile doesn’t feel intuitive in many settings because Agile is, I believe, focused on sustainability and long-term viability (“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”). The benefits are not immediate, and in the short term you’ll likely experience some discomfort and dissonance. A focus on quality, for example, truly pays off when the product becomes insanely complex and you can keep innovating. Shipping tiny increments pays off when the customer is extremely satisfied with the end-result (due to learning and pivoting), not when the customer tries the paired down minimalist version after sprint one and gives feedback. If short-termism is your thing (and to most humans it is), a deep focus on Agile isn’t your best hammer (but some blind sprinting may be).Even when you talk details, there’s just too much of a void in terms of shared understanding (and a dash of cognitive dissonance). I remember mentioning to a friend that I had worked in a company with maybe one minor production issue every quarter/6 months, AND a very successful product. That simply did not jive and true-up with their decade of experience. Something had to explain it: different domains, engineers-they-couldn’t-afford, different technologies, a winning product strategy involving justified cut corners (that eventually tanked), etc. We were literally at a impasse. For many, Agile is doing sprints and using Jira. So, they’re already “doing” it. This other stuff is some sort of fringe cult that only works in blog posts.Next, you have a bucketload of cognitive biases and intuition traps like the impact of high resource utilization, the cost of queues, the differences between manufacturing and knowledge work, etc. (see Don Reinertsen’s <a href="https://www.amazon.com/dp/B007TKU0O0/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1" rel="noopener" dir="ltr">The Principles of Product Development Flow</a> for a non-dogmatic summary of traps). Hint: even when people read this book they’ll know more theory, but be missing a ton of context.Finally, there’s the challenge of whole-org agility. Astute observers quickly realize that agility on the team level is but one part of the puzzle. Even when Agile on the team-level makes sense, you need that other part to make sense. The rest of the org was probably the blocker in the first place.Once you come to grips with the idea that Agile makes no sense, you can start doing a better job of advocating for experimenting with well known Agile patterns. The first step is taking off your Evangelist hat. There’s no sense in evangelizing stuff that makes no sense…you’ll be called a Heretic (and we know what happens to heretics). Same with being an Acolyte. People don’t trust followers of things that don’t make sense. Don’t mention what worked at another company…because “it won’t work here” (and it comes off as standoffish and elitist). Most importantly: flip your perspective from “I’m the one in the know here…they just don’t get it” to “this doesn’t make sense…this is on me.”What can you do?What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.When you take this humble approach — instead of “installing” a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.

I’ve spent a good amount of time learning why Agile-inspired patterns “work” — mostly the “hard way” (doing), but also through individual study, group study, conference going, participating in the…

communication

Communication

product

Product & Design

I’ve spent a good amount of time learning why Agile-inspired patterns “work” — mostly the “hard way” (doing), but also through individual study, group study, conference going, participating in the community, and learning what most decidedly does not work.

But it dawned on me recently that to any sane person — without lots of practice doing this stuff in real world settings and seeing it work — Agile makes no sense. Pair? Are you kidding me? Mob? OK, now you’re truly crazy . Release a crappy but usable version of the product in a week? Why? Figure out a near term goal and go — without lots of documentation and planning? That’s insane. Invite customers into the process? They’ll freak out! Let teams self-manage, self-organize, and decide where to focus continuous improvement efforts? Is this Lord of the Flies? Team goals, not individual goals?Are you a socialist? On and on.

If it made sense, everyone would be doing it, right?

We assume this stuff is obvious and intuitive. It isn’t, unless you’re talking vague high-level/nod-worthy ideas. Take phrases like “Individuals and interactions over processes and tools” and “Make safety a prerequisite”. Both sound reasonable — awesome even — but one person’s lightweight process and “open culture”, is another person’s bureaucracy and culture of fear/intimidation. So you have the challenge of slippery big words.

Agile doesn’t feel intuitive in many settings because Agile is, I believe, focused on sustainability and long-term viability (“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”). The benefits are not immediate, and in the short term you’ll likely experience some discomfort and dissonance. A focus on quality, for example, truly pays off when the product becomes insanely complex and you can keep innovating. Shipping tiny increments pays off when the customer is extremely satisfied with the end-result (due to learning and pivoting), not when the customer tries the paired down minimalist version after sprint one and gives feedback. If short-termism is your thing (and to most humans it is), a deep focus on Agile isn’t your best hammer (but some blind sprinting may be).

Even when you talk details, there’s just too much of a void in terms of shared understanding (and a dash of cognitive dissonance). I remember mentioning to a friend that I had worked in a company with maybe one minor production issue every quarter/6 months, AND a very successful product. That simply did not jive and true-up with their decade of experience. Something had to explain it: different domains, engineers-they-couldn’t-afford, different technologies, a winning product strategy involving justified cut corners (that eventually tanked), etc. We were literally at a impasse. For many, Agile is doing sprints and using Jira. So, they’re already “doing” it. This other stuff is some sort of fringe cult that only works in blog posts.

Next, you have a bucketload of cognitive biases and intuition traps like the impact of high resource utilization, the cost of queues, the differences between manufacturing and knowledge work, etc. (see Don Reinertsen’s <a href="https://www.amazon.com/dp/B007TKU0O0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1">The Principles of Product Development Flow </a>for a non-dogmatic summary of traps). Hint: even when people read this book they’ll know more theory, but be missing a ton of context.

Finally, there’s the challenge of whole-org agility. Astute observers quickly realize that agility on the team level is but one part of the puzzle. Even when Agile on the team-level makes sense, you need that other part to make sense . The rest of the org was probably the blocker in the first place.

Once you come to grips with the idea that Agile makes no sense , you can start doing a better job of advocating for experimenting with well known Agile patterns. The first step is taking off your Evangelist hat. There’s no sense in evangelizing stuff that makes no sense…you’ll be called a Heretic (and we know what happens to heretics). Same with being an Acolyte. People don’t trust followers of things that don’t make sense. Don’t mention what worked at another company…because “it won’t work here” (and it comes off as standoffish and elitist). Most importantly: flip your perspective from “I’m the one in the know here…they just don’t get it” to “this doesn’t make sense…this is on me.”

What is the smallest thing that could add value (and make sense)? A better standup? A better retrospective? Inviting a customer to a demo? Pairing for a day? Agreeing to get something into product in a couple days? Try that. Make one thing make sense as in “wow, I can see how that created value”.

When you take this humble approach — instead of “installing” a bunch of artifacts, tools, roles, and rituals AKA doing Agile — I think you’re embracing the true spirit of Agile.

Agile Makes No Sense