COMMENT: The Agile methodology makes no sense in banking
I've spent two decades working in banks, delivering successful technology projects, and the time's come to raise my hand and say what desperately needs to be said: the Agile methodology and banks do not mix.
It's not a popular opinion, especially with the new generation of technology professionals, but it's something that needs to be confronted. Most banks are pretending to jump onto the Agile bandwagon and it's a big mistake. Agile specialists who join banks are only going to be disappointed.
At the root of the issue is the fact that banks are highly-regulated and hierarchical organisations, where end users (typically traders) have no real interest in participating in daily meetings to discuss the progress of a technology project.
This doesn't fit with the way Agile works. Agile is a set of principles that allow you to move forward without having requirements nailed down. Daily meetings between the scrum masters, developers and the product owner allow the product to develop through a process of iteration. In theory, this leads to a better product - the example usually given is that you start out with a Flintstones car and end up with a Ferrari.
In banking though, the 'product owners' in the front office usually have one thing to say when you ask them to participate in daily Agile meetings, and it ends in "off." This means that the meetings are typically attended only by a proxy, who won't really be using the product.
Agile can be bad for developers too. When you're compelled to stand in a meeting every day and to write a post-it note declaring what you've completed, you can be pushed into rushing things or creating sloppy work simply for the sake of having something to say. This is especially the case in banking, where people are often fearful for their jobs and don't want to appear to be under-performers (even if they're not).
More importantly, though, banks are working in a highly regulated environment. When you're implementing a project in a bank, you need continuous checks and documentation. You need methodology documents, logs of meetings, and a record of any remedial action taken when problems arose. Agile doesn't necessarily provide for all this.
What does? Well, try the waterfall methodology of Prince2. Here, you have terms of reference explaining what you're doing and how you're doing it. You have an implentation plan for the people building it. And - most importantly - you have your RAID (risks, assumptions, issues and dependencies) checklist which is applied at every stage.
I'm not saying that Agile doesn't work, just that it doesn't work in banking. Agile is a great methodology if you're a group of developers producing code from the bottom-up and developing flexible products on a rolling basis at somewhere like Amazon. But when you're in a large, very hierarchical organisation with remote end-users and a zealous regulator, it simply can't work as intended.
Needless to say, banks are realizing this and most use some kind of hybrid between Agile and the more 'top down' waterfall methodology. This makes sense, but can be a shock to Agile purists who join from other industries, particularly if they believed banks' hype about embracing a new way of working. Banks aren't Agile and they never can be; it's best that you know this from the outset.
Ranjan Kamath is a pseudonym.
Have a confidential story, tip, or comment you’d like to share? Contact: sbutcher@efinancialcareers.com in the first instance. Whatsapp/Signal/Telegram also available.
Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)
Photo by İrfan Simsar on Unsplash
