Agile? We Are Doing It Wrong

Whatever your line of work, I’m sure you noticed companies constantly want to earn more. The intuitive way to earn more is to work faster. Produce more in less time, and you earn more for the same time window, right?

As a contractor, I’ve worked with many companies of varying sizes. From start-ups to scale-ups to international corporates, I’ve worked with them all. One thing most of them had in common is they bought into the Agile promise.

The problem is, the name chosen for Agile is unfortunate. It has nothing to do with agility. And so, when companies adopt it, they buy into a fallacy. Agile isn’t about moving faster at all.

To fully understand what Agile was all about, I went to hear it straight from the horse’s mouth. In his book, Clean Agile, Robert C. Martin (Uncle Bob), one of the people behind the Agile Manifesto, takes us back to when a group of passionate software engineers came up with the idea of Agile.

I strongly recommend picking up the book, as it’s a great read. There’s no point in me repeating everything already written there. I will say this, though: every company I’ve worked with that adopted Agile – was doing it wrong.

The key idea behind Agile is predictability. It’s not about delivering as much as one can in a sprint. It’s about producing high quality code over time. The higher the quality, the easier it becomes to maintain the same pace over time. This is invaluable for the business, because it can now plan forward.

Predictability also improves trust and respect between the Agile team and the rest of the business. Estimates mean something, and promises are consistently kept.

To achieve high quality, Agile advocates for some methodologies. I have to say, I’ve not seen those adopted by those same companies who think they adopted Agile. I don’t see enough pair programming, or I see too much pair programming (ahem, I’m looking at you, unnamed car manufacturing company).

I don’t see test driven development (TDD) followed at all. The common excuse is that the implementation is temporary. Of course it is. That is the nature of software. Surely this can’t be an argument against writing tests that will evolve with the code. This usually suggests the mindset is of tests being second-class citizens.

Not following core Agile ideas leads to lower quality code. Combined with a misunderstanding of what Agile is and what it’s there for this leads to unpredictable results. The business looks at these results, and declares the Agile experiment a failure. Everyone loses.

I don’t know who needs to hear this, but Agile is not about moving quickly, despite its name. This does not mean it’s not valuable. It’s just different value from what you’d expect.

_{I may get commissions for purchases made through links in this post.}