4

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?

  • Well I don't know the material you're referencing or even the subject matter all that well, but the notion that stories could be divvied up into "minutes and seconds" is absurd to me. – Lightness Races in Orbit Dec 28 '15 at 1:00
  • Yea man, I man very confused at the moment. everything i read was going good until this. I am thinking tho, maybe he meant the tasks will take days hour seconds. but then again, i dont think tasks can take weeks or months. according to the comparison that is in the book. – Evgeny Danilenko Dec 28 '15 at 1:16
  • Perhaps you should actually quote your sources so we can see what you're reading. – Lightness Races in Orbit Dec 28 '15 at 1:18
  • 1
    So? I can find a dozen books and consultants on different ways to do scrum. Or kanban, or whatever the project management flavor of the day is. You have two different opinions from two different people. If you wish to reconcile those, you should ask those two individuals. – user40980 Dec 28 '15 at 2:24
  • 5
    Extreme Programming has nothing to do with project management in and of itself. Maybe that's the confusion. User stories and sprints are concepts at the project management level and apply to teams of developers. XP more applies to an individual developer or pair of developers working in tandem. Beck is probably talking in terms of minutes and seconds because he's thinking at the level of test driven development, I.e, accomplishing writing a single test, making it pass, and then repeat. SCRUM et al operate at the project level and so don't concern themselves with anything smaller. – RibaldEddie Dec 28 '15 at 2:47
6

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.

  • 1
    "From a business perspective, it doesn't make sense for a project to operate on iterations shorter than 1 week ", of course, for lots of projects, products, or organizations, that is true. But at least some companies are practicing continuuos deployment, with several releases to the customer per day. The best known examples here are Google and Facebook, and they seem to be very successful with their approach. – Doc Brown Dec 28 '15 at 8:13
  • @DocBrown: So they make a release each time they change the label of a button? Or do they have several larger features that are developed in parallel and are released each time they get finished? I.e.: the individual features may be non-trivial but since several features are developed and completed in parallel you get a continuous flow of releases. – Giorgio Dec 28 '15 at 8:37
  • 1
    @Giorgio: see air.mozilla.org/continuous-delivery-at-google, "8 minutes after you commit code it's live in production" – Doc Brown Dec 28 '15 at 10:50
  • @DocBrown That's a good point. I'm going to edit to reflect that. – Thomas Owens Dec 28 '15 at 12:05
  • However, what do you mean by "But just because an iteration doesn't exist at the project level doesn't mean that..."? specifically the "iterations don't exist on a project level" – Evgeny Danilenko Dec 28 '15 at 17:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.