The Three Factors that Thwart Agile Banking, and How to Overcome Them

By Frank Trainer, Vice President of Process and Delivery at Apexon via The Financial Brand

Many banks and credit unions that have started down the road to becoming agile organizations aren’t seeing the results they’ve expected. This is often because the order to shift to agile was a top-down directive. Titles might have changed when the decree came down from the C-suite, but lower-level managers, teams, and employees haven’t altered the way they operate.

That misalignment becomes strikingly clear as organizations adjust to the COVID-19 world. Truly agile banks can excel in this uncertain environment by quickly responding to shifts in priorities caused by the pandemic. Banks with rigid, top-down management structures on the other hand have been struggling to react effectively.

Here we’ll examine three common barriers to an agile banking culture and highlight what financial institutions can do to break them down.

Barrier 1: Rewarding the Wrong Behavior

As part of their shift to agile, banks and credit unions might implement newly organized teams with scrum masters and product owners. But this change in structure alone won’t help the institution realize the benefits of agile organizations if the underlying culture remains.

Even after implementing a new organizational structure, financial institutions perpetuate an outdated culture by rewarding non-agile behavior by individuals. This can happen in the form of “Most Valuable Team Member” or “Contributor of the Month” awards. These rewards highlight individual performances but discourage teamwork.

Consider these examples: A bank or credit union might offer a Visa gift card to the software tester who identifies the most bugs or to the marketing team member who creates an email campaign with the highest click rate. This sounds great on the surface — they’re measuring productivity with a quantifiable goal.

But what happens when the “most productive” tester simply logs the same bug (under different operating systems and languages) multiple times? Or the “most successful” marketing campaign relies on a sensational subject line to boost its click rate, but generates no substantial leads?

Non-agile groups tend to be evaluated like bowling teams: The team score is the simple summation of separate individual performances. In other words, say I bowl a perfect game, but my teammate doesn’t break 100. I’ll still feel good about my score, even though our team score isn’t that great.

It’s natural for employees to resist an entirely team-focused agile approach. For their entire careers, they’ve been rewarded for their successes as individuals. Now, they’re asked to let personal triumphs be absorbed by the group.

In agile organizations, however, team performances and individual performances are one and the same — and need to be treated as such.

How to fix it: Financial institutions need to show every level of their organization that team performances are as important as individual performances. The team’s success or failure in achieving its goal matters more than the individual efforts it takes to get there.

To do this, individual rewards need to be replaced with team awards. Say a cross-functional team was tasked with building, implementing and promoting an online-only, high-interest savings account for college students and turning it into a $1 million business line for a bank or credit union. Once that goal is reached, the entire team should be rewarded: developers, operations staff, and project managers, as well as the marketing team that helped promote it.

Cross-training is another way to highlight the importance of teamwork within an agile culture. It helps break down silos and build more interconnected teams. A side benefit of this has become evident during the COVID-19 pandemic: cross-training keeps teams functional throughout unexpected absences and events.

The proper way to evaluate truly agile teams is like a football team, not like the bowling analogy mentioned earlier. Here’s the difference: With football, the score on the board represents the efforts of the entire team. A touchdown isn’t the sole responsibility of the player who scored it — it’s what happens when every player on the field understands their responsibilities and works together.

Barrier 2: Conflicting Goals

Working toward clear, high value (high-ROI) goals is critical for any agile organization. But if these goals are created in silos (or if they come from the top down with no input from lower-level employees), they can clash and restrict teams from reaching the objective they were meant to achieve.

Take this example from a bank’s technology unit. An infrastructure team is tasked with keeping uptime above 99.9%. On its own, this is a commendable goal. Customers need constant access to their financial information.

Meanwhile, the bank’s development team is tasked to shorten development cycles by 33% and issue more frequent deployments. Another commendable goal on its own — but it clashes with that of the infrastructure team. Frequent deployments impact uptime, which will keep the infrastructure team from reaching its 99.9% goal.

Conflicting goals create a lose-lose scenario for the business side of the bank. If the development team achieves its goal, customers are unhappy they can’t access their online banking. If the infrastructure team achieves its goal, customers are frustrated with bugs or a lack of functionality in their mobile apps.

How to fix it: In a technology scenario such as this example, financial institutions can implement a DevOps philosophy. DevOps is a way to realign technology teams, so development teams can put new code into production with minimal interference from infrastructure teams.

The best way to implement a DevOps approach is to start on a small-scale project, share the results with the entire organization, and then gradually apply the new philosophy on a greater scale. It won’t happen overnight, but buy-in will accelerate as teams see a genuine process improvement.

Let’s revisit our example from above. Under a DevOps approach, the infrastructure and development teams won’t operate under two different goals. The entire IT team might be tasked with a goal, like decreasing time to market for a new software product by 20%.

From there, integrated teams will work together to decrease time to market — throughout the entire process, from design and planning, to build, to deployment, and back to design. The objective of DevOps, at its most simple, is getting software in front of users as fast as possible, then improving it based on their feedback. That can only happen when the entire technology team is in sync throughout the process.

As technology teams align under a DevOps philosophy, business and IT stakeholders should align on common goals of their own. To do this, business and IT leaders can participate in weekly planning meetings to gauge the needs of the business against IT’s development and deployment cycle.

This helps solidify IT’s important role within a business context: high-level, agile organizations are four times more likely to have business stakeholders who perceive IT as a valuable partner. It’s a self-affirming cycle. Empowered by the business side, IT can shorten development cycles and deliver applications designed to meet business needs.

Barrier 3: Being ‘Uncertainty Averse’

Traditionally, banks and credit unions have moved slowly when it comes to technology, and for good reason: A cautious approach helps protect them from risk. But the opportunity cost that comes with moving slowly has become too great. Though it sounds counterintuitive, traditional financial institutions need to become more comfortable with the unknown. Or, put a little differently: Become more comfortable being decisive with limited information.

Even making the “wrong” decision is better than making no decision. The traditional need for certainty clashes with the fluidity of an agile culture because it assumes the possibility of perfect knowledge — a possibility that simply doesn’t exist.

Let’s take this example: a CEO wants to diversify his institution’s product offering by introducing a new, low-interest home improvement loan to high earners. The product development teams prioritize the project and streamline it toward completion.

Fast forward six months, and the institution rolls out its flashy new home improvement loan product — but it fails miserably. Competitors have introduced similar products, the economy has tanked, and, despite the best projections, customers aren’t responding.

The real failure here isn’t the lack of consumer adoption of the new product, however. It’s the wasted time and resources it took to get there.

How to fix it: Agile teams should work together toward clear, high-value (high-ROI) goals. When circumstances change and the goal is no longer feasible, agile teams need to be able to walk away — abandoning a low-value project for a high-value opportunity.

Let’s revisit the example above in an agile context. Rather than pigeonholing themselves into developing a home improvement loan, the CEO might revise the goal to be: Introduce a new loan product for high earners that can generate $1 million in annual revenue and has a 15% ROI.

During development, when the economy swings downward and unforeseen competition enters the market, the team walks away from the project. It’s clear they’re not going to generate the target revenue or ROI, so they elect to focus on maintaining regular business operations.

Both scenarios end in “failure,” but in the agile scenario the institution failed faster than the other — and cut the wasted resources in half.

By breaking down barriers to agile one by one, banks and credit unions can build more efficient teams across the entire organization and implement an effective culture that inspires action, creation, and innovation.