Home | Login | Recent Changes | Search | All Pages | Help

ShortIterations

I met someone today who manages projects with 17-day iterations. That's 17 work-days, not calendar-days. I like the idea of 17 days, because you have a break between iterations to revisit the requirements if necessary, and you're not trying to make an artificial date like a Friday or a Monday.

I've managed projects with quarterly release trains, where the quarter was a shorter iteration than before, and in some cases was still too long :-(. I'm practicing shorter iterations with my work now. I find that I'm much more likely to be able to cross things off my list because I broke them down into smaller pieces.

Do you use iterations? How long are they? What do you find with your iterations? -- JohannaRothman 2003.04.01

KeithRay 2003.04.02

I've used one-week iterations frequently, to good effect. We weren't building "story" based systems, so decomposed the system into chunks that did something meaningful that you could build in about a week. For embedded controls each chunk was something like: add the defrost algorithm, add high temperature throttling, etc. I have always found that there is a way to slice things so you get something new every week that's interesting, stable, and visible. Not necessarily "story."

I have used one week ship cycles with 3rd party vendors, database-intensive products and software tools as well. I actually like the artificial deadline of a Friday as a form of social engineering.

• "Not done by the weekend" seems a less ambiguous than a date, to me.
• There's some wiggle room in there. If we have to, we can work Saturday - once - to hit the delivery. Then we fix our estimates.
• There's limited wiggle room in there. Only two days from Friday to Monday. (Sad commentary, how having a calendar-driven cap of 40% "extra effort" is a useful limit.)
• There's some discomfort there. If we blew the estimate, fixing it by the following week means weekend work. People get highly motivated to estimate conservatively, which is better all around.
• A week is small enough that almost any idea can wait until "the next cycle." Reduces emergency ad-hoc redirection. One week seems kind of magic here, compared to other numbers. I have no explanation.
• One week gives you a shot at other processes that take longer, and are more disruptive. Let's automate rebuilding the databases and the test bed, over the weekend. (Maybe the repository, IDE patches, and the network as well.) So, this iteration is done, and we've got all weekend to have the machines make us a clean baseline - code, environment, libraries, and everything - while we rest up.
• Provides a synch point for external changes, like the dba's want to patch the db. One week is magic again for scheduling to meet our plans. One week is also magic for getting off-hours maintenance as in: "Oh, great, you can do that next weekend while the rest of our environment synchs up and does maintenance. And we'll have a fresh backup of everything by 23:00 Friday in case anything goes wrong. What else do we need to do to prepare for you?" This is way better than some other possible responses to: "We're going to re-roll your databases tomorrow, Wed. starting at 13:00, we think."
• Caps scope of failures. I get really nervous when I haven't seen something delivered that works for more than about 10 days. Doubly true when I'm dealing with external teams or vendors. Like dba's who's patch / database roll didn't work, for example.
• I get good indicators of bad estimates. If we're having to hork around the "weekend automated magic" because someone's not done, that's pretty visible. Without all that magic going on, it's easier to hide people doing more work than they ought to.

Johanna said "release trains" which is more product-y, and brings up another point I sort of illustrated here. There's great value in having a stack of delivery cycles. The weekly systolic software builds for the heat pumps I mentioned above didn't go to "the customer" every week - we essentially delivered to ourselves. Pushing out to labs and acceptance testing was less frequent - about every 6 weeks. Bringing in the circle of product engineers was less frequent - about quarterly. It's really useful to have a stack of these processes that push different kinds of changes further through the process, depending. Goes nicely with IterativePlanning.

-- JimBullock, 2003.04.03

A chunk that is interesting (to the user) and visible is an XP story.

A UseCase as done by RUP can result in around 40 stories, I've been told.

KeithRay 2003.04.04

I'm currently using one-week iterations, but that is really too short.

I understood "too short" to mean that the stories didn't fit in a week. What am I not getting here? -- JimBullock, 2003.04.04

You're getting it. Many of my stories didn't fit within a week, and we didn't try to break all of them down to fit within a week. Longer-than-a-week stories are not too much of a problem... other than tracking being less predictable.

You seemed to be saying that your "chunks" were not stories, but they seemed to fit the XP definition of stories.

KeithRay

You may start backlogging on the 2+week efforts that just can't complete in the interval.

It seems to me that you are claiming that you (Bob) sometimes have "stories" that can't be sliced into single weeks while still being "stories". So far, I have always been able to create chunks that are new, interesting, stable, visible, fit in a week, and between them cover all the functionality of the system. What's the determining distiction that makes some "stories" things that can't be sliced differently to fit in a week?

You seemed to be saying that your "chunks" were not stories, but they seemed to fit the XP definition of stories.

If that's for me (jb) no. I don't know whether my "chunks" are "stories." I am suspicious that "chunks" and "stories" are somehow different because I have always been able to find chunks that fit in weekly deliveries, while you (Bob and Keith) are talking like that isn't the case for you with "stories". I don't yet know what meaningful distinctions might might be at the root of this. I am curious.

Longer-than-a-week stories are not too much of a problem... other than tracking being less predictable.

" . . . Not too much of a problem . . ." does not fit my experience. "This week we're not going to get anything" has consequences in the social engineering items I named. Perhaps I have been in less mature and organized circumstances than you, or worked with different amounts of crossing organizations including balky vendors and prima-donna support organizations (dba's are at the top of my list right now, with LAN ops a close second.) The regular, repeated pulse of activities is an incredibly powerful synching function when some people aren't quite on the same page, nor do they want to be.

Perhaps this is a "scope of the problem" issue? Regular, weekly deliveries are merely convenient (perhaps trivially convenient - I'm not sure) in the context of a tight, colocated software development team. For me, getting stuff done as in "shipped and in use" has always involved more than just a single, tight team writing code together. Even if "getting stuff done" is only about writing code, there are lots of ways to make that harder - distributed teams is a recently popular challenge, since more US companies discovered that India exists. The regular pulse of deliver helps immensely the minute we stray from "everybody's in the same room doing coding" which is most often the case.

Perhaps there is a team composition or project state issue? I have recovered a lot of projects. Even a colocated development team that's been flailing has people who are underperforming (duh), some that shouldn't be in the job, some are fed up, some self-righteous, and some beaten down. It's amazing the clarity that happens with the simple assertion: "We're going to ship something at the end of this week. At the end of next week, we're going to ship something more. And so on." A related trick is what we're going to deliver that first week - a baseline build from the shared code / system repository, with no magic to make the build happen.

It seems to me that a lot of the value of ShortIterations is in the effect they have outside the development team. For those effects, fixed, regular, short iterations have been way more powerful in my exprience. But that's just me. I could be wrong. -- JimBullock, 2004.04.05

My company's overall culture is not short iterations. So my doing them is a little alien to the rest of the company. For example, I haven't yet gotten QA involved in my project, even though QA should be involved from the beginning for true XP style. (I may getting QA involved next week, hopefully.)

Our company had some salesmen from Rational give a presentation on RUP - incremental, iterative, and "architecture centric". Some of the execs said that we couldn't do iterative (even one-month iterations) because our customers don't work that way. Some of our customers are also Rational customers, so maybe that's incorrect. * sigh *

KeithRay 2004.04.05

Usually, these were legacy refactoring problems - rescuing a system from technical debt. Until the system achieves a certain cleanliness, it's hard to do safe & useful work in short iterations. The company was on one month iterations, but relentlessly played "Damn the torpedos!" on mounting tech debt. Testing freeze consumed the last 2 weeks of each month (no test-first here!) My "outside the window" effort was to make rational sense out of an out-of-control build process that took 3+ hours -- reduced it to 35 minutes so people would build instead of "presume" that modules were unaffected. There were about 75 DLLs composed of 750 source modules.

Perhaps the general thought is that accumulated code smells can be difficult, expensive and pervasive in short windows without aggressive refactoring along the way.

--BobLee 2003.04.07

To me, the reason large chunks are a problem on a wiki is that I'm reading on a screen. This medium doesn't lend itself to reading large chunks. And that brings up my real point of this chunk -

Choose an iteration size that fits for your situation.

One of the strongest parameters from a project control perspective is that no iteration should be so big that you can't afford to throw it away if it doesn't come out right in the end. This helps avoid the temptation to keep junk "because we've got so much invested in it already." JerryWeinberg 2003.04.07