I'll say something that might get me uninvited from Agile conferences: after 25 years in financial sector IT — as CIO at a major insurer, Head of Development at a banking group, and board member at a leasing company — I stopped trying to run Scrum the way the textbooks describe it.

Not because I don't believe in agile principles. I do, deeply. But because I spent years watching Scrum implementations that looked exactly right on the surface — the ceremonies, the roles, the Jira boards — deliver exactly the wrong outcomes underneath.

And I think I finally understand why.

The Scrum Assumption Nobody Talks About

The Scrum Guide is a beautifully written document. Concise, principled, and built on a core assumption that it never quite states explicitly:

Your organization is ready to act like a startup.

Autonomous cross-functional teams. A product owner with real decision-making authority. Rapid feedback loops. Minimal hierarchy. The ability to ship something meaningful every two weeks.

In a 12-person SaaS startup, this is achievable. In a 500-person insurer operating under MNB regulation, DORA compliance, and a 30-year-old core system that processes €2 billion in annual premiums — it is not.

And here is what I find troubling: most Scrum implementations in enterprise financial institutions don't fail because people did it wrong. They fail because the organizational conditions that Scrum requires simply don't exist — and nobody was honest enough to say so before the transformation kicked off.

What "Agile Transformation" Actually Looks Like in a Bank

I've seen this pattern more times than I can count.

A consultancy is brought in. Workshops happen. Everyone gets certified. Jira is configured. The development team is reorganized into "squads." A Scrum Master is appointed — often someone who was a project manager six months ago and did a three-day course.

Six months later:

— The daily standups are status reports delivered to the Scrum Master, who reports upward to a steering committee that meets monthly — Sprint planning happens, but by Wednesday of sprint week, three "urgent" requests have arrived from the business that override everything in the backlog — The product owner — a senior BA who is also responsible for four other projects — can attend sprint review every other week — The retrospective is the first meeting to be dropped when the calendar fills up

Everyone is exhausted. Nobody feels like they're moving faster. The developers feel micromanaged. The business feels like IT is still a black box. Management has a velocity chart that means nothing.

This is what DevOps.com called "Scrumfall" — the ceremonies of Scrum grafted onto the hierarchy of waterfall, producing the overhead of both and the benefits of neither.

Three Structural Reasons Scrum Breaks in Financial Services

1. Decision latency is incompatible with sprint cadence A two-week sprint assumes that meaningful decisions can be made and acted upon within two weeks. In financial services, this is rarely true.

A change to an insurance product calculation requires compliance sign-off. A change to a banking API requires architecture review board approval. A change to a leasing contract workflow requires legal clearance. These processes take weeks — not because anyone is being obstructionist, but because the regulatory environment genuinely demands them.

The result: backlogs fill up with items that are technically ready to develop but can't move because a decision is pending somewhere in the organization. Velocity becomes a measure of organizational friction, not team productivity.

1. The "autonomous cross-functional team" is a fiction in most enterprises Scrum requires a team that contains everything it needs to deliver: development, testing, design, and a product owner with genuine authority over what gets built.

In most large financial institutions, these people sit in different departments, report to different managers, have different performance objectives, and are evaluated by different metrics. Assembling them into a "Scrum team" doesn't change any of that. The developer's manager still expects him to support legacy system maintenance. The tester's manager still assigns her to three other projects.

You can call it a Scrum team. It doesn't behave like one.

1. The backlog is not owned by the product owner Perhaps the most important assumption Scrum makes — and the most frequently violated in financial services — is that the product owner controls the backlog.

In a regulated industry, a significant portion of the backlog is not discretionary. Regulatory changes mandate development work that cannot be deprioritized. Audit findings create remediation items that override sprint commitments. DORA, PSD2, IDD, Solvency II — these don't negotiate with your product backlog.

When 40% of your backlog is externally mandated and non-negotiable, the concept of "sprint goal" becomes difficult to sustain. When a regulator publishes a circular in October with a March compliance deadline, your next three sprints are already planned — just not by your product owner.

The Uncomfortable Truth About Scrum Certifications

Here is something I've observed but rarely see written down:

The Scrum certification industry has a structural incentive to define Scrum success in terms of process adherence, not outcomes.

If your daily standup runs 15 minutes, your sprints are two weeks, and your board has the right columns — you are "doing Scrum," regardless of whether you're delivering value.

This creates a perverse dynamic: organizations invest in Scrum Masters who are expert at running ceremonies but have no authority to address the organizational dysfunction that makes those ceremonies ineffective. The Scrum Master facilitates the retrospective where the team identifies the same impediments for the sixth sprint in a row — impediments that require organizational change to resolve, which is not within the Scrum Master's remit.

I am not criticizing Scrum Masters. I am criticizing a framework that gives them responsibility without authority, in organizations that have not changed the fundamental conditions that make agile work.

What I Actually Tried

Before I abandoned formal Scrum in financial sector projects, I tried several adaptations:

Extended sprints. Three or four weeks instead of two, to accommodate longer decision cycles. This helped with some of the decision latency problem but eliminated the rapid feedback loop that is Scrum's core value proposition.

Compliance lanes. Separating mandatory regulatory work into a separate "compliance track" with its own capacity allocation. This helped, but created coordination overhead and made sprint planning significantly more complex.

Dual product owner. Pairing a business-side product owner with an IT-side technical owner. This occasionally worked well, but more often created ambiguity about who had the final call.

SAFe. I tried this at one organisation. SAFe is essentially an attempt to make Scrum work in enterprises by adding more structure, more roles, and more ceremonies. In my experience, it mostly added more overhead without solving the underlying organizational problems.

None of these felt like genuine solutions. They felt like patches on a framework that was built for a different context.

What We Do Instead — And Why It Works

At FrontX, we work exclusively on financial sector IT projects — insurers, banks, leasing companies. Over years of iteration, we've developed an approach that borrows from agile principles but doesn't attempt to impose Scrum ceremonies in organizations that cannot support them.

The core shift: we treat delivery transparency as the primary agile value, and let everything else follow from that.

Weekly written status communication

Every week, the project team produces a written status update covering three things: what was completed this week, what is committed for next week, and what was not completed and why. This is not a standup. It is a document that creates accountability, surfaces impediments, and gives the business a clear picture of progress without requiring everyone to be in the same room at the same time.

This sounds simple. It is. And in our experience, it is more effective than daily standups in organizations where the "team" is spread across departments and time zones.

Milestone-based delivery with iterative refinement

We define delivery milestones — not sprints. A milestone is a meaningful, demonstrable piece of functionality that the business can evaluate and respond to. The timeline between milestones is flexible: some take two weeks, some take six. What matters is that at each milestone, the business has something real to look at and the team has clear feedback to work with.

Explicit change management as a first-class process

Rather than trying to absorb scope changes within sprint boundaries — which rarely works in financial services — we treat every scope change as a formal change request: estimated, prioritized, and agreed upon by both the business and the development team before it enters the work queue. This eliminates the sprint disruption problem and gives the business genuine control over what gets built.

Business Analyst ownership throughout delivery

In financial sector projects, the BA is not a requirements document producer who hands off and moves on. Our BAs stay engaged through the entire delivery cycle — present at every demo, available to the development team when implementation questions arise, and responsible for ensuring that what gets built actually matches the business intent.

The majority of financial sector IT project failures I have seen are not caused by poor technology choices. They are caused by a gap between what the business intended and what the IT team understood — a gap that grows during implementation when the BA has moved on to the next project.

More on how we approach Business Analysis in financial sector projects: frontx.hu/szolgaltatasok/uzleti-elemzoi-szolgaltatasok

What We Keep From Scrum

I want to be careful not to suggest that Scrum has nothing to offer financial sector projects. Several of its principles are genuinely valuable:

— Iterative delivery — shipping something demonstrable regularly, even if "regularly" means every six weeks rather than every two — The retrospective — regular, structured reflection on how the team is working — Visible work — making work visible reduces coordination overhead and surfaces problems early — The definition of done — explicitly agreeing on what "done" means before development starts

What we have abandoned: the fixed sprint cadence, the daily standup as a synchronization mechanism, the velocity metric as a progress measure, and the Scrum Master role as a distinct function.

The Honest Conversation Financial Sector CIOs Need to Have

If you are leading IT in a financial institution and you are feeling pressure to "go agile," here is the question I'd encourage you to ask before you invest in a Scrum transformation:

What organizational changes are you prepared to make?

Because Scrum does not fail because teams do it wrong. Scrum fails because organizations don't change the conditions — decision authority, team autonomy, backlog ownership — that Scrum requires. The methodology is sound. The organizational readiness is usually not.

If you are not prepared to give a product owner genuine authority over the backlog — including the authority to say no to urgent requests from senior stakeholders — you will get Scrumfall. If you are not prepared to allocate dedicated, genuinely cross-functional teams, you will get the overhead of Scrum without the benefits.

A Note on Where Scrum Does Work

For balance:I have seen Scrum work well in financial services. The conditions where it succeeds are instructive:

— Fintech startups where the entire organization is built around product delivery — no legacy hierarchy, genuine product ownership — Greenfield development teams within larger institutions given genuine autonomy and protected from organizational interference — Digital transformation initiatives with strong executive sponsorship where the sponsor has actively cleared organizational impediments before the team started

In all these cases, the common factor is not the Scrum framework. It is organizational readiness. Scrum works when the organization is ready for it. Our approach works regardless.

Conclusion

I stopped running Scrum in financial sector projects not because I stopped believing in agile principles, but because I stopped believing that agile principles require Scrum ceremonies to be effective.

The Agile Manifesto says: individuals and interactions over processes and tools. Scrum, in enterprise financial services, has too often become the opposite — a process imposed on individuals, a tool that serves the reporting hierarchy rather than the delivery team.

What we have built at FrontX is an approach that takes agile principles seriously without requiring organizational transformation that most financial institutions are not ready for. It is less elegant than pure Scrum. It is more effective.

If you're leading IT delivery in a financial institution and the Scrum implementation isn't working the way you hoped — reach out. You can find how we approach delivery at frontx.

Author Bio

László Behán is the CEO of FrontX, a senior IT consulting and development firm specializing in financial sector enterprises — insurers, banks, and leasing companies. Previously CIO at Signal Insurance, Head of Development at Groupama Insurance, and Board Member at LeasePlan Hungary. 25 years of financial sector IT experience.

FrontX works on business analysis, custom software development, legacy modernization, and QA in financial sector environments. More at frontx.hu