We started off our project with the recommended 2 week iterations. And this worked well until the system grew to a maximum capacity. That capacity being defined by the amount of resources available to the project available to satisfy the requirements. At this point, it became neccessary to introduce a reflection period between each iteration. Running iterations back to back didn’t allow sufficient time for the business nor the technical teams to absorb progress adequately. Interestingly enough, the number of bugs found in QA was an indication that we had reached this point.
The bugs were either a result of loosely defined requirements being misinterpreted [things were happening too quickly] or by technical implementations being delivered so quickly that logic was being duplicated, not by means of bad development processes, but because there wasn’t enough time between successive iterations to reflect and overview the system to see where it was headed.
After introducing the mandatory reflection period between each iteration, it allowed both the business and technical teams to catch up with a rapidly evolving system. After a while though, the added reflection period, which contributes to the capacity of a project, became insufficient in itself to deal with growing system. We needed another mechanism; in short, we needed more resources.
The reflection period turned out to be a resource which we used effectively to facilitate the more well known resource concepts: money and people. At least, the resources which we perceive to have more control over. For some reason, Time is still perceived to be outside our control.
Our next strategy was to change iteration lengths. Afterall, we are Agile, aren’t we?
So now we’ve adopted iteration lengths from anything to 1-3 weeks, depending on the business urgency of requirements and the volume of requirements. This iteration length is established by the business lead since they are the ones that need features by a certain date. And then, following our standard practices, the technical team determines what can be done by that date. This might seem a strange way of working for some and hard to grasp since immediately it will start begging a lot of questions. But it does work [for us].
This variable iteration period works well and allows us huge dynamic advantage as well as keeping things interesting without losing the much needed routine. The reflection period stayed and became a percentage of time of the iteration length. For now, we’ve adopted 25% as a guideline. As with most things, this is monitored and flexible, but not to the point of sacrifice.
More recently, we’ve taken the concept a little further by not starting iterations until the requirements are, by guess-timate, at least 80% accurate. This means now that both our start and end dates for each iteration are driven by business readiness.
So, in projects where budgets are limited [anyone working with unlimited funds?] and people are expensive [ramp-up costs plus hourly rate versus value to business over time], Time is the other resource you can play with. Using variable iteration lengths and reflection periods and only starting when the problem is sufficiently defined are just some ways you can manage your project more effectively…