justin․searls․co

Overcoming Resistance to Extreme Programming

The year is 2025 and, astoundingly, a blog post is advocating for the lost art of Extreme Programming ("XP"). From Benji Weber:

In my experience teams following Extreme Programming (XP) values and practices have had some of the most joy in their work: fulfilment from meaningful results, continually discovering better ways of working, and having fun while doing so. As a manager, I wish everyone could experience joy in their work.

I've had the privilege to work in, build, and support many teams; some have used XP from the get go, some have re-discovered XP from first principles, and some have been wholly opposed to XP practices.

XP Teams are not only fun, they take control of how they work, and discover better ways of working.

Who wouldn't want that? Where does resistance come from? Don't get me wrong; XP practices are not for everyone, and aren't relevant in all contexts. However, it saddens me when people who would otherwise benefit from XP are implicitly or accidentally deterred.

For what it's worth, I wrote about my favorite experience on a team striving to practice (and even iterate on) Extreme Programming in the August edition of Searls of Wisdom, for anyone wanting my take on it.

Benji's comment about GitHub—whose rise coincided with the corporatization of "Agile" and the petering out of methodologies like XP—jumped out at me as something I hadn't thought about in a while:

Similarly Github's UX nudges towards work in isolation, and asynchronous blocking review flows. Building porcelain scripts around the tooling that represent your team's workflow rather than falling into line with the assumed workflows of the tools designers can change the direction of travel.

One of the things that really turned me off about the idea of working at GitHub when visiting their HQ 2.0 in early 2012 was how individualistic everything was. Not the glorification of certain programmers (I'm all about the opportunity to be glorified!), but rather the total lack of any sense of team. Team was a Campfire chatroom everyone hung out in.

This is gonna sound weird to many of you, but I remember walking into their office and being taken aback by how quiet the GitHub office was. It was also mostly empty, sure, but everyone had headphones on and was sitting far apart from one another. My current client at the time (and the one before that, and the one before that) were raucous by comparison: cross-functional teams of developers, designers, product managers, and subject matter experts, all forced to work together as if they were manning the bridge of a too-nerdy-for-TV ship in Star Trek.

My first reaction to seeing the "GitHub Way" made manifest in their real life office was shock, followed by the sudden realization that this—being able to work together without working together—was the product. And it was taking the world by storm. I'd only been there a few hours when I realized, "this product is going to teach the next generation of programmers how to code, and everything about it is going to be hyper-individualized." Looking back, I allowed GitHub to unteach me the best parts of Extreme Programming—before long I was on stage telling people, "screw teams! Just do everything yourself!"

Anyway, here we are. Maybe it's time for a hipster revival of organizing backlogs on physical index cards and pair programming with in-person mouth words. Not going to hold my breath on that one.


Got a taste for hot, fresh takes?

Then you're in luck, because you can subscribe to this site via RSS or Mastodon! And if that ain't enough, then sign up for my newsletter and I'll send you a usually-pretty-good essay once a month. I also have a solo podcast, because of course I do.