Extreme Programming: how long are iterations supposed to be?

Question

I was researching about Extreme Programming, and started reading a book by Kent Beck called Extreme Programming Explained. There he mentioned practices and principles one of which confused me. It said that iterations must short.

If iterations are good, we'll make the iterations really, really short - seconds and minutes and hours, not weeks and months and years (Extreme Programming Explained - Preface

Later on in the same book, Kent Beck uses iterations in weeks:

Within a release, XP uses one- to four-week iterations of customer-requested features for fine-grained feedback about progress. (Extreme Programming Explained - Chapter 1)

The glossary again mentions a 1-4 week iteraiton:

Iteration

A one- to four-week period. At the beginning, the customer chooses the stories to be implemented in the iteration. At the end the customer can run their functional tests to see if the iteration succeeded.

(Extreme Programming Explained - Glossary)

However when I read on the extreme programming website, it says that iterations are 1 - 3 weeks long. However, I found a video (starting at time 7:09) where it mentions iterations in days, minutes, and seconds.

In Extreme Programming, how long are iterations and how do they work? Does an iteration work on 1 user story for 2 weeks? That seems alot. One of the reasons this confuses me is because Scrum completes multiple user stories in one sprint which last for 2 weeks. When I further researched about that it said that developers prefer 2 week iterations. So which one is it? Am I confusing it with something else?

Answer 1

I find this slightly confusing, but I think this one paragraph in the preface (which is the only place in Kent Beck's book where iterations shorter than weeks are mentioned) helps clarify things:

When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.

The practices of Extreme Programming scale very well.

Let's take the example of The Planning Game. The Planning Game is done on both a release level (to plan the stories that will go into a release) and again at an iteration level (to plan the tasks that will be done in an iteration). In theory, you could continue using the Planning Game to plan and manage every activity - even an individual could use it to plan out their day, for example. However, at some point, it begins to not add value.

Extreme Programming really does take good software engineering practices to the extreme. Pair Programming is a core part of XP and it takes peer reviews and makes them continuous. Test Driven Development (TDD) encourages creating and frequently running unit tests (even before the code is written). Customers and users can provide feedback after each iteration, not just each release.

From a business perspective, it doesn't always make sense for a project to operate on iterations shorter than 1 week or longer than 4 weeks. Customer-visible iterations that are shorter than a week can be wasteful - you're frequently bringing the customer in to provide feedback on just about every minor change to the software. Longer than 4 weeks prevents responsiveness to changing requirements and the environment (you're less agile). But just because an iteration doesn't exist at the project level doesn't mean that the practices don't result in things being apparent to developers in minutes or seconds, where those things are the results of peer reviews (via Pair Programming), failed tests (unit testing / TDD), or builds (continuous integration). Some companies, though, like Google, Amazon, and Facebook (1, 2, 3, 4) can make changes live to customers multiple times a week, sometimes in seconds. These companies are at the most extreme end of Extreme Programming.