Scrum - why extending sprint (iteration) length is usually not a good idea

I have to admit -- I'm a big fan of short iterations and I have plenty of reasons for it! But what does short mean? In most cases 2 week iteration is a good start. You should consider shorter iterations only if rule of having at least four, five iterations within a project can be broken, hence any project shorter then 8-10 weeks is a potential candidate. On the other hand, big, 6 months and more, projects should consider 3 week iterations ... but only ... I repeat ONLY ... when you are sure that scrum and in general agile software development process works for you and you are happy with the results.

How can you know that scrum works for your team?

One thing has to be clear -- you don't have to use pure scrum to make it work for you. Sometimes applying only some aspects of agile software development is the best approach and it doesn't make it any less agile. Fundamental thing about being agile is improving the process, so get rid of things that doesn't work, experiment with new ideas and learn!
It's often the case that people feel that there is something wrong but they can't really say what exactly therefore I highly recommend watching this presentation: "10 Ways to Screw Up with Scrum and XP". Also you can find more materials on Henrik Kniberg's blog. Check if you find your problems on this list, check if you follow fundamental scrum rules.

Why short iterations are better?

I stated before that I have plenty of arguments ... so here is a list:

1. The most important one - short iterations allow you to find problems early, always look for problems and remember about the rule: visible problem = killable problem. If your team is aware of the problem then there is a good chance that they can cope with it. Treat problems like a opportunity for improvement.
2. With short iterations new ideas and improvements can be applied quicker. After each iteration you should have a retrospective meeting to identify problems and figure out how to improve the process for next iteration. Short iterations mean that you can improve more frequently.
3. About certain problems you can learn only after full iteration ... for instance common problem is that people don't work as a team ... each person has it's own task and at the beginning of a iteration all stories are in progress. Sounds good as it means that whole team is working and is moving forward but actually it's not good as you can't really say how many user stories will stay in progress to the end of iteration. In worst case all stories are 90% done by the end of iteration which means that from a client perspective this iteration didn't add any new functionality, any releasable code, any new value.
4. Estimations and velocity - at the beginning of a project how can you provide reliable estimations? How do you know how long it will take to deliver whole system? At the beginning you don't know much about team's performance, you don't know how cooperation between the team and a client will be looking like. So probably you can't provide any reliable estimations ... you can only guess. But first few initial iteration should give you good idea about team's velocity which should result in much more reliable estimations ... now you can figure out what should be done in next two, five or ten months. Sounds like a useful thing?

Are you convinced? I hope you are ... if not ... then challenge me and post your arguments! Maybe you can persuade me that I'm wrong :)