Interval Length

Ron (and Kent, and everyone else),

I love your ExtremeSoftware practices. As you're probably aware, your experiences are becoming an extremely good example.

I've been using similar techniques, based in part on Ward's and AlistairCockburn's works, with successful results. Incremental development, responsibility-driven design, collaborative teamwork, regression tests: give me these or give me project death.

I'm interested in your interval lengths. It can be hard to arrive at a satisfactory release rhythm. A couple of questions, if you don't mind:

How did you arrive at a 3 week duration? Was it the original duration? On my teams, we've tended to choose either 6 weeks or 8 weeks. Longer than 8 weeks is much too risky, in my opinion. Up 'til now, I would have thought that 3 weeks is too short (prone to disruption from vacations and other events).
How often do you release software to your customers? Looking at my handouts from OOPSLA, it looks like the major C3 releases are about 7-8 months apart. So what do the 3-week cycles represent? Internal deliveries? Nothing wrong with that, but I suspect there's more to the story.

Thanks, --JamesCollins

Oops, I see this was asked back in October.

We thought two weeks was too short, that we'd be planning too often. Four weeks would immediately be refactored into "monthly", which wouldn't be a regular interval, and we felt it was too long. So we picked three at the very beginning and have gone with it.

Recall that we release code to the ENVY config more often than daily, and all developers stay current (or I kill them). When a developer holds back changes for more than a couple of days, we consider it to be a serious problem, indicating that they're probably in trouble.

In the early days, the customer stayed up with our releases, because the system wasn't in production. Now that it is in production, we release code to production approximately once per iteration. Release is controlled by our production support team, who decide when things should go out. The basic forces are: not too close to running the actual payroll; significant change needs to be in before running the actual payroll.

We now release small increments of functionality almost continuously. Chrysler is always coming up with some little gimmick, such as changes in the rules for holiday pay or profit sharing or whatever. And the customer asks for this or that improved feature or announces that oh, by the way, there will be a new corporation as of January 1. So while we only add entire populations on a long cycle, we make significant changes right along.

We "always" change forward. That is, if I have released some classes, and you have, and your stuff is needed for production, mine will be released to production. We don't try to back my stuff out and release just yours ... we're not smart enough to do that reliably. We are (based on actual performance) smart enough to release new classes that are harmless or to detect that they aren't harmless before they get pushed to production. If they don't work, we fix them, so we can go forward, not backward.

Mostly this works because our new work is either actually intended to impact our current pay population (and so it does), or it impacts only people we don't yet pay (biweekly for example) and so it has no effect. And we have an incredible array of tests, as discussed elsewhere.

Hope you're still here, James ...

--RonJeffries

I'm still here! Thanks for the persuasive rationale. I was struck that you wanted to avoid a "monthly" deliverable mindset. I understand that your rapid (and steady pace) doesn't require that long, and that a shorter cycle reduces the risk of working on the wrong thing. On the other hand, teams that I've worked with seem to find it easier to remember end-of-month deadlines (two month durations for my current team). In my opinion, remembering the delivery date is more than half the battle. For some groups, remembering that there is a delivery date at all is more than half the battle.

One side-effect of a strong delivery rhythm and clear delivery expectations: I don't have to listen to managers suggest "sliding the date" nearly as often. I never did like that phrase. It sounds like an unsettling mix of failure and omnipotence.

Thanks,

--JamesCollins

I agree that keeping the delivery date in mind is important as you are progressing on a task. One nice side affect of planning in weeks is that planning always occurs on a Monday and delivery always occurs on a Friday. This makes remembering the delivery date easier than a month end. The C3 team is always aware of where we are in a three week iteration and how far we are from the delivery date. --MargaretFronczak

We don't have fixed interval lengths, although we do try to release often, at least for internal testing. The current schedule has release dates at 2-3 week intervals. In the past, the intervals have been much longer. I expect that since we're in a maintenance/new features mode instead of building from scratch, the internal releases will stay close together.

As far as delivery days are concerned, the team I'm currently on always sets delivery dates on Mondays. That way, if I happen to have made a poor estimate as to how long my work is going to take, I can engage in some HeroicProgramming over the weekend to get myself back on track.

I've done this more than once. Last time it happened, I was told (more or less) to "get a life", meaning that I should spend more time figuring out how much time the work was really going to take. Perhaps I need better TaskEstimationPatterns...

--KatyMulvey

CategoryExtremeProgramming