The financial sector faces increasing competition as tech-enabled digital entrants threaten to disrupt the industry with innovative products and services tailored to increasingly heightened customer expectations. Financial industry players who leverage the opportunities of agile will be appropriately equipped to meet such threats head on and launch digital projects themselves.

In a previously published article, I championed the agile approach as imperative for implementing digital projects. In this article, I’ll walk you through what agile is, how it can and has been used to digitalise customer journeys in banking and how to avoid its pitfalls.

AGILE: A BRIEF INTRODUCTION

To give a proper definition of agile, it might be useful to contextualise it into the broader project methodologies toolbox:

• Waterfall: The waterfall methods or model is a linear approach to software development. It’s commonly known as the traditional model for software development and ranks among the less iterative and flexible methods. It progresses in one direction, from conception to the end product, and wraps up each stage before the next one begins. A critical disadvantage with the waterfall method in digitalisation projects is you might end up with something that is outdated when it’s finally launched.

• Agile waterfall: The agile waterfall method unlocks more agility than the traditional waterfall method, but less flexibility than unmitigated agile methods. As agile waterfall involves working within a given framework, it is well-suitable when changing existing products and services or adding new features to an existing product or service.

• Agile: The agile approach is iterative, flexible and team-based. It focuses on the rapid delivery of applications in complete functional components in what is called “sprints”. Sprints are phases where agreed-upon deliverables, prioritised by business value, are developed within a defined duration. As the project progresses and work is completed, stakeholders can review and evaluate the deliverables and adjust the plan if needed.

According to consultancy BCG, agile practices promises to improve digital delivery through an iterative, empirical and cross-functional approach when building customer-centred products. The brilliance of agile is that you split up the implementation phase in several smaller parts. Your work bit by bit and develop something that makes sense about process flow, risk management and technical limitations.

AGILITY AT WORK IN BANKING

One of the largest Norwegian banks embarked on an agile project to improve their existing credit processes. Their current process took each single credit case – 2000 customers and 3600 cases – and manually developed risk assessments for everyone – a tedious and time-consuming process. After rigorously researching and analysing their customers, they found that close to 50 percent of the cases were low-risk, requiring little to no manual handling. Half of their customers had a good economy, the right competence, no prior board member bankruptcies, good management capabilities and a long track record.

Coupling existing internal data with external data, the bank developed a decision-making model aiming to automate low-risk credit cases. Instead of manually handling every single case, the decision-making model assessed whether or not customers applying for credit displayed any signs of potential bankruptcy over the next two years, based on specific indicators or certain risk criteria.

With this digitalisation project, the bank was able to automate half of their credit processes, drastically reducing resource use, internal time use and most importantly of easing the customer journey. To get there, the bank relied on agile manifested in the following steps:

• Architecture control: The bank relied on an incredibly complex IT architecture, with thousands of disparate systems communicating with each other. In effect, the bank had to develop something within an IT ecosystem that had no overarching architecture, insufficient data management, complex data flows and silo-based systems. To tackle this, they took a bird’s eye view and developed Epics, big pieces of work that has one common objective, functioning as a placeholder for a required feature consisting of a few lines of description. Simultaneously, they searched for information to solve the various tasks, mapping out the data and functionality needed to be built into the system. This provided them with an architecture that covered the entire solution.

• Estimation techniques: After mapping out the overarching architecture, the project team assessed its complexity. They included business analysts, architects and specialists under the guidance of a lead architect who oversaw the entire concept to estimate each features’ complexity roughly. Each feature was given a number signifying complexity and time requirements. Then, they added all estimates together to gain an overview of overall implementation costs. To estimate as precise as possible, they narrowed it down to development only and drew on extensive project management experience among team members.

• Define main deliverables and develop business cases: Through the proper use of estimation techniques, the project team were able to provide stakeholders with a total cost overview. The entire project was split into several sub-projects into four independent deliveries with business cases for each of them. This allowed the bank to launch the deliveries to the market independently and stop any project if necessary.

• Active utilisation of project experience: As the project progressed, the project team continually harvested experience to report on the overall project portfolio and further develop the concept. During this particular project, it gradually became evident that implementation could be performed well within the original budget, but the bank decided to keep the original budget for potential future product add-ons.

AGILE PITFALLS, AND HOW TO AVOID THEM

Although agile is well-suited when developing entirely new products or services, it has its pitfalls; agile involves higher risks. Traditional waterfall methods specs out every detail to deliver the right software, while agile depends on a shared understanding of customer needs between the project team members. However, even though you may know the number of team members at your disposal and the timeline of your project, it is hard to determine how much you can deliver throughout each sprint.

• Assemble the right team: Map out key roles necessary for a successful delivery model. This includes practically-minded project managers, test managers, IT architects and business analysts. Implementation requires skill sets that go beyond theoretical and strategic thinking and practical implementation skills. “Street smarts” should be higher valued than education and resumes. This is particularly important for project managers.

• Daily follow-ups: Implement daily status meetings with everyone involved to ensure close dialogue and optimal communications. During these meetings, each member should summarise what they did yesterday, what they plan to do today and if there are any obstacles in their way.

• Milestone planning and responsibility delegation: Many refuse it, but agile requires milestone planning. This is not a milestone plan in the traditional waterfall sense, but a dependency line that enables creative freedom and creates boundaries to contain risks where they are supposed to be. In this milestone plan, you need to delegate clear responsibilities. If you are running a three-week project delivery, someone needs to be held responsible for its success; one designated team member must own the micro-delivery.

• Ensure team member proactivity: Encourage team members to notify and help other team members if they come across obstacles, challenges or opportunities that lie outside their area of expertise or responsibility.