What does it take to enable a successful agile setup in a bank?

What does it take to enable a successful agile setup in a bank?

I don’t mean to initiate a culture change and establish an entirely new mindset. My objective is to set up an agile environment as soon as possible ready, to implement a product in a bank. You can put together a team of business representatives, developers and possibly other people like marketing agents and so on. Everybody is super agile with the right mindset and not only preaching this, especially living this (there are still few in banking). Then it starts!

However, very soon it is “on hold”! The developer cannot install the desired open source solutions (forbidden), specifications on the UI / UX are to be allowed by the business management and the marketing projects (e.g., Grow hacking) are to be accepted in an STC, (once a month) then rolling out of a beta version can only take place, when all obligatory documentation has been approved and accepted (to be approved through more than 5 different people). However, even the finished and ready product can’t be rolled out because the management would like to present it to the board of directors (which happens once every five weeks) for the time being. A lot of time, energy and cash is lost!

How can these hurdles, disabilities, and tempo brakes be eliminated/reduced? Or even better, the pace and the drive also optimized? I identified 5 points for that. All five must be tackled. Only then, the fragile structure of an optimal agile configuration in a bank is considered a possible hierarchy.


Maximized (Workstation/place)

I do not mean to have a nice office with a punching bag, a ping-pong table, and a coffee bar. I mean a workplace that allows developers to try install/license anything immediately and independently at any time. It is a tool that needs to be installed, a firewall rule that can be bypassed or even a cloud service that wants to be used. These must be made available as quickly as possible. There is nothing more cumbersome for a developer, that to stumble in the middle of developing a supposedly optimal approach to permissions/firewall-rules or other prohibitions which can only be applied by a lengthy authorization process. Not infrequently, the work of 5 minutes, suddenly takes several days and various meetings in place.


All competencies belong to the team

All competencies have to be in the team. All of them! Architectural decisions, road map, releases, marketing, even which fruits belong in the shell. The team should/must decide what is best for them and the product. The team knows when the maturity of a product is given, how and when should a beta version go out. Not the manager or the head of corporate marketing.

The team defines, the team builds, the team takes responsibility, which means that the team decides! This promotes cohesion, performance and commitment to the product/team in multiple factors.


Courage let it go and just do it!

Last but not least, the management should be part of it. Which means, they should not be part of it! That means the management has to learn to play its part in this agile setup and hand over into the skills and the trust of their team. There is no guarantee that it will work without error, but the certainty of making mistakes as soon as possible and adapt them as quickly as possible. The team needs the support of the management in the form of trust and room for maneuver: no micromanagement, no overhead controls, no weekly budget controls. The management can always get an idea in review meetings (passive participation). The administration has to let the team do it.


Guidelines should help, not prevent

Needless to say, the team needs to create a framework. The most important rule “The guidelines should help the team to focus on the solution!” Leaving all freedom to the team can be counterproductive. The team can lose themselves and possibly even have opposite views of the product. The assignment to the group must be clear but not limiting. It is a tightrope walk, not to restrict the team too much but still give certain strokes to its creativity and their power. For example, the team must be aware of the regulatory limitations. Also, the requirements of the security must be made clear to the team. However, what does not work are already existing technologies and platforms of the bank as guidelines. There must be the idea to make recommendations or references to existing environments/products/platforms/software. Mostly, the instructions should help the team to find each other and create a general understanding of what the goal is. As I said before, this is a very delicate topic that is a bit tricky in its formulation.


Management Expectation

Management must realize that an agile setup doesn’t necessarily have to be cheaper. This must not save cost in the short term. There is a tendency that the prices can even increase in the short term. However, it is crucial to the management to clearly show that the set-up allows, that the product is developed and adapted much faster (market influence, technological influence) in compliance with the rules (can be maintained in working agreements). Thus, the product is also faster on the market (time to market). Considering these factors in terms of costs, it quickly becomes clear that the bottom line is that they are usually even lower than before. It must be clearly stated what management can expect based on its setup, plans, and rules.


In that sense… Don’t wait! Do it!

Hey Banks! It’s time to access the Future!

Hey Banks! It’s time to access the Future!

What does a bank do if it does not longer moving forward? What when the time comes and there is no internal solution as prospect? It summons one of the Big Four. PWC, Deloitte, KPMG, EY maybe also Mc-Kinsey. Without doubt, these firms truly stand for competence, with their wealth of experience and a wide network. They are often perceived as THE experts and also quite frequently as the saviors. This might be absolutely correct, considering the challenges in the traditional and “old” financial ecosystem.

When it comes to digitization, however, they present similar problems as the banks. Highly-qualified personnel, in the fields of Fintech, Regtec, Martech, x-tech, is difficult to recruit. The knowledge in these areas is temporally very limited, fast-paced and, not least, also exposed to other cultural environments. In certain situations, others rules than the ones known by you might apply.

Again, a situation has been made known to me, which has occurred several times in other constellations. A medium-sized financial institution has asked one of the Big Four about Blockchain. Of course, the Institute has recommended hisself for the blockchain topic, and assures to have appropriate expert knowledge. One would never admit being unable to provide adequate expertise.

Thus, the contract was granted, on the other hand accepted. After about 4 months with a lot of PowerPoint slides and high bills, they has realized that the know-how was not enough. That’s why they hired a blockchain fintech. Thus, the actual project could start 4 months and several CHF 10,000 later. The consulting institute earned the cash, but the services was provided by the fintech.

The financial institutes, for the most part, have not found any point of access to these “new” ecosystem. The big consulting firms have, in general, one-sided interests and therefore rarely partner with fintechs.

Do they not want them or do they not know how? From my own experience, I can confirm that digital projects in the “old”, cumbersome but long very successful ecosystem of the financial industry need many times more time and money. Moreover, from a qualitative point of view, the result rarely meets the requirements (internally as well as externally). With the exploitation of the new ecosystem, financial digital knowledge, the network, the diverse agile project setups as well as their culture and closeness to the digital generation become accessible.

It is time for the financial institutes to open up to this ecosystem. Fintech and startups receive the financial institutes with open arms. They rely on partnerships and collaborations. And the fear that certain services could be divested by the banks is less likely if the bank is part of that ecosystem than to continue to move outside.

Digital Change in the Bank: Easier Than Thought

Digital Change in the Bank: Easier Than Thought

How can digital transformation be effected in a bank as quickly and as painlessly as possible? This is a question that occupies the thoughts of some banks more than others.

Some take the view that this is all “overhyped” and favour a “drink tea and wait” strategy. Others try to deal with this topic by appointing a Chief Digital Officer (CDO) or Chief Innovation Officer (CIO) and believe that they have landed a big coup. Yet others try to implement the future by burying projects beneath external contractors and are amazed when their own staff struggle because they have no understanding of it. And then there are those that hope to bring digitization in-house via developing PoC (proof of concept) with fintech and/or start-ups.

These models result in expensive and, at best, minimal digitization success. However, it is more likely that this approach will lead to uncertainty and discontent within the organisation along with high costs. Employees refuse to deal with the issue, block it to protect their own position and barely cooperate. Urgently needed digitization of the enterprise grinds to a standstill.

With the help of 5 simple principles, it is possible to quickly and simply move digital change within banks forward:

  1. CEO’s don’t need to understand digitization

CEOs and Board Directors do not necessarily have to understand digitization. In any case, they usually don’t (https://www.der-bank-blog.de/bankvorstaenden-fehlt-digitales-know-how/studien/technologie-finance/20430/ ). The CEO or Board of Directors must give the mandate for digitization, but not necessarily take a hands-on role in its implementation or be able to participate in its ecosystem. They should trust the contractor.

  1. Digitization strategy is for freaks

The digitization strategy must be understood by those who have been directly entrusted with implementing projects within the framework of this strategy. The freaks, who are familiar with the subject, have been assigned to the project. These people who are established in this field, feel at home here or simply have a passion for it. Other keywords, such as Industrie 4.0, Fintech, E-Government, Multichannel, Cloud etc. are unclear, confusing and incomprehensible to everyone else. It is also not uncommon for them to feel insecure, which is undesirable.

  1. Influencing corporate culture

Corporate culture does not have to be digitally-oriented as a precondition for starting a digitization project. Apple never consulted us about their product evolution (iPhone, tablets). Also, the internet never asked mankind in advance whether we were ready for it. Corporate culture is automatically enhanced by the implementation of the digital projects, step by step.

  1. Implementing digital projects through “UFO” organization

Project managers should be accountable for the implementation of the digitization strategy and its corresponding projects. No-one should be able to oppose the plans. In so far as possible, such projects should not influence existing day-to-day operations of the business (no matrix organisations). This leads to a “UFO organization”. UFO organization? Maybe you have heard of digitization – some believe in it, others not. But once you have actually experienced the digitization process, you become a believer in both the project and its intended purpose. Just like a UFO. You only accept it if you believe in it. If not, hardly anyone cares.

Figure: Eco-System and UFO-Organisation


  • Project staff are engaged 100% to the project (minimizes conflicts of interest)
  • It is sanctioned directly from the “highest” authority (CEO or BoD issues the order to implement the digital strategy)
  • New opportunities open up for employees
  • Project team members become ambassadors of the digitalization process.
  • No initial troublesome and costly cultural change required
  • The business can continue to focus 100% on its work
  • Projects can be started and stopped easily (existing organization is not affected)
  • No escalation steps exist -> UFO-organizations are directly connected to the highest decision-making authority so projects are “politically” difficult to stop.


  • The reintegration of project employee can lead to unrest (employees do not want to return to their previous position; unrest due to newly created digitization know-how etc.)
  1. Good “little hand” in the selection of personnel

As is so often the case, a successful project stands and falls by the resources involved. Surely, the project staff must be 100% freed up from day-to-day duties. Above all, each project team member should be fully committed to the project.

In addition, the UFO organization needs to fill specific positions from outside the business. Such people should have appropriate networks, know-how and, last but not least, a feeling for tall this so that they can test and evaluate the various parts of the ecosystem on a regular basis or when a situation demands it. It is not easy to find/identify such people (https://dupress.deloitte.com/dup-us-en/focus/human-capital-trends/2017/developing-digital-leaders.html ). They are in demand and will become more and more so. So-called digital-leaders (for example in Blockchain as described here https://www.linkedin.com/pulse/blockchain-leadership-how-technology-calls-next-leaders-schoeni/).

Often several digital leaders are needed, as only rarely does one person cover all the bases. Digital leaders come with a deep network in their respective ecosystems and are familiar with the relevant technologies. They also have strong technical know-how of the relevant business sectors and well-developed project management skills. This new profile of specific requirements has so far been difficult to find in the digitization space. Several universities have addressed the issue and are attempting try shift resources to meet this need (e. g. HWZ https://fh-hwz.ch/produkt/cas-digital-leadership/)


There is no need to initiate cultural change or organizational adjustments to an institution and its processes to make the leap into the digital age. It needs a dedicated “UFO unit, equipped with the best possible skills and resources with freedom to operate. Digital leaders can then focus the concentrated power of digital know-how, in a situational and targeted way, to implement digitization in the company step by step.