As system integrators and software developers can confirm, in recent times, financial institutions have grown increasingly interested in Agile delivery. While some might say it was about time, given the consensus on the efficacy of Agile in enabling organisations to adapt and respond better to change, enterprise-wide Agile applications remain regrettably immature. Gartner’s Hype Cycle for Application Development keeps confirming year after year that, notwithstanding a few success stories, Agile is marked by a significant reluctance to adopt, mainly due to inflated expectations and recurring implementation failures.
The lag in adopting Agile by Financial Institution should not be a surprise. Historically, it has been one of the most conventional and conservative industries, struggling with massive changes in technology platforms, payments and financial systems, while attempting to deliver appetising services to their customers and complying with burdensome regulations.
After being adopted by many software development teams, also in the financial industry, during the early years of the web, Agile was broadly deprioritised, and its frameworks (wrongly) labelled as inherently chaotic and undisciplined. After the financial crisis of 2008, however, IT departments within financial institutions have consistently tried to improve performance and speed, while also dealing with a tsunami of stability-focused regulatory re-calibration.
Just a few years ago a survey from Accenture suggested that traditional banks could lose more than one-third of their market share to digital competitors by 2020. That is probably why financial institutions inevitably turned to technology, the primary source of success in an industry in which the uniformity of core services has made standing out a challenge.
We cannot ignore the fact that a large lump of the yearly budget allocated by most of the banks, is already going to the maintenance of the IT infrastructure, due to a less forward-looking factor that massively hits banks. A vast and ageing legacy network is holding back the banking industry. After the massive investments in the late ’90s, these systems now require constant maintenance and custom developments to integrate them with new technologies.
Larger banks usually also have to coordinate development between segregated teams that work on separate stages and component, frequently across different time zones, each of them with a few layers of management.
In this cost analysis driven reality, it is not difficult to understand why financial institutions prefer to define requirements and cost before starting development and why waterfall methodologies are usually preferred, due to the perception of having more predictable and defined outcomes. Moreover, the general misperception of Agile has ultimately bled into unjustified concern on the lack of audibility and transparency in its frameworks. In fact, waterfall methodologies quite often stray far from their expected outcomes, and they result in yet more requirements documentation.
Financial institutions are now taking stock and recognising that, for years, they followed a waterfall approach and saw customer satisfaction plummet as a result. While they were spending a long time gathering requirements, markets, customers, technologies, even project sponsors, who requested the product, changed.
Undoubtedly, the growing interest in Agile is a sound effect of the intersection of many trends and necessities, and a possible answer to the need of doing things in more innovative, efficient, and productive ways.
The mistakes and the benefits
There are some key challenges in adopting Agile that every organisation, and not just financial institutions, has to deal with. Some of them are quite common mistakes that could lead to a resounding failure:
- Skepticism towards Agile at the executive level can profoundly undermine the cultural shift to Agile practices.
- Underestimating the importance of proper skill-up and training could instil the false feeling that Agile can be implemented by only introducing a few Agile tools and adopting some of its high-level practices.
- Failing to give development teams the autonomy to manage the process collaboratively will lead to micromanagement and defeat the very purpose of the Agile Manifesto.
- Limiting the adoption of Agile to the delivery process disregarding technical practices can jeopardise the success of the delivery itself: it is not only about Sprints and ceremonies, but also about test automation and a continuous improvement.
- Setting unrealistic expectations can alone determine the failure of the transition to Agile. Agile is no magic wand; planning in Agile is rigorous but also dynamic and cannot be any more precise than a Waterfall planning on large periods; Agile frameworks are not problem-solving but rather problem-finding methodologies.
Once they have managed challenges and overcome mistakes, organisations will be able to collect the benefits of working with an Agile setup:
- The lengthy requirements gathering process will no longer paralyse the projects
- Automated tests and builds will mitigate part of the technical risks
- The same Agile discipline will address change-related risks on a daily basis
- Senior stakeholders will have more visibility of the real progress through demos and frequent releases
How to make it work
The road to the “get-it-done paradise” begins, as every journey, with small steps, that must be prudent and appropriately planned otherwise the whole process is bound to fail.
Bottom-up drive, top-down support
Since in Agile the team is the building block of the underlying philosophy, organisations that succeed implementing Agile adopted a bottom-up approach, enabling decision making within the project team. However, they could also count on acknowledgement and support from “above”, with an executive team enabling teams to manage the process and defining the expected results and benefits from switching to Agile.
Divide and conquer
Choosing a large project to begin the transition to Agile is probably not the best decision for any organisation. Starting from a small initiative will give the opportunity for the team to familiarise with the new workflow, the ceremonies and build confidence in each other. Agile ensures the best performance when applied to small scale projects, therefore organisations should not aim at applying the Agile mentality to big projects or large teams anyway.
Training and Education
Turning a company into an Agile organisation implies that all areas involved in the delivery of the programmes of work are “Agile ready”. Everyone needs to take the training that is appropriate to their role and quite likely also receive further coaching to put into practice the Agile principles. The excess of information (and opinions) on Agile on the internet should not be a surrogate of proper training. One of the main pain points of any organisation moving to Agile is the procurement office. If the company is not able to engage Agile vendors and keeps enforcing fixed-price agreements, your projects will be “handcuffed” since the get-go.
Invest in Agile technical practices
Agile’s ultimate goal is to have a production-ready product and to achieve that environments require build and test automation. One of the main steps in embracing Agile consists in adopting a Continuous Integration model, from both a delivery and a technical standpoint. The cost of setting up this CI chain is utterly puny compared to the cost of delivering poor quality – and recovering from it.
Set up an “Agile” work environment
Agile begins with an open communication, and thus everybody working on a project should be in the same space. Working in silos, adding layers of management or approval, keeping business and technology separated, will just hinder the information flow.
Adopt Lean Requirements
Working with Lean Requirements means abandoning the idea of linearly and minutely writing requirements with all the needed details. It rather involves brainstorming ideas in workshops, focussing on user personas, performing a story-mapping exercise, drawing user flow diagrams and creating a backlog for the Minimum Viable Product. All these practices are part of a natural Agile training and should not scare anybody that is not familiar with them.
As in all changes, especially the ones that virtually involve the whole organisation, the switch to Agile is a non-starter without somebody championing the change. A champion will likely take care of most of the heavy-lifting in educating the company. Having a champion, as high as possible, and preferably one from business, another one from technology, could be a real game changer.
An agile transformation for heavily regulated institutions with an established enterprise delivery framework will take time to complete. While consumers are demanding a change from financial institutions, many of them are trying to understand the degree of culture change required. The ability to adapt to external forces and defeat the resistance opposed at many levels will be crucial to the success of the leap to Agile. After that, all the benefits of Agile will be at reach.