This is the subject of far more knowledge transfer that can be accommodated by a message board post, and a prohibitive time commitment to turn experience into serialized text, but nonetheless…
XP teams are more effective because they understood the holistic side of development, and how development unfolds over time.
The focus of XP teams is the reality that productivity erodes over time due to moment-by-moment iotas of design decisions that weren’t quite right.
It’s about reducing the batch size of quality assurance down to the most microscopic elements of software development work.
And that batch size is indeed moment-by-moment. Meaning: It cannot be scheduled in advance. If you wait to address these things later at a pre-determined time, say, an end-of-day sync-up, the stakeholders will no longer be in-context enough to address the design issues.
When you increase the communications and knowledge transfer batch sizes to the sizes required by the async communications of remote teams, then the design problems do not get fixed. Rather, the become the foundations for the amplification of the problems by building more mistaken design on mistaken design foundations.
XP teams know software. They know software design. They know software process. They understand how future productivity degradation is being created right now in each and every moment by developers who are failing to see the cellular-level mistakes they are making that become the cancer that the whole body is doomed to suffer.
XP is about software. If you don’t really have a grasp of what that means, then you can’t leverage it to your advantage.
I can’t merely put fingers to keyboard to transfer ability at this level. XP isn’t the basics. It’s a basic training program for something far more advanced than the mere practice exercises and mechanical practices of XP.
The ultimate reason why XP teams are more effective is that they want to be more effective, and they don’t allow anything to get in the way of that. They forgo the luxuries and conveniences that many more mediocre teams indulge to the point of entitlement.
But I can’t just give you specific mechanical practices and suggest with a straight face that they’ll make any difference. They’d just as likely turn into cargo-culting, the way that TDD was mechanically cargo-culted in Rails but very rarely was even minimally achieved in Rails.
XP has no easy answers. It’s not just something that can be handed over in text the way that more material concerns can be, like tools, frameworks, patterns, and more trivial methods like Scrum. Only the easy stuff can be transferred from person to person materially. But the really effective stuff has to be gotten by hand by the individual, building on the more concrete and tangible stuff that has been transferred materially.
You don’t get into the major leagues by reading about it. You get there by not seeing direct, moment-by-moment participation and in-person training camp as an inconvenience, but as an honor and as an opportunity for breakthroughs.
You can’t schedule breakthroughs. XP is about being present at the moment that is about to lead to a breakthrough. You can’t be present for that if you’re merely on the other end of an always-on video conference. The amount of interaction required to turn the raw materials of breakthrough into de facto breakthrough is vastly-more than the stark limitations of telecom technology.
You can read about all of the practices of XP in Kent Beck’s short books on the subject. But you still won’t have done more that gather up the raw materials of XP into your mind. Putting it into action is a whole other level of effort and commitment. And if the convenience and comfort of working from home are more important than the breakthroughs that remove the problems standing in the way of our efforts, then all the reading in the world won’t make a bit of difference.
XP teams are effective because they reject the entitlement to complacency. They accept no level of tolerance for flaws - knowing that their compound effects are why software projects become so disheartening that we’d rather just stay home and work from there.
The specifics of XP are irrelevant, though. It’s not a work system that works at a level low enough that merely telling others about practices can change the outcomes.
No one needs me to tell them about XP. You either want it, or you don’t. And if you want it, then you’ll get on it - just like I did, just like every other XPer did.
The reason that you don’t hear much about XP is that it’s only a scant minority of developers who are predisposed to being relentless against flaws. And with the rise of async communication and batch transfer semantics inherent in the work methods being adopted by contemporary teams, we’re headed in the opposite direction to XP at an increasingly faster rate.
XP is not a culture of lowering the bar to the point that you’ve already achieved it. XP is a culture of constantly raising the bar. It’s not for everyone - merely by virtue of the mathematics of population distribution this can be seen.
So… I’m hesitant to get into any more detail. It’s an arduous journey to teach XP, and it’s not something volunteered for without evidence of serious commitment.
The only practice I’d say that developers should learn is TDD - especially developers who feel they’ve already learned it just by going through the mechanical motions of merely writing tests before writing code.