So, hey. Back in them olden times when architects ruled the world, and methodology was an actual thing – despite nobody having any idea what that meant, and I can tell you that from first-hand experience – there was a way of delivering working software that end users could actually use.
It went un-articulated for decades, until some folk actually articulated it. They gave it a name, and that name was – disappointingly – “Extreme Programming”. To quote from The Hitchhiker’s Guide To The Galaxy when Deep Thought named the computer to solve the meaning of life, the universe and everything that would come after it: “Oh”.
But don’t be fooled by the name. XP is how computer programmers writing software for customers had been winning at writing software for customers for decades. There’s literally nothing new in it. Its brilliance is in how it named the thing those programmers were doing. It gave them form. It gave them voice.
There’s nothing extreme about it. Unless you think that delivering software customers need is extreme.
But since the rise of “Agile”, those software development truisms have been lost in a fog of the same illusion of control that gave rise to the Big Methods of the 1990s. SAFe is just SSADM with agile tinsel draped around it. LeSS is even less than that. Scrum has become a monster, spewing out an exponentially growing army of consultants 70% of whom have never delivered a working software product in their lives.
Cut through all that crap and what’s left is those decades-old insights into what delivers reliable, maintainable working software that customers can change their minds about. And those Big Agile ideas may now dominate the world of Big IT, but teams who dare to deliver working software still cleave to those original insights. There are no shortcuts.