Danger zone

Have mercy on me, O God, in your love, According to Your great mercy, forgive my sin. Wash away all my sins, Cleanse me of my offense, Forgive me, Lord, for I have sinned: I’ve done some Agile coaching.

Because, yes, these days, it’s better not to call yourself an “Agile coach”: Agile has become so ☢ radioactive ☢

Agile, watered down

Oh, it sounded great in theory. It sounded so great, in fact, that almost no one understood it.

Which results in (selected excerpts):

• “We’re 200% agile” 🫣
• “We’ve taken the best parts of Agile” 🤢
• “We do Agile on a fixed-price basis” 🤮
• “We do sprints of varying lengths” 🤯
• “We apply the Agile method” 😭
• “We’re looking for an agile project manager” 💩

In other words, we’re swimming in cognitive dissonance. We’re trying to fit square pegs into round holes and acting like nothing’s wrong: micromanagement, splitting work into fixed-price lots, and endless cost estimates, all hidden under a thick layer of Agile concepts. Except that a ticket that takes three sprints to develop is anything but Agile, and it just doesn’t work.

If you have doubts and are asking yourself, “Why?”, I’ve created a training course just for you: Agile with a Hammer. Someone who understands Agile even a little bit would be more likely to say: “We aren’t as agile as we’d like to be, but we’re working on it day after day.”

As Agile concepts have become mainstream, they’ve been distorted, giving rise to “Fake Agile.” The term was coined by Martin Fowler, one of the fathers of Agile, in his opening keynote at the Agile Australia 2018 conference. Here’s a summary of the keynote: “Do whatever you want: I don’t care anyway; I’m off to raise goats in the Ardèche.”

So after throwing the baby out with the bathwater, what’s left? The fact remains that we still need Agile.

We can’t do without Agile

Improving software quality requires working on several fronts: Agile and the technical practices that go with it, which are somewhat reductively referred to as Software Craftsmanship. Agile and Software Craftsmanship are inseparable because they were born together, with Extreme Programming (XP) in the 1990s.

Agile and software craftsmanship are based on the same principles. Take, for example, the importance placed on feedback:

• We don’t want to work for months without user feedback to tell us if we’re heading in the right direction;
• We don’t want to work for four hours without test feedback to tell us if the code works as expected (Test-Driven Development).

And then there’s functional design…

Let’s just talk about Example Mapping. Example Mapping is a simple and effective way to improve the quality of functional design by putting examples back in the spotlight. Because, as we all know, the devil is in the details.

These examples force us to be specific and to explore every aspect of the design without waiting for development to begin. They spark discussion. This way, we avoid a lot of back-and-forth later on. Down the line, these examples serve as acceptance tests, that is, as a contract between the product owner and the developer.

So, is this a practice of Software Craftsmanship—as it’s generally presented—or an Agile practice? It doesn’t matter: in any case, we need to really focus on the quality of the design.

The point is that working on the technical aspects without working on Agile makes no sense. A technical coach is necessarily an Agile coach.