Where does Change Management fit in to business agility?
Working with organisations that recognise the value of an organisational Change Management capability, has given me the experience of some lively leadership debates around where within those organisations, their Change Management capability should reside. The debate was often polarised between a centralised team of Change Management subject matter experts (maybe reporting to the HR or the Communications department) providing services across the organisation, or individual people (often contract resources) funded by and reporting to specific projects as required. My short answer – “none of the above”.
If the Change Management specialist is sitting in a centralised team on the org chart, they may find themselves working across multiple programs at once. Available time and quality of work is reduced by context switching and being spread too thin. In this model, Change Managers often reported that it was difficult to add value as projects weren’t really interested in ‘managing the change’, but rather ‘ticking the box’ by following a schedule of predefined change activities. Being a step or two removed from a project means that often Change Managers are unable to implement feedback mechanisms that could actually impact the direction of the project.
Interestingly, Change Management experts reporting directly to projects expressed similar concerns; difficulties in actually ‘managing the change’ to add value. The causes were different and included the churn of short-lived teams, or funding constraints that resulted in Change Management being downstream towards the end of a project to simply action pre-defined ‘communications and training’ tasks.
Both operating models suffer from the impacts of traditional project and program management approaches (command and control, top-down, management heavy). They are not supported by mechanisms that allow the programs to listen and learn from their stakeholders. Change activities are locked in upfront.
Embed your change management capability into your agile teams
With the 2020 updates to the official Scrum Guide the product’s vision has come into greater focus with a Product Goal, alongside self-managing teams. As a result, there is now a stronger focus on product management over project management.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Product Management and Change Management are strongly aligned. Change Management is about listening to your people and stakeholders, the users and consumers of your product. Change Management can be that link between just creating the product and achieving the product goal. Don’t just assume the consumers of your product will ‘just get it’.
“The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
Embed your Change Management capability within your team:
- To get the people ready for the product, and
- To get the product ready for the people.
Undertaking Change Management in an agile way ensures your product is valued by those who consume it. A Change Management lens within the agile team will ensure that someone has their eye on Organisational Change Management concerns, and overcomes the traditional habit of assuming we know all upfront. It will keep the customer’s journey front of mind. Having Change Management as part of cross-functional agile teams helps build the organisation’s capability to truly add value to the organisation.
Ensure change management activities are in your Product Backlog
The Product Backlog contains all of the work needed to achieve the Product Goal. This should include all the activities for Change Management. These Backlog items, though, are likely to come from Change Models, such as Kotter or Prosci ADKAR. Kotter’s change models focuses on early leadership action and vision setting, others such as ADKAR focus on activities to bring the individual on a journey through Awareness, Desire, Knowledge, Action & Reinforcement.
Regardless of the Change Management model you are inspired by, the change outcomes required to support your product should be part of your Product Backlog and tested by the whole team as Lean Change Management experiments.
Integrate change management into Agile Events like Sprint Review
While change frameworks from Kotter and Prosci ADKAR are often interpreted as linear, most change practitioners don’t necessarily follow their linear progression. The smallest trigger may make a person’s view of value change dramatically. Not only does your product management need to be able to pivot and adapt rapidly to changes in stakeholder needs in response to marketplace conditions, but product management also needs to be able to adapt to the emotional and cognitive changes of your customers.
To adapt, you need to be continuously checking in. If you already have an agile framework in place then you are set up to listen and take customer feedback on board. Use your Scrum events – particularly Sprint Review – to stay focussed on value to the customer by engaging with your customers and stakeholders early and often.
Change Management as part of the Definition of Done
For work to be potentially releasable, the Definition of Done serves as a set of quality criteria for the whole team to work towards. As soon as a Backlog item achieves the Definition of Done it becomes an Increment.
Business, stakeholder and user readiness often require communications, documentation and training components. Rather than standalone items in the Product Backlog, Change Management as a part of the Definition of Done often includes:
- Training documentation iterated.
- Operating procedures updated.
- Business readiness assessed.
- Communications delivered.
Building an Agile Change Management Capability
To set up your organisation to succeed, Change should not be an afterthought or purely a downstream activity. It’s not a supporting service, it belongs in your agile teams. Bring it forward, bring it into the teams. Where possible embed Change Management capability within the team and help them build cross-functional Change Management skill sets within and across teams working at scale. Many Change Management practices complement the intent of agile practices so look at ways to implement the Agile Change Management Framework and Change Management principles into your agile approach.
