Are the days of waterfall change and transformation... over?

In the age of volatile, complex change, is there still a need for an “end state”?

What’s goin’ on?

Roughly 15 years ago, “agile” as a way of managing change, became much more prevalent in the business world. It was an old story in the technology world. But nearly beyond technology suddenly became subject to an agile approach.

Driven largely by the dominating impact of technological change on many aspects of our lives, and as agile emerged as proven way of developing software solutions rapidly, there has been a natural tendency to approach almost every aspect of business change using agile.

And in the change implementation world, agile has placed a serious challenge at the door of the planned change approach.

So what about it? Does the change and transformation space need to move with the times and update for agile? Or more radically – are the days of waterfall (planned) change management over?

The Pro’s for agile:

Today and moving forward, technology is even more pervasive, and sometimes all-encompassing in business change.

Everywhere you look, technology is impacting or enabling some change in the way we do things – in the wider world, and importantly, inside organizations. The rise of digital transformation as a new business area is one testament to the onslaught.

And so everywhere, this seeming constant state of “becoming” – always hanging between the next development release and the not-quite-ready current state is becoming the new normal. Which doesn’t feel at all like the old paradigm of planned change (typified by waterfall implementation approaches) – where there was some seeming sense of an end-state.

As we move into becoming more “agile” and “user-defined” in our design approach and “VUCA-enabled”, should we throw out the concepts of “waterfall” and “planned change” altogether? How do we frame change when the end never really arrives?

The middle ground:

I posit for a little of both.

There are many aspects of business that, previously – say in the last 5 to 10 years – have had to seriously re-think the way they implement change. Business functions, in particular the regulated aspects of Finance, HR, HSE (Health Safety and Environment), Medical and Regulatory (in financial services), have been significantly impacted, since introducing agile into regulatory and more annual update cycle environments runs quite counter to traditional implementation.

But in the wider organization context, change – even radical change – based on technology, is the new normal. No mention of when how we do things in the present might change again – and often very low certainty or “end-state” realities. What if you could automate regulatory updates in financial systems? Wouldn’t that change the way you implement change?

Implications for change leaders:

Why not completely drop the idea of staging your change and transformation with water-fall like mid-points and end-states in favor of 100% agile?

First – consider whether it useful to frame change and transformation in organizations as “constantly changing”?

Consider whether the introduction of boundaries around which we frame cycles of agile might serve some purpose.

Businesses entities and the sub-components that make them up are at different states of change – and likely will continue to be. Going forward, they will attaint levels of stability – but at different times – in their on-going iterative regulatory cycles.

Would having end-states to agile development environments – i.e. similar to coming to the end of a waterfall – serve the useful purpose of taking stock of the accumulation of change? Would re-aligning while change continues create the ability to update the agile process itself?

So what?

The upshot of this dilemma is that we would be well advised to continue to seek out the “fit-for-purpose” implementation approach as opposed to land in one camp or the other.

Here are three metrics to evaluate your implementation approach and frame it over a defined time horizon (or not):

Technology is driving much of the change in organizations – and there’s nothing wrong per se with agile.

What you’re really looking for is the right fit for the change you’re contemplating.

The uptake of a bad installation is the other side of an excellent implementation of something that doesn’t get taken up. Neither is desirable.

It’s just that in the first case, you would know much sooner that the thing being implemented isn’t going to work – and thus costs can be better contained; and demoralized – and in the worst cases, traumatized – end-user environments, avoided; and change knowledge retained.

In a strictly agile implementation, it is much more difficult to determine adoption since the adoption period itself is subject to change. But phased roll-outs of releases, which fits with a waterfall frame, could be helpful to your most important stakeholder – your change-frazzled end-user...!

Zimmy’s musical reference for this post:

Deep Purple, Smoke on the Water (1972, live in London): (https://www.youtube.com/watch?v=ikGyZh0VbPQ)