Over the years I have worked with, talked to and/or read about many agile teams. Almost none of the teams did agile software development the same way which has reinforced my belief that there is no "one way" of doing agile. One aspect of agile development I have always been drawn to is iteration length. Most teams seem to be falling in the 2-3 week range. In fact, recently a friend of mine said they were doing scrum with 3 week iterations becuase "any thing shorter caused too much overhead." I tried to point out that that isn't always the case as it depends of what overhead you are doing. I am a firm believer in minimuzing overhead as much as possible. I have always found ways to decrease or shift overhead to take less time in an iteration than previously believed possible. My favorite technique is process impedance matching.
I believe that lean thinking should be applied to software development. Given the principles of flow and value along with agile development practices it is obvious to me that the shorter the iteration the better. One of the competing forces is as the team size increases so does the overhead. To combat this I recommend capping team size to 9 (I am a slave to the magic number :-) Another consideration is the team's schedule. All the agile teams I know of work Monday to Friday and have a daily standup in the AM (9AM seems to be a popular time). People also like to forget work on weekends...some would argue it is the point of the weekend. Given these factors releasing on a Friday make the most sense to me. Monday's typically are hard... catching up on emails from people you didn't get to on Friday, remembering what it was you were doing when you left Friday...so planning meetings are best suited for Monday's. As you plan you are refreshing your memory as to the features you plan on bulding. All of this seems to point to a week long schedule of Monday mornings are planning and Friday afternoons are releasing. It's a nice package for an iteration in my opinion. I am open to shorter, but longer seems wastefull.
Many people will immediately think some version of the following: "That can't be a good idea becuase I'm not doing. If it was a good idea I would have thought of it when we decided to do >1 week iterations" or "I am sure it is >1 week here for a good reason...I just don't know exactly what that reason is." Given that I would like to convince you that my belief should be your belief (one of my many weaknesses) let me try and lay out common arguments against the one week iteration.
A1) One week iterations will have too much overhead.
I have found that the most people say this because they they they have to cram all the overhead they currently do in 3-4 weeks into one thus it is obvious to them this makes no sense. This assumption does not hold because of the lean principle of waste reduction and thus the goal is to minimize overhead. I challenge everyone to examine what overhead is actually needed in EVERY week? We already have blocked of 2 half days (Monday morning planning and Friday afternoon release & retrospective) as well as the 15 min stand up every day. Everything else should be avoided or at least minimized. If your organization requires a weekly status report and meeting. Use process impedance matching (e.g. let the team lead do it for the whole team; rotate through the team). Most all obstacles can be overcome if you use a brainstorm session with you team. If you have trouble solving a problem use the many internet sources (websites, groups, blogs...) If you seem stuck it is probably due to a lack of true teamwork (The Core has some iteresting ideas).
A2) Weekly releases are wasteful
Usually this comes from a management type who is thinking that all releases must have the business customer present (or some overhead thing like A3). If your business customer isn't engaged enough to commit to 2 half days a week then improvise and have a team member play a surrogate customer in those meetings. Different people have different skills, but hopefully one member of your team can think from a customer's point of view long enough for you to move forward. Once the customer makes time then re-validate. I am not saying it isn't ideal to have a fully committed business customer, but don't throw the baby out with the bath water.
A3) We can't do X in one week iterations
X is usually some localized practice that has evolved from a problem that wasn't solve, but is now. Like passing all releases to some QA team. If your organization is one with a separate QA team that must "sign off" on all external releases then simply use process impedance matching and send them your final release (the one that has all features needed in the time allowed) and then they test and they few if any defects (if you used proper agile development techniques) . You fix them as they find them and send them one more release when they are done (if they can manage to test in one week...doubtful if your organization hasn't embraced continuous testing..then send them one per week without needing to change your process much). Pretty simple if your team thinks about how to fit what needs to be done for organization reasons with what has to be done for agile development reasons.
I am sure there are more arguments out there that don't neatly fit into one of the above. Please comment with them. I think Tom Gilb once challenged an audience that over lunch he could figure out a way to release early then they currently do (Gilb's guidance was 2-5% of budget/schedule for each release). He got at least one free lunch out of that challenge. I am willing to take the few who read this on :-)
