During my years in IT management, I heard more than enough cynical responses to the regular round of strategic changes handed down from on high.

One hardy perennial was ‘What goes around comes around’; the view that these changes never took us forwards but simply circled us back to somewhere we’d been before.

In the cynic’s eyes we would centralise, delegate, centralise again, delegate once more, then eventually get bored and go for a complete reorganisation instead.

It became known as Hokey Cokey management because we seemed always to be putting something in, taking it out or shaking it all about.

This cycle is understandable. The benefits of the new tend to blind us to the value of the old, until we start to see the shortcomings of the new and the old way suddenly seems attractive again.

By this time it’s effectively become a new way because most of the people who were around when it was the old way have moved on, leaving only the old cynics tutting and rolling their eyes.

It’s been happening for time immemorial in our personal relationships. When X says to Y ‘I’m leaving you because Z can give me all the things you can’t’ there’s a fair to middling chance that X is conveniently forgetting the things that Z isn’t so hot at which Y can do standing on their head (not literally, so stop smirking).

Outcome: X comes crawling back to Y after a while, and if Y has any sense they tell X to take a flying jump.

Of course, business decisions aren’t the same as our personal ones. They don’t normally stem from naked lust (I hope!), they tend to be driven by quantifiable business imperatives (cheaper, faster, better than the competition), and they are based on the proven premise that new ways of doing things are usually better than the old.

When you have strong business drivers for change and an alluring new model which enables you to meet them, it can easily create what I’ve called the anti-legacy legacy. You don’t just replace the old way, you make sure you discredit it completely and turn ‘legacy’ into a dirty word. You do this because

You need to be totally focused on making the change happen; the more you accept about the old way, the greater the risk that your change will be diluted.

Stakeholders want to see total commitment to bold, visible and decisive change. If they’ve brought you in to clear the swamp, hearing you say “I get it, but those water irises actually look pretty cool, can we keep them?” makes them nervous.

Legacy people working legacy processes tend to fight to hang onto them. Going in hard with all the things that are wrong with the old way helps you loosen their grip.

Legacy bashing is a great way to vent all the frustrations that have built up with the old way of doing things.

These are all valid reasons for being tough on legacy, and I’m sure there are others.

So what’s the problem with taking this strong anti-legacy approach? After all, we are meant to be the steely-eyed agents of change, not lily-livered liberal fence-sitters.

For me, the big risk with a radical anti-legacy approach is in throwing the good legacy baby out with the bad legacy bath water.

This may sound obvious, but generally the good legacy baby is hiding in very murky bad legacy water, and you probably have a bunch of shareholders or a CEO shouting that they need that bath water thrown out NOW!!!

I think this is best illustrated by a couple of examples, one from my specialist field of IT and one from the wider business realm.

In IT, I remember the early days of what became Agile, and being taken aback by the evangelical zeal of its pioneers.

The old waterfall methodology was pretty much regarded as the Antichrist, and I wasn’t the only one to receive a tongue-lashing from Tom Gilb and his co-creators for daring to question whether Agile really was the answer to everything.

After all, God created the world in six one day sprints, not after a billion year analysis and design phase.

True, waterfall projects were often painful for IT and customer alike, and the Agile promise generated a feeling of release for everyone.

Trashing waterfall was part of the catharsis, and I had certainly suffered  enough waterfall projects to buy into that.

But I was and still am wary of the view that you can build anything and everything using Agile techniques and that waterfall is just plain misguided.

I’m aware that waterfall is still used quite extensively, I just get the feeling that it’s never lost that stigma from Agile’s early days.

My caution stems from my view that Agile techniques work really well when you already have architectures and components to facilitate rapid delivery of user value.

Without these, Agile can easily deliver a mess of services and an integration nightmare.

If you already have Lego, building a four-bedroomed doll’s house using Agile is a cinch.

Work with the customer to deliver a high level vision and run a sprint for each room, and evolve the overall design by rearranging and tweaking components as you go along.

But what if you only have the plastic granules? You have three options:

You use bad old Waterfall to design a complicated mould for the whole house, which you have to keep redesigning as requirements change, and one day in the far future you might get to melt your granules and mould the damn thing, just before the requirements change yet again.

You use a basic Agile approach, you engage with the customer to agree a high level end vision for what the house will look like, then work together to produce a simple mould for a single room and rapidly deliver it. You now have the challenge of building the rest of the rooms around this one, without having much of a clue how they will fit together. Quick and satisfying for one room, risky for a whole house.

If you’re smart, you design your Lego, create the moulds and your automated injection moulding process, and sit down with the customer when you’re ready to start banging out custom spec Lego houses like there’s no tomorrow.

Critics of waterfall in IT sometimes overlook that the first IT developers effectively only had plastic granules, and that they still twigged from a very early stage that they needed to design Lego.

When I started as a programmer 35 years ago – on the timeline of IT development historically, roughly halfway between now and when commercial IT started – maximising reuse of components was already well established, and we were already embarked on the road that would take us to objects, service oriented architectures, APIs and containerised applications, the building blocks on which Agile IT development depends.

Fast forward to today, and we have reached a level of maturity where we can often develop these components using an Agile approach.

Even now, though, the big transformations and the complex stuff often still needs that element of waterfall which involves taking time to analyse the problem and create a comprehensive, robust design before you build.

At the business services layer, Agile only came in when pretty well all the core basic business functions had been computerised by bad old waterfall, so it had an extensive base to build from.

Consider if you had to set up all the IT for a major manufacturing business from scratch today without access to SAP, Oracle, Microsoft, AWS or any of the other pre-built IT solutions – could you create all the IT rapidly from the ground up using only Agile?

Criticism of the waterfall legacy has been overstated – necessary for Agile to get established, but harmful to it building on the platform that Waterfall delivered, and to our ability to deploy Waterfall effectively where it is still  the right approach.

Agile is too well established and valuable for us to see a full ‘Hokey Cokey’ comeback for waterfall,  but this is because we have evolved mechanisms to adapt to Agile’s shortcomings in delivering the complicated layers of data, core applications and infrastructure.

DevOps, which recognises that you can’t just keep delivering functional user value without reference to infrastructure and operation, is one example of this, application containerisation another.

Looking at the wider business environment, you can see anti-legacy at work in the way established companies respond to disruption and competitive pressures.

Consider an established business which runs on strong brand value, with high customer and employee loyalty, and ways of working evolved over many years.

What happens when this business faces dangerous competition from disruptive new entrants?

Clearly it must adapt to survive, and that generally means having to focus ruthlessly on the business fundamentals of revenue and costs, with brand values taking a back seat.

Pan Am, Woolworths (in the UK), British Home Stores, Toys r Us, Maplins; there is a litany of defunct brands which people remember fondly, but whose brand value could not save them at the crunch.

In this environment, “Show me the *@%#ing money!” becomes a necessary mantra, and full anti-legacy mode is a short step away.

If you need to make rapid root and branch change, it puts you in a stronger position if you start by rolling your eyes and shaking your head at just about everything in the current setup; the product, the working practices, the supply chain, the suppliers, the employment contracts and perks, the long-term employees, the pension scheme.

If you begin by recognising that there are elements of the business which were right when they were put in place, and that some of these are still valuable, change is likely to be harder, slower, and you’re more likely to run out of road before you can reap the benefits.

The necessary trade off of this anti-legacy approach is that you risk causing damage to those underlying aspects of the business which may not immediately show up on the balance sheet, elements like service quality and brand value.

I have seen cases where this has led to Hokey Cokey management decisions: for example, businesses which have gone heavily for outsourcing to reduce cost, only to start insourcing again when they realise that they needed that part of their legacy to meet their customer expectations and service levels.

Insourcing to improve customer service is a fairly clear bit of Hokey Cokey backtracking on anti-legacy.

Anti-legacy’s impact on brand value, and the consequential long term effect on the business, is harder to judge, and potentially more worrying.

When you rip out legacy to meet an immediate business imperative, your brand may well suffer. That’s not too much of a concern while your balance sheet remains healthy, but experience tells us that declining brand value can hit the bottom line hard sooner or later, and it’s notoriously difficult to get back once it’s gone.

To take the bleakest view, you could argue that an established business facing disruptive competition can either choose to fall back on its brand and die quickly, or rip out its legacy and die slowly as its brand withers away.

I don’t believe this is inevitable, but avoiding it takes either some pretty innovative brand recovery actions or some Hokey Cokey management to put back the good legacy bits which sustained your brand before.

In summary, whether you’re a CIO or a CEO, I believe you can either trash your legacy and be prepared for some Hokey Cokey management later, or, if you have the luxury of time, recognise and build on that legacy so your agility stays based on a strong core.