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”—Agility has become so ☢ radioactive ☢
Agility has been overused
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 squares into circles and acting like nothing’s wrong: micromanagement, feature slicing, and endless cost estimates—all hidden under a thick layer of Agile concepts. Except that a feature 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: Agility with a Hammer. Someone who understands Agility 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 Agility 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 Agility, 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 Agility.
We can’t do without Agility
Improving software quality requires working on several fronts: Agility and the technical practices that go with it, which are somewhat reductively referred to as Software Craftsmanship. Agility and Software Craftsmanship are inseparable because they emerged together—it was eXtreme Programming (XP) in the 1990s.
Agility 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. Later, 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 Agility makes no sense. A technical coach is necessarily an Agile coach.