Banks only pretend to embrace Agile development

These days, with the onslaught of fintech, challenger retail banks and ever reducing margins, bulge bracket banks are all about "digital transformation” to unlock productivity and become more profitable. Marcus by Goldman Sachs is classic example. - Banks want to leverage the power of data, redefine their operating models and become digital driven organisations. Managementese nonsense aside, all banks have been trying to get their technology organisations to use agile software development practices in an effort to compete with the rate at which fintech rivals can release new products. 

Agile software development comes from the Agile Manifesto published in 2001. This set of principles was combined with a practice of iterative development called scrum. The idea was to release software to users every two weeks or so, with feedback from users going into the next development cycle. There are daily stand-up meetings to micromanage track progress on an agreed set of tasks for the cycle. There are many different tools and techniques that fall under the term agile. It has become a synonym for iterative development in general.

Many claims are made about how certain tools, technologies and practices improve software development. Indeed, a whole cottage industry of “certified" consultants and coaches around Agile engineering practices is now well established. I’ve seen them dotted around the banks I’ve worked for, trying in vain to effect some cultural change.

Now, it may come as a surprise but as an industry we actually know very little, empirically, about the effectiveness of software engineering practices. One of the reasons for this is that it’s incredibly hard to collect data given the proprietary nature of most large programming projects. Of the studies that have been done, we know for example that code reviews reduce bugs in production, and pair programming improves code quality with a trade off in productivity. The famous "10x programmer” who is supposedly 10 times more productive than the average developer? Well, it would help if we could come up with an objective way of measuring developer productivity for a start. And we can’t. Frankly, in my opinion, we are in the midst of a software engineering methodology racket. It’s all anecdotes and common sense, with little attention on studying outcomes or collecting evidence and banks like everyone else have been taken in by it.

The fact is that many technology teams in banks still do waterfall development even if lip service is paid to Agile. -  They may have incorporated some of the agile ceremonies, tooling and principles into their day to day work, but their product will only be used when it’s finished. Traders, salespeople and bankers have neither the interest nor the human resource on their teams to devote to product managing technology projects. Because of this, engagement with technology is contracted out to their business management teams.

This is the big problem with software development jobs in banks. Iterative software development of the agile scrum variety requires constant feedback and domain experts readily available. That doesn’t happen most of the time in finance. What does happen is a team will deliver a finished product and it’s not quite right - at that point there will be a rush with good business engagement on ironing out the bugs and shaping it into something usable. I’m not saying that there aren’t teams out there with very good business engagement practicing true scrum agile, I’m just saying that it isn’t the norm in large banks.

So, what should banks be focussing on in order to automate more aggressively? In my anecdotal experience, the stars need to align on a few fronts:

• Co-located teams of developers with a healthy mix of juniors and seniors and a strong tech lead. You just need good people who like working together and care first and foremost (this is hard).
• Rather than specifying the way to work (agile or otherwise), allow teams to self-organise, survey the politics of the wider organisation and agree an operating model with the business they support.
• First class tooling so that it is easy to integrate, test and release newly developed software.
• Cloud infrastructure with minimal bureaucracy so teams can manage and scale their hardware plant.

Highly engaged partners and domain experts in the business who are incentivised to give their time to technology projects (this is really hard.)

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 Patrick Perkins on Unsplash