What A Retail Bank Learned About The Value Of Persistent Teams In Digital Transformation

What A Retail Bank Learned About The Value Of Persistent Teams In Digital Transformation by Peter Bendor-Samuel In digital transformation, it’s an undeniable fact that many companies end up getting nowhere close to hitting their goal. But a major US retail bank undertook a highly strategic project to build the back-end support system for a […]

January 31, 2018

What A Retail Bank Learned About The Value Of Persistent Teams In Digital Transformationby Peter Bendor-Samuel

In digital transformation, it’s an undeniable fact that many companies end up getting nowhere close to hitting their goal. But a major US retail bank undertook a highly strategic project to build the back-end support system for a digital payments transaction platform, and it achieved outstanding results. A compelling high level of productivity. A superb product that delivers competitive differentiation. Plus, the system was delivered in agile, fast way, and the overall total cost outcome was very low. How did the bank achieve this outcome when many companies fail to get traction in digital transformation? I want to share with you how the project played out because I believe the bank’s experience illustrates the future of IT services.

Typically, companies hire a third-party service provider or system integrator (SI) to build a new system and then hire that provider to take over the running of the system. Historically, companies repeat this pattern over and over again. But the business world is changing as far as how organizations achieve value and competitive differentiation, and embracing a new talent model is critical to success.

As I previously blogged, a large retail bank wanted to implement a digital payments platform. After several attempts internally and with SIs to build the back-end system to support a digital wallet, the bank shifted its strategy to use Quisitive, a small, boutique service provider to build the system. Quisitive built and delivered a superb product after just nine months and then transitioned ownership of the overall architecture to the bank. But the success didn’t stop there.

Quisitive’s team and the bank’s team work together today in a very tight agile/DevOps model. As Quisitive’s chief customer officer Paul Bresnahan explains, “We run very tight sprint structures. The bank decides the function that the business wants to add from a security or compliance capability. We design the sprint, and then we run that sprint very effectively in two to three weeks and release that new functionality into production. That’s the model we’ve established, and it’s super-effective for the bank.”

How Does The Model Work?

Quisitive’s core team is based in proximity with the bank’s team, comprised of business leaders, people from the bank’s core technology group and security group. All are located together in a “pod” at the bank.

If you’ve ever been involved in building a major strategic system, you understand these projects often turn into what I refer to as M2M projects – meaning they require many millions of dollars and many months. And hundreds of development people. But not so with Quisitive. Nine months and a team that was never larger than 35 people at its peak.

“With deep knowledge of the platform, deep knowledge of the tools, strong methods, agile development, and a persistent team, small companies like Quisitive can achieve a lot with a 25-30-person pod compared to more traditional development methods,” says Bresnahan.

The persistent team is a key component of the model. Unlike the traditional practice of using leveraged, disbursed teams of service providers or SIs to build a system and then turning the system over to the provider to run, a persistent team in close proximity with each other “is much more effective,” says Bresnahan. “The process just wouldn’t work effectively if the teams were disbursed.”

“The environment of the pod at the bank’s facility is so dynamic,” he continues. “Each person in the pod has a role within a sprint cycle, but there are multiple things going on in parallel. Somebody might be getting to a point of pushing something into a QA role, and then they discover something that has an implication for another piece of componentry being built in parallel within the team. They can quickly get together, troubleshoot it, fix it and move on. If you were to visit the pod, you’d see them getting up and shifting across desks and pulling together and dealing with issues. They work in this dynamic flow because of their proximity.”

The team methodology provided another benefit: Quisitive didn’t need deep expertise in payment systems. Through the model they developed, the bank’s experts in payment systems – who were experts that could talk to retail customers and draw out their requirements – were part of the team and fed the information straight into the development cycle. No need to hire a fintech service provider. The team was able to capture retail customers’ user stories and turn that information into a product quickly and then quickly adjust the product as the users experimented with it and provided feedback. So, the bank’s use of the pod team produced a better outcome, better product, and achieved it much faster and at a fraction of the cost. It’s the death of M2M projects.

The small, boutique service provider got the bank where it needed to go for future competitiveness. It developed a superior architecture, and the pod team structure yielded high productivity.

Another benefit of the persistent team structure is avoiding the time delays and costs of a disbursed team having to deal with a deep learning curve. Typically, Transformation is a journey, not a destination; and a journey approach needs to take a broader, longer view. Yes, there are new releases to the bank’s digital wallet system, as the bank continually evolves and improves it. But the persistent team doesn’t disband; it keeps working together, and it leverages its deep learning curve knowledge to continue the journey effectively.

Contrast the benefit of a persistent team’s deep and evolving learning curve knowledge with what typically happens with SI resources. They typically spend one-third to one-half of their time building requirements and learning the environment. Then the team leaves once the system is deployed because they’re too expensive and no longer needed. Thus, the company loses the learnings of the team.

Leveraging a collocated persistent team using agile methodology and design thinking is the latest thinking in talent models. Combine this structure with an integrated, automated flexible architecture and digital tools to change the business model, and you have the ingredients for what the bank and Quisitive achieved: a transcendent result.

I believe we’ll see more and more powerful examples of this dynamic new talent model in 2018.