Scrum, the Way a Banker Still Loves It

4 MINS

I started my career writing ERP code at Infosys, then spent six years inside a bank doing trade finance, then came back to product. By the time I sat my SAFe 4 Practitioner exam, I had watched Scrum from three different chairs: engineer, business owner, and product owner. I want to put down what I actually believe about it, because the loud opinions on the internet rarely match what works inside a regulated bank.

Scrum is not the point. Cadence is.

Most teams that fail at Scrum don't fail because of Scrum. They fail because they have no cadence. They have meetings, but they don't have a rhythm where the same questions get asked at the same intervals, and the answers compound.

What I actually defend, when people want to ditch Scrum:

A short, predictable planning window. Two weeks, three weeks — pick one and stick to it.

A standup that is for the team, not for the manager. If standup turns into a status report, it's already broken.

A retro that produces one change. Not five — one. Everything else is negotiable. The cadence is not.

The banking reality nobody talks about

Inside a bank, your sprint is not the only clock. There is a regulatory clock, an audit clock, a treasury clock, and a vendor clock. Pretending you can run a "pure Scrum" team while ignoring those clocks is how delivery gets quietly destroyed.

The best PO move I have seen — and the one I now use — is to draw the other clocks on the same wall as the sprint board. Literally. When the team can see the regulatory submission window and the bond settlement cycle next to the sprint goal, prioritisation becomes obvious. When they can't, prioritisation becomes a fight.

What I keep, what I drop

After years of trying to make Scrum honest in environments it wasn't designed for, here is my personal list:

Keep: definition of done, refinement, retro, demo. These are the load-bearing parts.

Drop, or at least negotiate: estimation theatre, story-point arguments, velocity comparisons across teams. Everyone is lying about velocity, including you.

Add: a "fact pattern" in every story — one paragraph that describes the real customer or operational moment we are trying to fix. It kills a lot of pointless features in review.

A small closing thought

I am not a Scrum purist. I have sat in too many rooms where the framework became a way to avoid product thinking. But I am also not the person who dismisses it. Inside a bank, the discipline of a short cadence and an honest backlog is not a "framework choice". It is the only thing standing between a regulated product and chaos.

If your Scrum doesn't feel like that, the problem is probably not Scrum.

The Quiet Craft of Picking Payment Rails

Paul skipped presentations and built real AI products.

Paul K Paul was part of the March 2026 cohort at Curious PM, alongside 17 other talented participants.