Radicalism as a guiding principle
Radicalism is the refusal to distort words, and thus the refusal to water things down. It is divisive, of course, but that is for the best.
I readily describe myself as a radical. What does that mean? Can we work together?
Words have meaning
“Radical” refers to the very essence of things. Radicalism, therefore, begins with the refusal to distort an idea. And to do that, it’s usually enough to simply listen to the word itself. Example: Agile.
Long before the advent of software, “agility” referred to the ability to move with ease. The founding fathers of Agile did not choose this word by chance. The idea was indeed to foster new practices better suited to promoting this quality within IT systems. So if you’re absolutely determined to practice Agile by drafting a 1,000-page requirements document, quantifying every detail, and setting off full of optimism for two years of development, go ahead, my friends; I won’t stop you. Just don’t call it “Agile.” Instead, call it a “good old-fashioned project, the way we’ve always done it”; I’ll survive!
The same goes for Test-Driven Development. You can twist it any way you like, but it’s not “Test-First,” much less “Test-After”; it’s not even “writing tests at the same time as the code”; it’s a development practice. Test-Driven Development. It’s right there in the name.
The same goes for DevOps practices: if someone on a team is doing nothing but Ops, that’s not DevOps. You’re missing the point, since the whole idea is that Ops expertise spreads throughout the Dev team. Call me nitpicky if you want, but that’s exactly what the term itself says: Dev-Ops.
Say no to the wishy-washy middle
Radicalism, then, is the refusal to water things down. I prefer a clash of clear ideas; something will always come of it, provided the conditions for debate are met. Agile vs. the V-Model? Let’s talk about it! As soon as we give our brains a little workout, interesting nuances emerge: 1. It all depends on the context: business IT isn’t the same as embedded systems; and 2. It all depends on the size of the projects: one week isn’t the same as one year. These are obvious points that we actually don’t hear mentioned very often.
On the other hand, following the V-Model and disguising it as an “Agile project” (a contradiction in terms) prevents you from identifying the problem, and thus from thinking it through. In other words, it’s denial. It’s hard to make progress under these conditions.
What, then, should you say to a team that genuinely wants to use the V-Model when the project isn’t suited to it? It all depends on your role (manager, coach) but also on how critical the project is. In some cases, it might be best to let them experiment, provided there are no serious consequences, and see together what turns out to be a mistake… or not. Someone might be right, but that’s not the point. What matters is that you’ll all come out of it better for it, because you’ll be wiser.
Discuss, debate, experiment, all of that, but please, don’t wallow in a lukewarm middle ground. For heaven’s sake, don’t do fixed-price sprints (just writing that makes me lose health points).
Get to the root of the problem
Radicalism, ultimately, means daring to confront the root causes of a problem rather than endlessly mitigating its consequences, like Sisyphus.
Take quality issues, for example: yes, you can set up a battery of output KPIs, but you’ll only end up stressing your teams by pointing out that nothing is going right (“yes, we know that”). You can also deploy an army of testers, but their work will essentially consist of playing catch-up, since bugs will continue to pour in. Or you can tackle the root causes of the problem, namely, development and testing practices, and, well before all that, functional design. In other words, you can’t separate “doing” from “doing better.”
Speaking of root causes: “You cannot solve a problem with the same thinking that created it,” said Albert Einstein (apocryphal quote). This means that your corporate culture must change, which sometimes even involves changing the people. Training helps, but let’s be honest: you can’t make a racehorse out of a donkey… Especially since someone may have been the right person at a given stage of the company, during the bootstrap phase, for example, but may no longer be the right fit when it comes time to move on to the next phase: scaling up. Keeping that person in their position does neither the organization nor the individual any favors. I often observe a certain loyalty on the part of the CEO toward employees who have been with the company from the start, even when the circumstances have changed. I understand this loyalty, but I believe it holds you back.
A contract for working together
Radicalism, therefore, implies courage and boldness. The boldness to aim high, to be ambitious. If we don’t strive to do very well, we don’t strive to do better, and we no longer strive to do well at all. No, perfection isn’t a dirty word, as long as continuous improvement brings us closer to it day after day.
This radical stance is divisive, and that’s for the best: by distancing myself from organizations I couldn’t possibly work with, it brings me closer to healthy organizations that are genuinely eager to change. That saves time for everyone. Let’s just say that this radical stance serves as a contract between us.