"Agile" Change vs "Waterfall" Change

I was thinking over recent times about “Agile” Change vs “Waterfall” change or just change management as it has generally been practiced over the last number of years.
 

I get asked from time to time about my view on the difference between the old/current way of doing change and how we need to adjust our change approaches for Agile projects or even just for organisations where a more flexible or agile approach is needed.

So first off, what is Agile? I think different organisations treat it differently and do different things but Wikipedia’s definition is:
 

“Agile management, or agile process management, or simply agile refers to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner; an example is its application in Scrum, an original form of agile software development”

And just before we move into the crux of this blog it’s important to point out that Agile has been around for 15 years so not sure we can really classify it as “new” and then if you include the creation of Scrum by Hirotaka Takeuchi and Ikujiro Nonaka in 1982 and you consider that Scrum is a form of Agile  then its 30 years old!

My experience is that different organisations do implement Agile Project Management practices differently and some even use the term Wagile (being a combination between waterfall and agile although Agile purists will tell you its Waterfall masquerading as Agile!)

So let’s just agree it’s a faster, more iterative approach to projects and can involve the business earlier than would be typical with standard project management.

Having agreed on that – here is what I think you need to be thinking about to ensure you adjust your change approach to incorporate more adaptability and agility.

Firstly, is a mindset piece – mindset of a change team and a project team working in Agile is way more “flexible” “adaptive” – so thinking you can basically execute stuff on a linear timeline from change strategy through a structured framework can be overplayed and too slow in an Agile delivery. You must be able to pivot, change direction and be OK with that…………that doesn’t mean you don’t follow a framework – but you must question the need for massive change strategies and how long this can take vs still working through a change strategy or approach but that being more about principles of managing change, key risks, etc. not fifty page documents. In summary starting first with your MINDSET……think” I need to be more adaptive in my thinking and approach and iterate as I go and be comfortable with that!”

Assuming your mindset is sorted the other changes you might want to make are..…

Stakeholder engagement can increase – lots more going on more often with the business generally and deployments more often (in one client I worked with it was every 6 weeks!) so you need to be upping the ante on this – it may need to be someone’s’ full time plus focus

Communication – kind of goes with the Stakeholder piece that it needs to increase as well – if people are truly doing sprints and then actually making things live fairly often that ACTUALLY impact customers/the business much more often  (sometimes it can be technical sprints that don’t actually get made live in production) then more communication more often and you need to be creative about how you do this as you might not have the timeframe to repeat messages several times over a long period to ensure communications are understood.

Seat at the table – Change needs to be at the table when talking about what is delivered when – tech people can think a small technical piece they deliver in a sprint and make live is tiny but it can still have a big impact on business so need to be there when decisions are made around this

Experienced Change Team – I have found because its faster, more flexible, and things can change often, you need solid practitioners who aren’t perhaps at the start of their change journey and know how to flex with the changing scope and delivery that can happen with Agile projects

Involve the business – There is more need to involve the business in designing the change interventions – get people involved early in how we approach the change and co-create

Feedback – You need to be getting a greater sense from the business that the change is working so need to have strong feedback loops in place so you can adjust the approach as you need to – try things and adjust as you need

Training – for me a practitioner needs to be careful about how much training material you build and its longevity with things changing –– so be lean on creating materials knowing things will probably change – don’t go crazy on lots of Job Aids and formal training that will have short life spans…

Playing – as much as possible get people to play in the changes if they can - if it’s a system change  - find a way to give them access to a “sandbox” as implementation times can be faster so this type of familiarization can really help.

Testing - OK my experience with a large organisation using Agile change was that they undercooked the testing needed significantly and then things either went haywire in production or major delays in go live which creates levels of challenges for change managers – not much you can do about this personally but one thing to challenge the broader project team on and have in place how you will manage if things aren’t perfect when they are released…

And some final points from me on other key aspects of change

• Change Impacts – in the end we still need to understand and manage these – it’s still about how we move people from one place in the current to a place in the future – you just might use more agile tools such as impact assessments on a page or having them mobile and up on walls
• Sponsorship – still need it -still the most important factor for success
• Change Leadership – still hugely important that senior leaders are driving the change and owning it
• Journey Maps – these have been used a lot in recent years – again in Agile projects having one pagers, one page journey maps will be more common than long documents showing all the change activities.

Would love to hear about your experiences so please reach out to me or drop a note to us at info@allegraconsulting.com.au

Caro