Sustainable productivity in eXtreme Programming

2 minute read

eXtreme programming will not improve your short term productivity. But it will drastically improve your long term productivity.

My last post detailed how prioritization and Work In Progress limits are the keys to less work and higher productivity.

XP is an experiment in answer to the question, “How would you program if you had enough time?” Kent Beck

Cost of changes over time, for traditional and XP ways of building software
From “Extreme Programming Explained: Embrace Change” by Kent Beck

The best jam is made in old jars

As I was writing the post, I could not stop thinking :

Once again, XP has been addressing these WIP and prioritization issues for 20 years now !

Let’s see exactly how.

WIP limitation

XP has a drastic way to reduce WIP by 2 : pair programming. Instead of 6 developers taking on 6 stories at the same time, they only tackle 3. I won’t dive into the ton of other advantages to pair programming here. If you want to learn more, these blog posts might help.

Although it is now seen as a Scrum practice, Planning Game was part of original XP. Sticking to a basic planning game will give room for slack at the end of iterations. The trick is to leave the infamous focus factor away.

💡 A simple planning game will give room for slack.

Suppose a team member takes vacations for a sprint. The team should deliver less user stories that sprint. They’ll have less story points to schedule on next sprint. This leaves room for slack and long term improvements such as refactoring, learning … If half the team goes on holiday, that’s a different story, adapt your schedule with gut feeling.

A funny aspect of this is that XP teams are now the most likely to switch to the more extreme #NoEstimates.

Priorities

XP’s on-site customer is a straightforward way to work only on the most valuable features. Who better than an end user would be able to make this estimation ?

The YAGNI (You Ain’t Gonna Need It) and simple design principles avoid building unnecessary features. TDD’s strict point of not writing code before a failing test prevents over-engineering.

Modern XP

In this wonderful talk from Rachel C. Davies, she presents how her team has been improving XP for 15 years. She explains how they organize as 2 mobs and 1 solo. At any moment, one mob is working on stories. The other mob works on important long term technical improvements. The solo does some learning. This is an even greater WIP reduction technique than pair programming.

Having a dev doing learning all the time is a form of continuous slack. If the team feels that they cannot deliver something by an important date, he can join the mob to help them.

There’s even more to this learning. It can be about anything. Developers work on their technical skills, but they also learn about the domain. Little by little this turns them into domain experts. Guess what : domain experts are great at optimizing value !

💡 With time and efforts, developers can become domain experts !

Afterthoughts

Unfortunately, there is no easy way to prove the long term productivity of XP. We cannot split the world to run the same project with and without XP. Another difficulty is that after a years of XP, work remains smooth and sustainable. Nothing like crunch mode. People used to the hero culture are hard to convince that they can be more productive by doing less.

Hopefully, lean theory and gut feeling of programmers who have switched to XP can back up my claims.

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Leave a comment