Agile and DevOps: myths and legends (part one)

Agile and DevOps is a state of mind, an attitude towards working that transcends the technology of both then and now

I regularly come across claims that Agile delivery has only become possible as a result of the parallel arrival of DevOps and the shift towards containerised infrastructure and services.

Like a bizarre twist on Bjorks “The Modern Things”, Agile has supposedly been waiting in a mountain for the right moment, confident that the old order has been silenced. A “two speed” delivery model has emerged as a result of this claim – based on a fundamental assumption that an organisations heritage technology is physically incompatible with this lean new world of Agile and therefore needs to be kept at arms length from it.

From a distance this seems an attractive and practical approach but it is a lazy one which asks neither why nor how large organisations developed such inertia around their traditional IT operations in the first place. By not asking those questions of themselves large enterprises (and the professional services feeding off them) are able to keep propounding the myth that old tech = slow tech. But it was not always this way…

My early years of banking IT involved small collocated cross-functional teams. Distinctions between business and IT were grey areas and loosely enforced.

We delivered changes on Sundays.

We delivered changes on Mondays.

We delivered changes on Tuesdays.

We delivered changes in the morning.

We delivered changes in the afternoon.

We delivered changes that worked first time.

We delivered changes that didn’t work and were rapidly fire-fought by the team who had delivered them until they did.

We delivered small changes that took two weeks from inception to delivery.

We delivered large changes that were years in the making.

We performed coding reviews in groups of mixed ability and experience. Novices spotted howlers and together we grew our confidence.

User-centric test plans were written and executed by the same people who had conceived and documented the requirements.

IT applications were supported by the same team that originally built them.

We sometimes made changes to how things worked for no reason other than our urge to improve them. We made our software (and thus our products) faster, smarter, cheaper and generally BETTER. We didn’t need to be asked first. We were aware of the old adage of not fixing something if it wasn’t broken, but frankly we very rarely did break anything, and very very rarely for long enough for anyone to notice. The success rate for enhancements to a product when performed by the same team that built it is remarkably good.

We utilised sparse and infrequent data on how products and services were being used as intelligently as we could, even when it told us things we didn’t want to hear.

All this happened on and around “legacy” technology platforms during the era of pagers and dial-up modems. We did these things because it was the right and natural way. The inclusion of a Mainframe in our technology footprint was never considered a hindrance.

But as you will have already guessed, it did not last. By the mid to late noughties changes had taken place which fundamentally altered our ways of delivering and working together. Some were unavoidable consequences of the need to scale whilst simultaneously managing risk – others the bewildering legacies of past leaders in whom much faith was once placed.

Policies change first, in creeping and subtle ways but their traction increases as the organisation slowly sheds its old skin. This is a phenomenon of glacial proportions and duration. To catch it moving, you must watch for a very long time. Only us hostages who remain know of it’s methods.

What I witnessed over the last two decades was a gradual layering upon layering of process after process. Activities which once occurred and were managed naturally became increasingly subject to formal requests, rules, approvals, sign-offs and schedules. Trust became eroded, it’s worth diminished by overlords fresh with policy to defend their new empires. No travelling cross-country now, you must take the road at all times. Systems were required to break, sometimes spectacularly, before approval to alter them in any way could be secured. The new mantra was Control – not a centralised intelligent and thinking form of control but a strange decentralised and dysfunctional maelstrom of multiple controls, starved of the feedback necessary to modify and improve themselves.

I write this not to simply debunk Agile and DevOps with some predictable and crass “we invented it first” claim but to highlight it being a state of mind, an attitude towards working that transcends the technology of both then and now. Consequently it is difficult to simply (re)import such a state of mind into an organisation when the conditions which originally supported it have been so deliberately and meticulously dismantled.

Three questions need to be asked:

• What caused this to happen?
• Can it be prevented?
• Can it be reversed?

This is the first of two writings on this topic. In the second we will explore the answers to these questions.

By Howard Crisp
Howard is a 20 year plus veteran of a major global financial institution and has during that time developed and supported numerous systems in the commercial and corporate banking space. Views expressed are his own.