Discover your dream Career
For Recruiters
Prepare for disappointment if you join a bank as an Agile specialist.

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

author-card-avatar
AUTHORRanjan Kamath Insider Comment
  • Ag
    Agility Gurus
    11 October 2020

    Some feedback on this

    https://www.linkedin.com/co...
  • Jo
    Johannes
    28 April 2020

    The bank kernel sometimes still runs on an old fashioned mainframe in Cobol and in assembler code. Touching these kernels is risky. The agile way is mostly used in projects where the bank kernel is not touched or in bank fusions with compete IT migration (which also not touches the running kernel) . What I have seen is that agile projects are, web visibility layers, data analytics or new web based services, a kind of project that is loosely coupled with the kernel. The problem arises as above stated, because the Business departments have a different goal set then IT. Am I getting the client to sign with the 1B loan ? Is the balance sheet compliant? Does the refinancing meet the predicted risk values? Are we properly reporting to the regulator? Do I keep my job? In many of these aspects IT plays an important role, but all these concerns have never changed since the last centuries. Therefore in a waterfall project one can imagine the result, in an agile project one can not imagine the result, because it is not analyzed in front. This makes employees working on main banking processes very nervous and is out of their interests.

  • An
    Anondev
    19 October 2019

    Comments section is a safari for anyone who wants to see defensive No True Scotsman in the wild

  • Kr
    Kris
    15 August 2019

    Unfortunatelly what the article describes is an example of poor attempts of implementing agility. I have spent several years at ING seeing how the agile approach was providing the bank a huge competitive advantage, just it wasn’t at all about post its and standups. There’s more to agility than that, for example Lean innovation, using design thinkjng and Domain Driven Development. Prince2 gives you only a false sense of certainity and false control. But I understand that its prescriptive approach is easier to accept than the d complexity of finding the right take at making the business Agile.

  • Je
    Jeremy Pulcifer
    14 August 2019

    Hilarious.

    'Banks aren't Agile and they never can be; it's best that you know this from the outset.'

    Maybe your bank.

    I've worked in regulated industries, corporate finance, and banking for over 20 years. The one process that has been statistically proven worst: waterfall. And that's including not using a process at all.

    Of course, agile can be done badly, and often is. Note also that most of the issues above (developers afraid for their jobs!) are management failures.

    Disagree? Go to Ally, Chase, Wells Fargo, Citi, BofA, Amex and tell them agile doesn't work.

    Also, why the pseudonym?

Show more

Apply for jobs

Find thousands of jobs in financial services and technology by signing up to eFinancialCareers today.

Boost your career

Find thousands of job opportunities by signing up to eFinancialCareers today.
Recommended Jobs
Alexander Ash Consulting
Business Analyst/Project Manager (Front to Back Change)
Alexander Ash Consulting
London, United Kingdom
Financial Services
Change Manager
Financial Services
London, United Kingdom
Eximius Finance
Senior Regulatory Control + Change/Projects
Eximius Finance
London, United Kingdom
Canada Life Limited
Function Lead - Cloud Enablement & Adoption (CEA)
Canada Life Limited
Potters Bar, United Kingdom
Goodman Masson
Senior Risk Officer - Post-Brexit Regulations
Goodman Masson
London, United Kingdom