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!