Change Management in Agile Projects

photo credits

 Working in the last 5 years in IT projects I realised the struggles of adjusting change management from waterfall to agile. 

 Reflecting on it, here are 4 Change management components that you can do agile and 4 components that are still needed as in traditional waterfall approach.

What is the same as in waterfall projects? Mostly, the prerequisites needed in the initiation phase: 

  1. Defining the change and the gap analysis between the “as is” and “to be”
  2. Key stakeholder mapping (high level to get things running). Identify early adapters and resisters in order to get them involved. This will become an ongoing activity during the project as different stakeholders will be needed to be involved in iterations and provide valuable feedback
  3. Organisational readiness (identifying the opportunities in the low hanging fruits and the potential threats/resistance points)
  4. High level change planning per release and target groups

Then how do we integrate change management in sprint/iteration work? Here is what I have tried:
  1. Use the change management resources (communicators) to identify and on-board your stakeholders (customers) that are needed in the sprints to support the build of the product.
  2. Involve change management resources in the sprint work (the communicator, the learning developer or anyone else that is responsible to inform your users on the delivered functionalities). What are the benefits of having them in the sprint team? First of all they will have a better understand of both the customer needs and also of what it is developed for the customer. Then the information that reaches your end users (customer) will be much more tailored to deliver customer experiences not features.
  3. Prepare the communication and education materials after each sprint. Even if fine-tuning will be required before the release it increases the efficiency as most of the work will be already done instead of producing everything all at once just before the release.
  4. Build a diverse team that covers all the skills you need. We always hear that less is more and for example when it comes to education less learning needed is truly more value for your customer. By recruiting communicators and learning developers with UX competence you secure that their input in the build of each iteration will mean less material that needs to be produced for informing your customer. Having these T-shape skilled resources will enable the collaboration with other project resources like developers, business analysts, architects, etc.
In the last project I worked in, I’m most proud of the last 3 points. Having the change management resources involved in the iterative work brought much more value for the customer in the quality of the communication and education materials needed to complete the user experience. Also by having the materials ready after each iteration increased the efficiency of the release.

On the UX competence topic, I will talk more in a different article.