February 20, 2019

...Learn TDD with Codemanship

A Tale of Two Agiles

There are few of us left who rode the first wave of what we now call "Agile Software Development" who don't think something has gone very wrong with "Agile".

At the tail-end of the 1990's, it was all about small self-organising teams working closely with their customers to rapidly evolve working solutions and deliver value sooner and more sustainably with technical discipline. Extreme Programming, for example, represented a balance of forces - people, process and technology - all of which had to be addressed to produce valuable working software that met customers' needs today, tomorrow, and on the N+1th day.

Since the signing of the Agile Manifesto at Snowbird, Utah in 2001, that balance has been slowly drifting further and further off-kilter, towards Process. Today, Agile is almost unrecognisable from the small, adaptive set of values and principles celebrated in the manifesto.

Big Process once again dominates. Values and principles be damned. The micromanagers who made teams' lives hell in the 90s are back with new job titles like "Head of Agile", "Head of Delivery" and other heads of things nobody envisaged you could possibly need a head of in 2001.

"Product Managers" act as the new chasm between developers and customers, who are as far removed from each other as ever they were.

Small teams are now organised into major programmes of change and "transformations" under the kosh of "scaled Agile" processes that attempt to achieve conformity where none is either desirable or, frankly, possible. Among the most experienced dev practitoners, they have little credibility. By what magic have the scaled Agile wizards solved the problem of large-scale software development? The answer's simple: they haven't. The problem they have solved is how to make Big IT money from something that's supposed to be small.

And the technical side of it is all but forgotten. I recently reviewed more than 100 CVs for an "Agile leadership" role a client was advertising. More than 70% of candidates had never written code. Most of the rest hadn't written code in more than a decade. Pioneers of early lightweight methods were always clear about this: decisions should be made by people with the necessary expertise and experience to make those decisions.

Meanwhile, armies of "Agile Coaches" - who are also mostly without technical experience - guide development teams in the prescribed process. Agile "maturity models" abound. It's big business now.

And for every 10 Agile coaches, you might find one developer guiding teams in the technical practices. Teams get very little help in things like unit testing, TDD, refactoring, CI/CD, architecture & design, etc. I think, from my own experiences working in this space, this is because most managers are from non-technical backgrounds and find things like Scrum, Kanban and SAFe accessible. They see the value in them. They don't understand code craft, and don't understand the value in it. So they don't invest anywhere near as much in it. Our people-process-technology tripod tries to walk with one leg much more developed than the other two, and tips over.

The upshot of all this is that we're back where we started. Oversized teams (and teams of teams), micromanaged in deep command-and-control heirarchies, measured by arcane heavyweight processes. All the emphasis is back on "Did we do it the right way?", and "Did we do the right thing?" is as immaterial as it was when the Unified Process ruled the waves.

None of this would be a problem if organisations also invested seriously in the other 2 legs of the Agile tripod, especially their People.

None of this would be a problem if every non-technical Agile manager or Agile coach was balanced with an equivalent technical manager or coach.

None of this would be a problem if we could get back to the original vision of small, self-organising teams working directly with customers to solve problems together.

I'm not saying everyone involved has to be a software developer. I'm saying organisations need to restore the balance between those forces to succeed at "delivering sustainable value" through software (to borrow the vernacular).

Whatever it is successful dev teams are doing today, I'm loathe to hang the label of "Agile" around its neck. In 2019, that might be considered an insult.

Posted 1 month, 2 days ago on February 20, 2019