>If the team had one day iterations, but found that they couldn't
>deliver something of value to business, would you recommend

> a) shortening the iteration, or
> b) lengthing it

Neither. I'd want to find out what the issue was. I might sit down
with them and try to do something of value in a day. But a week is
five! times longer than a day.

If a team had one millisecond iterations and couldn't deliver
anything of value, I'd definitely suggest that they would lengthen
it.

> I generally agree with most of the points you are making, I just try
> not to think in absolutes (i.e. shortening iterations is always the
> answer).

Well, with a team having week long iterations and difficulty
delivering business value, I absolutely would not make my first
remote suggestion be longer iterations. I would want to know whether
the issue was that the customer's expectations were too high;
whether the team has figured out how to split stories; what the
issues were in the development environment; and many other things.

After all that, it might be that longer would be better.

I think lengthening the iteration, for a team
that's already not clicking along nicely, is a risky strategy.
Getting XP / Agile clicking along involves learning and discomfort.
I don't want people tortured, certainly, but making the exercise too
easy isn't the first resort I'd choose either.

It's just that my first reaction to "my, this is difficult isn't it"
isn't "oh, well, don't do it then". I don't want to demoralize the
team, mind you. But not doing the hard stuff isn't the way to learn
to do the hard stuff.

How about trying to do just one story, of value in the iteration, or
two, instead of one or two per programmer?