Two Weeks of Extreme Programming

Some initial thoughts after two weeks on a new team practicing extreme programming.

Posted in Main Thread on May 20, 2015

Over the past few years I’ve worked on a lot of teams. Most of which claim to be agile. I tend to cringe when I hear teams say they’re agile. Pretty much for the same reasons Andrew Hunt, co-signer of the Agile Manifesto, recently wrote about in The Failure of Agile.

Most teams cherry-pick a few methodologies and tools and claim they’re agile. Even Kent Beck admits this in his interview on Full Stack Radio. To him, being agile simply means:

…that you can respond in time. Things are going to change. Can you respond in time? If you can, you’re agile. If not, you’re not.

By his definition this team seemed agile. Not because they hold daily standups or use Pivotal Tracker. Instead it is their practice of extreme programming. I became intrigured when this team made the distinction.

Both Agile and Extreme Programming share their value of lean processes. But two key practices set extreme programming apart: test driven development and pairing. So far, I find the combination revolutionary.

I struggle practicing test driven development (TDD) on my own. I never know if I am correctly driving development through testing. Individually, I might lack discipline, but paired with another developer we can answer such questions and in turn improving our craft.

Pairing with another developer also gamifies TDD. We take turns writing tests. My pair will write a “good, failing” test and then I will make the test pass. For the next test we swap roles.

Sure, plenty of teams practice TDD and pair program. However, this team pairs all day, every day. Not always two developer either. Designer and product owners enter the mix. Having the entire team together, a core principle of extreme programming, sharing this process helps us remain agile.

Now, I have to admit, being a manager before, pairing all day seemed wasteful. After all, we produced the code of one developer for the price of two, right?


First, there’s the assumption that the developer pair writes the same amount of code. Although not scientific, I am more productive while pairing. Having another developer sitting right next to me undoubtedly increases my productivity and efficiency.

Second, there’s the assumption that a single developer is 100% productive. Regardless if they’re a junior or a 10x developer, I think we can all agree no developer is 100% productive. Between meetings, nerd sniping, coffee, and kittens we are unproductive at some point.

So let’s do some math. Let’s say solo I am 60% productive. However, when paired I am 80% productive. So two developers individually provide 120% productivity, while paired they provide 80% productivity.

While there is a loss of productivity, it was not cut in half. Furthermore, you have to consider the ancillary benfits of pair programming: sharing domain knowledge, improved code quality, leveling up skill sets.

In closing, I think back to the quote:

Software development is a team sport. Even if you’re the only one on the team.

Practicing Extreme Programming makes software development a true team sport.

Find this interesting? Continue the conversation on Twitter or in a comment.

Need more? Let's team up!

Schedule 1-on-1 coaching or hire me for your project.

comments powered by Disqus