Think of the last change your business went through. Was it successful? Was it truly successful? If so, brilliant! Please put up a blog post about it and send it to me. And… you no longer need to continue reading this post. You cracked it! :-) For those of you whose change management wasn’t successful… what were the top complaints? Chances are, somewhere in the top five, were ‘lack of transparency’ and/or ‘lack of/no communication’.

I’ve been through way too many organisational changes. I have done my best to change how change is managed. I have compiled feedback on change activities. I have advocated the change while understanding the confusion and fear said change caused. And I have come up with a theory…

…what if we did our change within an Agile framework…

Yep, I heard that pin drop. Humour me.

Before I go into the reasoning, what I want you to picture is this happening…

Daily standups consisting of representatives from each of the areas involved in the change – the team lead, the programme manager, HR, Finance, Communications, Learning, Recruitment, Legal etc. They take place every working day, and using a Jira board to track their actions they update everyone on what they did yesterday, what they are doing today, and what their blockers are. Instantly we have transparency of what each other are doing, can alert to any changes they should be made aware of, and know where there are blockers. This is your first instance of Transparency, one of Agile’s Three Pillars.

Backlog Refinement meetings where tasks are updated, moved in priority according to what is happening in the business and with the team in question. And attended by the team lead, the programme manager, HR, Finance, Communications, Learning, Recruitment, Legal etc. Here is the Adaptation within Agile’s Three Pillars. Refinements happen once or twice each sprint depending upon business activities. 

Sprint Review where your most important stakeholders, your primary stakeholders, are the people who are being impacted, ie being moved to a different team, having their job role changed, being made redundant; your secondary stakeholders are those who will be impacted, but to a lesser extent ie they may be working with a different contact, they may need to prepare new employment contracts. The Review brings in the second instance of Transparency. The Sprint Review is once per week as the sprint completes. Any tasks not completed get refined and either carried over into the next sprint, broken into smaller tasks, or taken out completely if no longer necessary.

Retrospective…being able to identify what is not working and understanding why is crucial. Here is the Inspection within Agile’s Three Pillars. Retrospective is once per week following the Sprint Review.

Sprint Planning is when the team agree on what will be done during that sprint period, ie how many tasks, in what order, and who by. You will estimate how long each task will take and if there are any dependencies not picked up earlier. A sprint can be a week, it can be a month, or a quarter, but the ideal is fortnightly. Sprint planning is done following the retrospective.

Let me know how you get on, or if you want more information on how to implement this process in your change.

Resources

Three Pillars of Scrum: Transparency, Adaptation and Inspection by Knowledge Hut –  https://www.knowledgehut.com/blog/agile/scrum-pillars#what-are-the%C2%A0three-pillars-of-scrum? (First lesson in adaptation… is to see past the software development aspect of this blog and open your mind to how it could work with change)

What is Agile Methodology? A Beginner’s Guide by Asana – https://asana.com/resources/agile-methodology

©Fiona Doney 2024