Customers and changes

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:

1. Maintaining continuity. Because agile approaches rely on informal communications, with limited formal documentation, they are most effective when the same people are involved in the process. However, once a system has gone into use, it may be very difficult to justify having the same customer representative involved as has been involved in development. This means that new customers with different ideas may be involved at different stages, so sending mixed messages to the development team.
2. Change assessment and costing. This is closely related to the above point but reflects issues of maintaining continuity in the development team rather than maintaining customer continuity. Essentially, much of the information about the system requirements and rationale is in the development team's head rather than in formal system documentation. New people who come into the team during maintenance and support may find it very difficult to understand exactly what has and has not been included in the system and may find it very difficult to assess the consequences of making changes, especially if these affect the overall system architecture.

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.