"Agile" Change Management: From First Principles to Best Practices

• Minimizing the number and size of non-code artifacts that must be produced or updated in order to implement a change
• d) Working only on the features scheduled for the current iteration

Continuous Customer Collaboration: The Key to Responsiveness

Perhaps the single most influential practices that agile methods provide for change management are the use of:

• 1. Incremental and iterative development to quickly deliver very small but very frequent executable milestones and obtain customer feedback on the results
• 2. Close customer collaboration to promote daily interaction and face-to-face communication between customers and the development team

The first of these two practices has the most influence upon the time and effort required to effect a requested change; the latter of the two has the most influence upon the time and effort required to respond to a requested change.

Since much of change control is about decision-making and prioritization of requested functionality, we would like to remove or reduce anything that slows down the process of obtaining customer agreement to approve, prioritize, and authorize a requested change.  If the customers are always available to converse with most anytime, then we don't need to spend any time waiting for customers to convene and approve requests. Such approval can instead transpire in a matter of minutes or hours rather than days or weeks. 

Agility mandates that customer input and decisions can be obtained within at most one or two days, and preferably within a matter of minutes or hours. If customers are not readily accessible, then a suitable customer representative (a product manager/champion ) must be available, and must be empowered to make decisions on behalf of the customers.

Getting "One Voice" from the Customer: The Product Champion's Burden

Getting a group of customer's to agree upon functionality and priorities can be very difficult! Competing business interests, differing customer markets, and personal and political agendas can make it seem futile to attempt to facilitate alignment on a vision and a shared set of goals and priorities. Furthermore, issues of broad or diverse customer bases make timely and effective customer communication and collaboration even more difficult.

The role of the Product Champion (or Product Manager ) is to effectively overcome these obstacles to quickly and accurately convey a common and collective set of needs and priorities that is representative of the product's installed (and prospective) customer base. Jim Highsmith writes the following about the role of the product manager (in a 14-July-2003 posting to the agileprojectmanagement Yahoo group):

The primary functions [of the product manager] are to facilitate, nudge, and mentor the customers in carrying out their partnership responsibilities. For internal IT organizations, the product manager works with various user departments, making sure the right person is available when the development team needs them. The Product Manager is also responsible for the participatory decision-making process on the customer side, just like the project manager is on the development side. Neither one's primary style is to make all the decisions, but they have the power if need be. 

For product companies, the product manager works with others within the company to convey customer requirements, priorities, etc. to the development team. How and when the product group involves the real outside customer is a fairly complex issue depending on the market, product stage, etc. 

The danger in any [customer] proxy is that they may come to believe that they are the customer and not just a proxy--their job is more like a facilitator's job--most of the time.... In the past, IT organizations have gotten in trouble because the "analyst", who usually comes from IT, has implicitly taken on