Checkout

Total items: 0

Subtotal excl delivery & tax: £
Menu
Search

Optimize Your Change Management Initiatives

javier-allegue-barros-c7b-exxpoie-unsplash.jpg

Agile Change Management is the alignment of Agile project delivery and the activities needed to create new ways of working. It is this partnership that realizes benefits and leads to return on investment.

Change management activities are all the work that a business undertakes to design, develop, implement and adopt new ways of working. There is pressure on organizations to speed up these activities, because Agile approaches deliver high volumes of change on a regular and frequent basis. If change management activities take too long, then the business is still preparing its response to one wave of change, whilst the outputs from the next Sprint or Increment are queuing up to be implemented. This delay leads to a hold up in realizing the benefits which breaks the promises made in the original Business Case for the project.

Simplify change management activities

To create the necessary speed for managing change, it is helpful to ‘automate’ these activities. Make them as simple to understand and easy to carry out as possible, so that they can be undertaken quickly (because the time between changes is short) and frequently (because the volume and regularity of change is high).

As part of the completion of every Sprint, run through a checklist of points to how much work is needed. For example:

  • Are we changing the inputs to any of our processes? This includes the data we make available to systems, the format of this data, the time when it is available etc
  • Do we need to change our operational processes? This includes removing steps from the process because we have automated the work or adding in new quality reviews or sign offs.
  • Do we need to change our maintenance processes? This includes contracts for support, timetabling updates etc
  • Do we need to change our security processes? This includes who can access systems and information and what information can be changed or shared.

Review those involved in the work that is expected to change, using this simple Community Map diagram:

agile1.png

Have a set of standard questions available to ascertain what needs to change. For example:

  • Roles, responsibilities, reporting lines and levels of authority
  • Activities in a process
  • Documentation used to carry out a process
  • Frequency and/or time when set tasks are carried out
  • Equipment needed to complete tasks

Use this information to identify the actions needed to make change happen. To appeal to your Agile colleagues, write them up as User Stories.

User Stories

A User Story is a way of expressing an objective or requirement so that it is directly attributable to the individual or group that needs it:

change2-1.pngFor example:

As a Customer Services Manager

I need developers to show me the changes to the data input screens

So that I can identify what steps to remove from the existing process

As a Call Centre operative

I need to know what the new information we need from customers

So that  I can change what I say on the phone to customers

By having these User Stories ready for inclusion in any Product Backlog, the implementation activities can be prioritized alongside the creation work from the start of the initiative.

Daily Stand Ups

Daily Stand-Ups are also known as daily scrums, where all those working on the change come together to give a brief update on what they have done since the last stand-up and what they are working on between now and the next stand-up.

By including change management activities as User Stories, they get picked up as part of the work of a Sprint, so are discussed at the Daily Stand Ups. The meeting provides up to date information, ensuring that everyone knows what everyone else is working on so that it is easier to collaborate, to identify and resolve dependencies, risks and issues. The meeting helps the team get things done and minimize the need to escalate to senior managers.

Kanban Boards

I want the teams running each of the Sprints to use a Kanban Board to demonstrate their progress. Kanban is a simple technique for visualizing the work involved in making change happen. There are 3 columns:

  1. To Do
  2. In Progress
  3. Done

Each task is written on a sticky note, and these notes are moved from column to column as the work progresses.

change4.png

Each of their User Stories can be shown on a Kanban Board, so that progress can be visible to all by sharing the latest picture of the Kanban Board as part of a weekly blog.

If you are working with teams who are not co-located, pictures of each of their Kanban Boards can be sent in to form an overall Kanban Board that summarises the progress across the globe.

Cautionary note

I think that we need to re-think how we support the implementation of change created by Agile approaches, and the ideas described above can help to regularise change management as a well-defined, and easy to apply business service.

However, I think it is important to clarify the risks that Agile approaches expose businesses to:

Whenever we are implementing change, we are asking humans to learn new habits and unlearn old ones. This is a complex psychological and emotional process which is hard to rush. Essentially change management involves creating new habits, and we all know how much repetition is needed before something becomes the new norm. How much can we really speed up the emotional acceptance of change and the amount of time needed to practice something until it becomes the new ‘unconscious competence’?

Because of agile methods, the volume of change is much higher. We are not asking people to prepare themselves for one change, ae are asking them to adapt to a world of constant and unrelenting change. Whatever we do, we have to support our actions with a narrative that sets this new reality of constant change, and that nothing is ever completed. There is always another version coming soon, so people are being asked to work in an environment of non-permanence. That suits those who believe change is good and standing still is risky. But for those who get comfort and confidence from stability, these “shocks” keep coming, making it harder for them to cope.

Conclusion

Agile continues to drive new approaches in project management and change management. I think we are only at the beginning of the journey to helping staff cope with (and perhaps even thrive) in a world of constant, unrelenting change. This paper scratches the surface of ideas to manage high volumes of change, and I would love to hear your ideas, as we need to keep learning from each other.