Agile Transformation in Financial Services – 7 things we have learned

Thought Leadership

Daniel Fiedler

Most of the financial industry is starting up or maturing in their Agile way of working which is part of a digital strategy or an eagerness to change and innovate rapidly. We support clients across Europe and have observed certain recurring topics. Certain areas currently do not get the needed attention, such as getting the basics right, Leadership & Culture, Technology stack, as well as the flow of funding and information. More focus can improve the chance of experiencing the full potential of Agility.

Facing fast-changing customer needs, more complex IT systems and new arising competitors like Amazon, Alibaba, Chime or N26, most financial service companies started out their Agile Transformation journey to deliver faster, cutting costs, getting closer to customers, enabling the broader digital transformation and most importantly, becoming more innovative. With all the pressure of day-to-day work, it is worthwhile to do a retrospective of recurring challenges faced by our clients. Given our experience across multiple transformation change projects in the financial industry, we find it beneficial to share the common challenges and recurring topics with you.


The organisation decided to go forward with the transformation, developed a roll-out plan and started executing. Especially in the beginning, it is crucial to transfer the whys and whats of the transformation to the floor. But it is also important to enable the teams to work in agile. Teams lacking the basics in agile practices should be avoided at all cost, else this can lead to agile ceremonies which are just placeholders in the calenders and not more.

The result will be a misalignment or unbalanced workload within the teams because they don’t do stand-ups properly. Insufficient refinement and planning lead to a delay in the implementation or increase of re-work.

But what is even worse for the success of agile is that this behaviour leads to the impression that agile ceremonies are considered overhead and don’t deliver the necessary value because people don’t know yet how to apply them properly.


By transforming the operating model from waterfall to agile, big financial service companies are facing the challenge of fitting the high numbers of middle management into the agile framework. The question is what roles are the most suitable fit?

We observe that former middle-managers are pushed into roles like Scrum Master or Product Owner with limited skill check on how they could fit into the new role.

Product Owners are responsible for shaping the product, creating a product roadmap and vision.

They are in charge of prioritising the product backlog as well. Former project managers, especially within the IT department with a strong technical background, tend to interfere during implementation by falling back into the old mindset. This could interrupt the team during their sprint and creates friction with the Scrum Master. Most importantly it reduces the capacity for the main responsibility of a Product Owner, which is to develop the product and a stable prioritisation.


Legacy systems are complicated (sometimes even complex).

Microservices allow decoupled releases and a proper CI/CD-pipeline. Most companies started their DevOps journey by focusing on automated testing and a CI/CD-pipeline. This is already a major challenge requiring huge investment in technology and tools. To truly embrace the full potential of DevOps, a broader use of DevOps methods and principles need to be taken into account, including further organisational changes. This is to enable the teams to truly live the slogan “you build it, you maintain it”.

It is key to set the right priorities at the beginning so as to not lose the momentum halfway in the transformation


Leadership & Culture is probably one of the most discussed topics in the agile space. However, these topics are the least tangible for leaders and people who grew up in a command-and-control environment.

The leaders give orders, and the subordinates follow and execute – end of story. The traditional leadership behaviour model might have helped to stabilise the organisation while operating in well-known market conditions. However, this behaviour model no longer empowers the self-organised teams nor serves the organisation in an uncertain environment like today. This is the reason why leaders are crucial to the success of the organisation and the ability to change the culture. Leaders must allow their teams to self-organise and support them through both success and failure, ensuring they do not fall back to their old command-and-control behavioural patterns.

Out of our experience, leaders need to think ahead about how to lead during a crisis in order to minimize the likelihood of falling back. They need to use the available tools and the information at hand to create the transparency to be able to lead – no additional excel-action plans, no additional status reports next to meetings like reviews, stand-ups or scrum of scrums. Transparency and trust are crucial.


Since McKinsey first introduced annual budgeting in the 1920s as a major management tool to steer companies, a lot has changed but not the annual budget process. Starting already in September of the previous year budgets will be forecasted and locked. Making changes, when required during the year, difficult and messy. The forecast mutates to the main goal of the company, a self-fulfilling prophecy.

This rigid process does not go well with the “embracing change” of agile principles. We saw in the most transformations that changing the budgeting process was postponed due to huge impact on the entire organisation. What makes sense, in the beginning, becomes a major obstacle at some point. Agile teams can become demoralised coping with bureaucracy.

Additionally, we saw companies losing complete visibility on their projects because agile teams could not enter the information needed with no other opportunity to gather alternative data which were used in an agile environment the company were left in the dark for months about the spending and progress of projects.

It is essential to think ahead on how the budgeting can work in the specific set-up. How and which detail is going to be tracked and planned? Finally, thinking about how to move from a project-based-funding to a value-stream or product-based funding to achieve greater agility and flow.


One of the foundations of agility is fact-based decision-making grounded on empiricism. The key to success is measuring what matters, meaning focusing on outcomes rather than outputs. Measuring the outcome of a delivered solution to validate the initial hypothesis to be able to learn for the future by having the right mix of leading and lagging metrics. We experienced that people new to the concept struggle to set the right metrics which can lead to suboptimal outcome or gaming behaviour at worst which makes the metrics unusable.


Agility can’t be copy-and-paste from another company. If you do it, you are doomed to fail and end up in chaos. You can look out to other companies for methods, practices or frameworks to gather ideas and to have a starting point. But it is crucial for the success of your organisation to experiment and learn what works well and what doesn’t in your individual context. In the end, there are no shortcuts to achieve greater agility.