Extreme Programming attempts to weave together several independently useful concepts into a single paradigm... For that to make sense, the amalgamation of ideas has to be greater than the sum of its parts individually, but it's not clear that this is the case.

TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes, for some types of work which doesn't require deep focus...

It just doesn't work as a blanket 'XP' paradigm because you rarely need all these parts all the time, at the same time. IMO, this is why Extreme Programming lacks gumption as a concept. It feels like a bunch of good ideas thrown together. If there was some kind of synergy between those ideas and practices, the concept of XP would be more important.

As it stands today, everyone is implementing maybe 1 or 2 aspects of XP, but almost nobody is implementing ALL of XP... So nobody can claim that they're adhering to XP.

This is not the same as as 'Agile' because with Agile; the vast majority of big companies are implementing maybe 90% of agile practices, with 70% fidelity... This consistency is enough for companies to identify themselves as 'Agile'. I've worked for many companies which implemented ALL of the Agile practices but not one of them actually implemented them exactly as taught in the Agile Manifesto. I think the closest one I worked for was maybe 90% of the way there; they even followed the story point system exactly and used a packet of cards with numbers on them to allow people to vote during Sprint Planning meetings... but anyway, pretty much all the companies/projects I worked for identified themselves 'Agile' because all the practices fit into a single paradigm and there was value in adopting all of them. After a while, it became easier for project managers to just say "Let's switch to Agile" instead of saying "Let's time-box our development work into short increments, with a planning meeting, refinement meeting and retrospective meeting for each 2-week increment."

That's why the XP book arranges itself into values, principles, and practices. The best line in the book is about how practices without underlying values are dead, while values without practices are wishy-washy abstractions. What he's really advocating for at the highest level is skilled teams, who are given ownership, that are actively defining their own processes, and executing them with discipline to produce well-designed and reliable software. The book is a "grab bag" (very legitimate point) because those are the sorts of techniques that those kinds of teams use.

>TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes

For production code I do pretty much all of these, always - at least insofar as it is possible (e.g. willing pairing partner).

Im curious to know under which scenarios you think im doing something wrong. Coz I dont think i am.

Agreed, we’ve come a long way since the dogmatic agile of the 90s, and maybe I could be more explicit that this is about introspecting how you’re delivering software (now AI-enabled workflows are everywhere) to decrease the probability of only increasing output (rather than increasing the probability of outcomes) for your users… XP is a good place to start (but not necessarily end).