The change management process used in large projects is often a bureaucratic process that inevitably delays the implementation of changes in a system. Agile methods try to side-step much of this bureaucracy by involving customer representatives closely with the development team and by making it the responsibility of the customer representative to prioritize changes that should be made to the system. Of course, the team have to make estimates of the costs of these changes so that the customer understands the implications of these decisions.
This system can work well during the development process if the customer representative involved in the team has a good understanding of the requirements of different stakeholders in the process. It is more of a problem if there are several changes to be made with different stakeholders assigning different priorities to these changes. In those circumstances, it is hard for the customer team member to make decisions on these as they will inevitably be influenced by political and organizational issues as well as technical requirements.
After a system has been deployed, it is not really clear to me if an agile approach to change management can be used and I have not seen any reports of agile 'maintenance' projects that have discussed this issue. There are really two problems at this stage:
Overall, the whole area of agile maintenance and change management is one that is not widely documented. Ambler discusses requirements change management but this seems to be concerned with change management during development rather than after deployment.