One of the hardest things for our sales team, our project managers, our development team, and our customers to agree upon in agile development is what constitutes an acceptable stabilization period.
Let me expand. I have been in software consulting for almost 10 years now, and the hardest part of any project is gaining final customer acceptance that the project is "done." With custom software, there always seems to be another bug to fix. The customer is afraid of giving up their rights to have the undiscovered bugs fixed if they sign off too soon.
With agile development, the idea we have implemented is that there is a set amount of time after new development for the team to focus on changes or fixes from any prior iteration. We set aside one iteration for software stabilization. We set this expectation with our customers up front, and they agree.
When it comes time for the stabilization period, however, it seems that as new development tasks from prior iterations take more time than anticipated the new development tasks bleed into our stabilization. While agile touts that our customers should be able to prioritize all outstanding work - be they new development tasks or bug resolution - based on their needs, it seems that the customer always chooses to add the new development tasks and never choose bug resolution. Then, when stabilization is over and there is a list of bug fixes, the argument comes up that we did not deliver a quality product.
While I understand that this problem is all about setting the appropriate customer expectations and about working with the customer to convince them that new development tasks should not be planned in the stabilization phase, it seems that we repeatedly get ourselves into this same situation. I love the agile approach. I love the idea of working closely with our customers, and getting immediate and real feedback as we deliver working software on a regularly scheduled basis. I also think it makes sense to weigh the tough decisions with the client sponsors in order to prioritize remaing new development tasks against the agreed upon schedule - excluding the stabilization period.
However, just like I found with the waterfall process, as soon as the schedules start to slip or estimates go over, the first thing to get the ax is testing. In this case, stabilization gets the ax. And when that happens, how can we confidently deliver quality to our customer and agree that at least the first phase of the project is in fact "done?"