One of the predominant goals of the Agile movement is to have software development teams deliver software in regular yet meaningful increments. Out of this the was born the idea of short time-boxes of development cycles with specific delivery goals at the end of them. These time-boxes have been referred to as iterations, sprints etc etc depending on the methodology is in play.
One of the challenges I see with iterations is that management arbitrarily picks a length of time, say 3 weeks, as the length of the iteration and applies it unilaterally across all development initiatives that exist perpetuating the notion that all development initiatives need the exact same methods applied to them. It could be very possible that one software change initiative works better with weekly iterations because new functionality can be delivered/demonstrated on a weekly basis while another initiative needs 6 week iterations for the exact same reasons. Agile teams should strive to be self-organizing meaning minimal management interference. Teams (with coaching) need to understand their objectives and iterate in manner that makes them most efficient. Asking all the teams within a group to conform to a “standard” iteration cycle/schedule/calendar imposes constraints that actually gets in the way of getting things done (and getting them done quickly).
How so you might ask? Well, a direct result of imposed iteration cycles on all development projects is that it causes teams to make up what I consider to be “soft goals” (or pseudo goals) such as “deliver design documents” in order to have something to show at the end of the iteration. I’ve sat in meetings making up worse goals such as 10% of the use cases done by the end of the iteration (what was I thinking?) While there is nothing inherently wrong with delivering design documents at the end of an iteration, in my opinion, it devalues the essence of time-boxed development which is delivering actual end user functionality. What is of value to the end user is a working solution, hence the ability to show incremental progress towards the solution should be the driver for iteration sizes – this makes iterations the most meaningful.
Determining how quickly incremental functionality can be delivered should determine iteration lengths. This proposed length of an iteration should further cause a retrospective on the proposed approach to development for that particular development initiative. If the length seems too long, then the team should focus on methods that allow them to shorten development time while yet maintaining a high level of quality as creating short iteration cycles is addressing a symptom and not a problem. Truth be told, there is a lot of “waste” in software development as many of the mandated processes/practices we consider value-adding do not provide actual value to the end user (at least not in the first delivery) e.g. end users don’t care about monstrous catalog of user stories, user cases, functional specifications that we keep and the value they provide to the development team is generally overstated but this is a topic worthy of its own post.
My recommendation is determine iterations schedules with the explicit goal of demonstrating customer functionality at the end of every iteration specific for each initiative.