We have really short iterations in my organization… which is a blessing and a major hurdle. We try to be "agile" in our development cycles, but sometimes "agile" gets awful close to "chaotic". The problem that we have is that we are part of a "Service Delivery Organization", or an organization that is dedicated to supporting the customer's production environments. This makes it really hard to separate someone's legitimate production issue from something that is a legitimate problem, but has to be resolved through a new feature enhancement to the system.

The distinction between a "problem" and a feature request that needs to be added to our backlog is an interesting one. If we were able to follow the SCRUM methodology correctly (really at all), we would always be asking that these requests go through a "product owner" for each part of the system. My counterpart on the Analysis side of the team has done a wonderful job of trying to make this happen, and he has had some measure of success. However things still slip through the cracks and derail the team. I recently dedicated one developer a week, on a rotating basis, to the role of "maintenance" in order to try and deal with the need for quick turn-around additions to our software. Just like the attempt at moving all requests through a "product owner", this has had a little success and a little failure. We're constantly tuning how we react to "production needs", and we hope that we will eventually figure it out.

In the meantime, we find ourselves in a situation where the majority of our work (something like 70%) is broken up into projects that are one week of development and one week of testing. This is an interesting pace to keep up, as we are expected to be able to do a release once every two weeks. It doesn't mean that we are releasing major changes that often, but it does mean that there is almost always something going out to production on those cycles.

I mentioned the SCRUM Sprint because we have a very interesting model of one to two person projects constantly working in mini-sprints. I would be interested to know if any organization has found a methodology that can support turnaround times that are shorter than a month for mission critical systems… all the while maintaining a constant backlog of about 6 months of work (that's after dividing the effort by the number of resources that we can dedicate to it at any point in time).