Thoughts on adding "stabilization" to the end of your project plan

It's a pretty common practice to add time to the end of your project plan in between the end of the last development iteration and production deployment. There are a number of activities that may have to happen prior to going to production, including:
- Final QA signoff of cards from the final dev iteration
- Any remaining defect fixes as a result of that testing
- Final user acceptance testing
- Preparation of the system for production

This period is often generically referred to as "stabilization". The issue I have is that this term implies that the system is not going to be stable at that point in the project, and this may even become a self-fulfilling prophecy.

The ideal in an agile project is that there are no defects at all at the end of each iteration. While this is not an impossible goal, in reality teams will usually strive to ensure there are no defects that would fit in the category of "critical", "high" or "medium", and more than likely a few "low" defects will escape the iteration. They will catch up on these in subsequent iterations, but following the logic you will still have some at the end of the last iteration.

So instead of referring to that final stage as "stabilization", I would probably prefer something like "wrapup" or maybe even "polishing".

Agile is not a magic "change" vacuum

One statement about Agile that seems to haunt a number of projects is "Change is expected and welcome" during the project. This is true, but with conditions, and if expectations are not managed properly things can get out of control.

I've seen more than a few cases where customers think this means they can keep changing their mind with no impact to the project. When we explain that it is fine to change your mind, or ask for more changes, but something else has to go, they act as if we just performed some kind of bait-and-switch. The "problem" is especially prevalent because with short iterations we give the customer plenty of opportunities to review the finished features and make comments.

The essence of welcoming change has to do with making adjustments before the story card has been finished. If you are in an iteration and the developers are working on a story card, and in the process of discussing the requirements with the product owner (or bringing up an issue they have discovered) it is determined that things need to change, that is generally going to be ok as long as the spirit of the story does change dramatically and the estimate for the change is still in line with the original estimate. We want the finished product to be what the product owner really wants and needs.

But in terms of managing change once story cards are completed, it is important to explain the dynamics to your product owner/customer up front. The team will establish a velocity throughout the iterations, and for the purposes of planning, that velocity will guide what goes into the iterations. If you want to put something else into that iteration, then something else has to go. So if you are in the iteration showcase and the stakeholders make some comments about changing/adding something, then you need to decide number one whether it is worth it or not, but number two when it should be scheduled and what else is going to move as a result.