I had a discussion with a management type the other day about implementing the concept of release and internal iterations. Currently that project has extremely long iterations (6 weeks or more in length) which always are released to the client for testing. As a result of this, the feedback cycle from testing is very slow. The client isn’t getting the software into their hands, and then not getting their concerns raised until longer after that point, that there can be a gap of 4 months between initial development and defects being raised and fixed.
In an attempt to shorten that feedback cycle, I made my suggestion of implementing shorter, internal iterations that fell within one larger duration (and feature list) iteration. Here’s how I saw it working. If the project had a release iteration planned with a duration of 6 weeks and known set of features, the development team would split that release iteration into a set of smaller internal iterations (say 3, each being 2 weeks in length). At the end of each of those internal iterations, the development team would be responsible for providing a demo of that 2 week iterations features to the client. The demo would allow for high level feedback on things like UI design, workflow and domain concepts, but it would not allow the client to get into the meat of the features. In my mind, the purpose of the internal iterations wasn’t to elicit full feedback, user acceptance testing or full feature verification. Instead I was suggesting that this project take steps to increase their ability to readjust the direction that their development effort was heading.
In my mind the benefit of iteration based development is the feedback and directional guidance that the client provides sooner, rather than later. I liken it to the small steering corrections that pilots make when the plane is hurtling down the runway on takeoff or landing. It’s much more comfortable having those little left and right corrections and sways in your seat (I say this now sitting on my balcony…it would be quite different if you asked me during takeoff) than it is to have one hard turn once the plane was up to speed. If your iterations are the length of the runway, you’re going to have to make a bigger and less comfortable change when you get to the end of it. I think that internal iterations are one of the best ways to avoid that shocking change.
Unfortunately, my suggestion of internal iterations was misinterpreted as “release to the testers and clients every time there is a feature completed or a defect fixed”. Just another battle to be fought in the war on BDUF I guess.