The third way: applying Agile to big banks
As banks are moving away from the rigid approach of Waterfall projects, the other option, Agile, can also present challenges. Its flexible qualities don’t fit naturally with the challenge of planning budgets aligned to specific end-goals, dealing with legacy systems and working towards regulatory commitments, to only name a few.
Agile is often associated with smaller, more technology focused, companies lacking the large legacy systems which often cause the problems. Their nimble governance structures and political simplicity lend themselves to the fast-paced world of Agile in a way that the bureaucracy and stubbornness of big banks doesn’t.
But in a bank?
Most banks would require a tectonic shift in culture to allow teams to move away from deadlines and structure to an environment that actively encourages full fluidity of scope with last-minute changes to requirements. In banks this is especially pertinent; with a significant portion of activity driven by regulators’ timetables, large banks must operate in a way that provides clarity and transparency.
But there is a third way, where harnessing all the benefits of Agile does not mean tossing aside scoping activities or working to strict deadlines.
This is where SAFe comes to the fore, an incarnation of Agile that is specifically geared towards large companies and projects. SAFe stands for Scaled Agile Framework (not forgetting the “e” to keep it catchy and incorporates some disciplines that help align teams within large programmes. It enables a programme to follow a vision collaboratively developed with senior leadership, where all parties commit to what is going to be delivered over the course of the next Program Increment (PI). SAFe itself is constantly improving (currently on version 4.6), leveraging principles of other methodologies in a constant effort to adapt and stay relevant.
“There is a third way, where harnessing all the benefits of Agile does not mean tossing aside scoping activities or working to strict deadlines.”
The practices described below aim to minimise the most anarchic practices of Agile that are prohibitive to banks, while retaining the many benefits that can be realised through Agile development.
How does it work?
The key elements of SAFe are: Program Increments (PIs), an Innovation Sprint, and Release Trains.
Program Increments are a collection of sprints, usually five, that are planned at the outset of each PI. The PI planning process may take place over a few days, during which stakeholders from senior leadership and across the program work together to set direction. Features and goals are agreed and prioritised that then allow teams to self-organise their sprints to deliver against these goals.
The final sprint of the PI is the “Innovation Sprint”, during which the program downs tools to critically assess the prior four sprints and identify improvements to the product and opportunities to innovate the ways of working for the next PI.
By doing so, the feedback loop essential to Agile is included but changes are agreed program-wide, keeping everyone on the same path and removing any lack of clarity that can feature in other Agile frameworks.
Release Trains further provide the structure essential for large banks. They are specific deadlines for when all teams will release functionality across the program, with all “trains” departing and arriving at the same time. The ability for teams to self-govern and determine exactly how an objective is met still remains, but the Release Train allows deadlines to be married up for seamless delivery.
Is it worth it?
Shifting the ways of working to follow Agile methodologies can be particularly painful for a bank that has grown used to the predictability and security of Waterfall. However, until the shift is made, Waterfall’s rigidity will cause the same age-old issues.
Equally, the unpredictability of some Agile frameworks means that they are not suitable for large banks that need to commit to – and deliver against – an outcome.
SAFe is the third way. It enables many Agile practices to be incorporated – putting the user first, iteratively improving, and enabling the self-organisation of teams, amongst others – without throwing caution to the wind. Regular prioritisation during PI planning also ensures that work that will deliver the most value to the bank is always done first.
“The implementation of SAFe at Standard Bank allowed the bank to reduce time-to-market from 700 to 30 days, decrease costs by 77% and increase productivity by 50%*.”
Implementing SAFe should be seen as an investment, an initial dip in productivity is to be expected while everyone gets used to the new way of working. Very quickly this loss will be made up for and benefits will be realised as value is delivered with each sprint, as shorter feedback loops minimise technical debt and self-organisation increases productivity.
A recent example of SAFe at Standard Bank allowed the bank to reduce time-to-market from 700 to 30 days, decrease costs by 77% and increase productivity by 50%*.
Critics will argue SAFe is too prescriptive and loses the agility that pure Agile methodology offers, and that is fair, but the additional structure gives confidence to senior leadership and project teams alike knowing that collectively the program is headed in the right direction. SAFe amounts to a sensible compromise for large banks, tying prioritised delivery to value for money through a flexible, yet clear roadmap.
* According to Scaled Agile Framework case study: https://www.scaledagileframework.com/standard-bank-case-study/