In Banking, Agile Isn’t Just For Software Development

“You keep using that word, I do not think it means what you think it means.” – Inigo Montoya, The Princess Bride

Banking is the latest in a long line of industries to fall in love with Agile. I hear bankers use the term in almost every discussion about software implementation. We talk about timelines and give our usual pitch that the speed of implementation is up to the bank, and that we will move as fast as they want to move. Some act as if we have offended them.

“The bank uses Agile for all our projects. You won’t have to wait on us.”

That’s a short statement, but there is a LOT to unpack there.

In some of the banks this is patently false. We will definitely be waiting on them.

They call their method Agile, but what they mean is that they try to do a waterfall approach really fast. They still have a long, sequenced plan made on day one, and there are “phase gate reviews” with management after months or sometimes years of work. At no point is customer or end user feedback involved, and there is no attempt at shipping smaller, finished products for testing and feedback. That ain’t Agile, and I although they keep saying the word, I’m not sure they know what it means. While this group is worthy of discussion, they are not the topic of this post.

Instead, I want to focus on the banks that really do use Agile.

In these banks, Agile has been sold as the cure for all project ills, and now they have a few teams that follow the methodology with a frightening dogmatic devotion. They spend a lot of time planning sprints and choosing scrum masters. While their heart is in the right place, I fear that they generally miss the point of Agile.

The point of agile is not the terminology or even speed, but flexibility. To meet the needs and expectations of a fast-moving market, it is essential to be flexible and adjust on the fly to meet those needs. This is true of building and implementing software, but for banks, it must also be true of their day-to-day work of servicing customers. For lessons on how to do this, we can turn to, of all places, the auto industry.

The MIT Sloan Management Review had an article in their Winter 2018 Issue called A New Approach to Designing Work that discusses the topic. In the article, they describe the traditional design of work. If the work consists of well-defined and repeatable tasks, then it should be organized serially, as in a factory (so they call this fittingly, “factory mode”). If the work is more ambiguous and requires interaction, then it should be organized collaboratively (which they call “studio mode”).

Most companies have both kinds of work and divide them in this manner. But, that division comes with meaningful trade-offs. The work done in factory mode is not flexible, and the work done in studio mode is not scalable or efficient. For banks, factory mode would be things like processing transactions in a checking account or originating a loan. Studio mode would be things like designing a new kind of account, implementing a new technology platform, or negotiating a decidedly non-standard loan transaction. The Sloan article asks an important question about this design of the work. What happens when you need to switch between the two modes?

Consider a Toyota manufacturing plant, which is the epitome of factory mode. They have assembly lines where every small motion of the workers is planned and practiced. However, there are occasional problems, and the workers need to adjust. If the parts coming down the line start to have small defects, they might slow down a later step, and the line starts to bottleneck. In many factories, the workers would be expected to keep the lines running, so they would find shortcuts or workarounds. As a result, faulty products are shipped that damage both the brand and the bottom line.

At Toyota, the workers are empowered with a version of an Andon cord. By “pulling the cord,” any worker can stop the line. A supervisor then immediately arrives on the scene, and the team switches from factory mode to studio mode to collaboratively solve the problem. They will either find a solution or call in additional experts who can help. Either way, they quickly fix the problem, and the line can resume. The work switches back from studio to factory mode.

Banks are generally unable to do this switching. They are using Agile methodology for their studio work, but the factory work has no such mechanism. Instead, any flaw or deviation from normal standards causes bottlenecks, mistakes, and inconsistent decisions. If you don’t believe, try submitting a request for a non-conforming loan that is “outside of policy” and see how quickly it gets handled. In short, banks need a mechanism by which they can better switch between studio and factory mode.

How do banks solve this? There is no silver bullet, but the banks that do this best have a few common traits.

The entire process is transparent

Many of the struggles in switching modes come from the fact that each process happens in its own silo. An RM has no idea what is happening to a loan once it lands in credit. There might be questions that credit struggles with for hours, and the RM had a clear answer all along. And, worst of all, if the bank can’t clearly see the progress, how on Earth is the customer supposed to stay informed? Commercial lending doesn’t need to be such a black box, and transparency lowers error rates and speeds up the work.

Work is broken into smaller pieces

This is one of the core tenets of Agile and the one that banks violate most often. A giant batch of work is handed off to a specialist or to a committee, and they go away to their cave to work on it. Many weeks later they emerge with a deliverable that may or may not resemble what was expected. The best banks have well defined processes that happen in small, bite sized pieces. This allows for quick feedback from everyone else involved and ensures that work stays on the intended trajectory.

There is a clearly defined “Andon cord”

As any commercial banker knows, there is no such thing as a “smooth’ process for a complex commercial transaction. There are millions of dollars at stake, lots of people involved, and multiple teams of attorneys. Things get messy. Everyone involved, from the Relationship Manager to the Credit Analyst to the operations staff must have the ability to halt the process to correct problems.

Too often it is unclear how to solve an issue or who should be involved. Errors, risk, and delays creep into the transaction. The best banks have established procedures for these situations including resident “fixers” that specialize in solving complex problems. They can negotiate disputes, navigate internal exception and approval processes, and find expert resources as needed. If you don’t have a clearly stated process for problem solving, you’re leaving your staff to decide between letting problems slide or winging it on solutions. There is too much at stake to allow this to happen.

I’ll wrap it up with a great quote from the Sloan article:

If you strip away all the hype, the agility of any work process — meaning its ability to both adjust the work due to changing external conditions and resolve defects — boils down to the frequency and effectiveness with which the output is assessed.

Banking is all about checks and balances. This isn’t a giant leap for the industry. We just need to make sure that the most important Agile principles spread throughout the bank, and that the right kind of frequent feedback is built into the workflow. Assessment doesn’t just mean that a boss checks their employees’ work. It means that end users and customers get to see the progress and steer the work in the right direction as it’s done.

In short, for your bank to really be Agile, use the principles where they matter most: with your customers.

If you're interested in more banking content like this, please check out the Resource Center at PrecisionLender.com