A provocative question - I know. But it is worth asking.
Because my experience is that formal Scrum doesn't work well in a significant share of cases in large financial institutions. Not because agile principles are bad, but because the context is different - and that is rarely said out loud.
Why is the context different in financial services?
The Scrum framework was designed for a software development team: an autonomous team, direct access to the customer, fast decision-making and minimal bureaucracy.
At a large insurer or bank, these conditions are generally not met.
Decision-making isn't fast. Changing an insurance product requires a compliance review. Modifying a banking system requires architectural approval. Changing contract terms at a leasing company requires legal sign-off. These processes take weeks, not days, and can't simply be accelerated by introducing Scrum.
The "team" isn't autonomous. Developers, BAs, testers, business units and IT operations all belong to different organisational units. Everyone has a manager, and everyone has different priorities. Setting up a cross-functional team requires organisational change, not just a methodology decision.
The backlog doesn't belong to the business. In financial institutions, development requests often stem from regulatory requirements, audit findings or management decisions - not from a product owner's prioritisation. The "most valuable feature first" principle is hard to apply when the compliance team dictates the order.
What usually happens?
Scrum is introduced. There are daily stand-ups, sprint planning sessions and retrospectives. Everyone completes Scrum Master training. The team gets Jira access.
Six months later:
Daily stand-ups have turned into status reports - not identifying impediments but reporting "what I did yesterday". Sprint planning happens at the start of the sprint, but "urgent" tasks from the business arrive mid-sprint and override the planned work. The retrospective gets squeezed out of a packed calendar of back-to-back meetings. The Scrum Master's time is mostly spent on administration.
This isn't the Scrum Master's fault. It is organisational reality.
So what does work on financial services projects?
The agile mindset - not necessarily the Scrum ceremonies.
Three things I consider genuinely valuable on financial services IT projects:
Iterative delivery in smaller increments. There is no need to wait two years for the first live version. If the system can be delivered module by module, feedback arrives sooner and risk is lower. That isn't Scrum-specific - it is a general agile principle.
Continuous prioritisation. Maintaining the backlog and regularly agreeing priorities with the business is valuable, whether or not it is called "sprint planning".
Transparent communication about progress. A weekly status email that sets out exactly what has been completed, what is committed for next week and what hasn't been delivered adds more value than a formal Scrum ceremony in a dysfunctional organisational structure.
When does Scrum work well in financial services?
To be fair: there are situations where Scrum really does work well in a financial services context.
A dedicated, genuinely autonomous team. If the business and IT jointly allocate a dedicated team to a project - co-located, with a shared calendar and real decision-making authority - Scrum can work well. It is rare, but it happens.
Greenfield development. When something entirely new is being built - rather than an existing legacy system being developed - Scrum's flexibility adds real value. In developing the Mitigia carbon credit platform, for example, the iterative approach worked precisely because the business logic and the software were taking shape in parallel.
Fintech and insurtech start-ups. In financial services start-ups - where the organisation is flat, decision-making is fast and the team is truly autonomous - Scrum is perfectly applicable.
So do you need a Scrum Master?
Yes - but not necessarily in the form the textbooks describe.
What really needs to be covered on a financial services IT project: someone who protects the team's focus from organisational distractions, communicates across organisational units, transparently documents progress and impediments, and helps the team continuously improve how it works.
That role isn't necessarily filled by a "Scrum Master" - it can be an experienced business analyst, a strong project manager or an agile-minded tech lead. The title matters less than the competence and the organisational standing.
The most damaging thing an organisation can do is introduce Scrum terminology and ceremonies without changing the decision-making structure, organisational boundaries and prioritisation processes. The result: Scrum's administrative burden remains, while agile values never take hold - and the team unfairly loses faith in agile methodology.
What we do at FrontX
FrontX projects, including our custom application development projects, are not "Scrum projects" - they are structured, iterative projects that apply agile principles adapted to the financial services context.
Weekly status emails, continuous stakeholder communication, modular delivery and transparent impediment management. Not ceremonies, but real value.
The business analyst is involved throughout. Not instead of a Scrum Master, but because on a financial services project, owning the business requirement matters more than facilitating sprint ceremonies.
If you have an IT project where introducing agile methodology hasn't delivered the expected results, we are happy to look at why: frontx.hu/en/company/contact
Frequently asked questions
Does Scrum work on financial services IT projects? It depends on the conditions. Scrum works well for dedicated, autonomous teams, greenfield development and fintech start-ups. In large financial institutions - where decision-making is slow, teams aren't autonomous and the backlog is dictated by compliance requirements - formal Scrum usually doesn't deliver the expected results. The agile mindset remains valuable, but the ceremonies need adapting.
What is the difference between Scrum and the agile mindset? The agile mindset is a set of values and principles - iterative delivery, continuous feedback, flexibility and close collaboration. Scrum is a specific framework that implements these principles through ceremonies, roles and artefacts. You can work with an agile mindset without Scrum - and in large financial institutions that is often the more effective approach.
When is it worth having a Scrum Master on a financial services project? When a genuinely dedicated, autonomous, cross-functional team is available, the organisation is ready to change its decision-making structure, and the nature of the project allows iterative delivery. If these conditions aren't met, an experienced business analyst or project manager with an agile mindset can be more effective.
Why doesn't Scrum work in large financial institutions? Four main reasons: decision-making is slow and can't be accelerated by a change of methodology, the team isn't organisationally autonomous, the backlog is dictated by external constraints, and the organisational culture doesn't support the time the ceremonies require. These are organisational problems, not technical or methodological ones.
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services.
