Agile Business Change
Moving to Agile? Is your Business Change strategy coming with you?
An increasing number of companies are ditching ‘Waterfall’ in favour of ‘Agile’ methodologies to develop and release new technology across their organisations. If you’re not sure of the differences between these, Agile focuses on delivering fewer, more valuable features, more frequently, and adapting future releases based on end-user feedback; conversely, Waterfall releases all (or most of) the product features after a lengthy period of time.
There are a host of benefits associated with using Agile methodologies which support Business Change activity. These include:
· increased collaboration and closer involvement of end-users in the design process,
· a focus on developing features which create the most value,
· faster times to release updates, and
· bite-sized chunks of change, making it easier for end-users to adapt.
These benefits can ensure staff will want the change and will adopt to the change more successfully.
Whilst the advantages described paint a positive picture of happy end-users getting what they asked for in rapid succession, delivering change using Agile can prove more challenging than initially anticipated.
Agile creates a level of uncertainty regarding the features to be released at the end of development ‘sprints’, as the ‘product owner’ navigates the ‘backlog’ and the team grapple with developing the features on time. For managers of Business Change, this makes it more difficult to assess the change impacts which importantly inform plans for training, communication, and engagement.
Additionally, whilst change might be small, true Agile delivery means end-users need to get comfortable with a consistent level of change. Creating the right culture that fosters resilience and generates continued enthusiasm for change is a real challenge, especially as change fatigue can inhibit the success of large-scale IT transformation.
These challenges highlight the need to carefully adapt the approaches used for Business Change. The successful implementation of Agile change requires consideration of how your employees will experience the change. Here, I offer some suggestions that may help your Business Change strategy keep up with Agile:
Communicate the big picture first
If your IT team don’t tell you the exact functionality that end-users will receive, don’t panic. Engage end-users in a vision of the future by communicating why the change is happening and how they will benefit long-term. As the picture becomes clearer ahead of each release, fill in the blanks to build excitement about impending improvements.
Set expectations around the pros and cons of Agile
Pro: “You’re going to get smaller changes to technology, rather than all at once, which will minimise disruption to your job.”
Con: “The new technology will be a work in progress, and we need your feedback to make it better!”
By setting the right expectations with end-users, they will get used to what Agile means for them and early-adopters will be more forgiving when there are issues with the new technology.
Adopt the great advantages of Agile
Agile encourages frequent end-user feedback about the product design, so why not solicit feedback about the success of the Business Change efforts at the same time? Showing these stakeholders that they’re being listened to on the technology front and how they’ll experience the change will improve engagement.
Iterate, iterate, iterate
Your developer colleagues will feel a sense of freedom to deliver an early-stage ‘minimum viable product’ (MVP) and subsequently iterate it based on valuable end-user feedback. You’ll have little option but to iterate your usual suite of change impact assessments and training needs analyses alongside the development of the technology. Look for ways to embrace the uncertainty and build flexibility into understanding what the change means for end-users, for example, by using a visualisation board to track impacts as they arise.
Don’t be scared to bend the rules
Agile purists will want to stick to the rules that makes it so successful, but don’t be scared to break out of the ‘daily stand-ups’ when it makes good Business Change sense. For example, ‘show and tells’ at the end of sprints may focus too heavily on the technical detail, creating a gap in explaining key messages to your most important stakeholders. Fill the gap with engagement events tailored to stakeholder needs.
Not having a plan for how you will adapt your Business Change approach to embrace and support Agile development may land you in an uncomfortable position, where what works in traditional Waterfall situations may no longer be of benefit. Spend the time to understand how end-users will receive the change in order to maximise the success of your adapted approach.
This article was written by Tom Shorney, Manager at Alchemmy.
Want to discuss Agile Business Change further? Connect with Tom on Linked In or email Tom.Shorney@alchemmy.com