In my previous article I looked at whether a financial services IT project needs a Scrum Master at all. My answer: it depends on conditions - and in large financial institutions those conditions are rarely met.
Now I want to take a step back: when Scrum, when Kanban, and when neither?
Because in my experience many people confuse the two methodologies, many use them interchangeably, and few think through what each is actually for.
The essence in one sentence
Scrum creates value in iterations, delivering a working product increment every sprint. Kanban creates value in a continuous flow - no sprints, no fixed time box; work items flow through the system continuously.
At first glance this difference looks technical. In reality it has organisational and business consequences.
When is Scrum the right fit?
Scrum works well when the goal of the project is building a new product or feature - where requirements can be refined based on iterative feedback, and where the team can deliver something of real value every sprint.
Three conditions without which Scrum doesn't work:
A stable team. Scrum assumes a cross-functional team - developers, testers and a BA in one team, dedicated to the project. If team members work on several projects in parallel and keep changing, Scrum's overhead doesn't pay off.
Requirements that can be iterated. Scrum adds value when the product owner can prioritise and the team can get feedback every sprint. If the requirements are fully defined up front and can't change - a regulatory compliance project, for example - the Scrum ceremonies are unnecessary.
Decision-making authority. The product owner can decide what goes into the next sprint. If every decision has to go through a committee or an approval process, sprint planning becomes a formality.
When is Kanban the right fit?
Kanban works well when work is continuous and arrives at a variable pace - where there is no well-defined "end of project", but a steady stream of tasks to be handled in order of priority.
I see three typical Kanban areas in financial services organisations:
IT operations and support. Incident reports, change requests and smaller development requests can't be sprinted. They arrive continuously, with different priorities and different complexity. A Kanban board shows visually what is in progress, what is waiting and what is done - and WIP limits stop the team taking on too much at once.
Legacy system maintenance. Maintaining an insurance core system has no "sprints" - there is continuous change management that has to be documented, prioritised and executed. Kanban is perfect for this: the flow, the lead time and the bottlenecks are all visible.
Organising the work of BA and SA teams. The work of business analysts and solution architects can't be sprinted - they work on several projects at once, in different phases. A Kanban board makes visible who is working on what and where the throughput limits are.
Experience from financial services
I worked at a large insurer where the development team was organised in Scrum - sprints, daily stand-ups, retrospectives. Alongside it, the operations team used Kanban - continuous flow, a visual board, WIP limits.
This dual structure worked, and not by accident. It was a deliberate decision: development is iterative, operations is continuous. Nobody tried to sprint operations, and nobody tried to force development into Kanban.
Where I did see problems was where the two teams' work met. Development delivered a new feature every sprint, and operations had to integrate it immediately into its continuous system. That handover point was the source of tension - and neither Scrum nor Kanban solves it on its own. It has to be handled through an organisational agreement.
The third way: a hybrid approach
The choice between Kanban and Scrum also depends on how ready the organisation is to adopt a new mindset - but in reality you don't always have to choose. The two methodologies can be combined.
In practice, this is what I see working in financial services organisations:
Scrum for the development team - new features, projects, greenfield development.
Kanban for operations and support - continuous change management, bug fixing, maintenance.
Kanban for the BA and SA team - parallel projects, requirements discovery, specification.
This isn't a theoretical construct - it is the approach that can be introduced with the least organisational resistance and delivers visible value fastest.
When neither?
There are situations where neither Scrum nor Kanban is the primary answer.
One-off, well-defined projects. If a regulatory compliance project has to be delivered on a fixed deadline with a fixed scope, the classic project-based approach (milestones, a Gantt plan, change management) is simpler and more transparent. Scrum's overhead doesn't pay off, and Kanban's visualisation adds no value.
Very short projects. For a four- to six-week development, setting up the Scrum ceremonies takes a disproportionate amount of time away from the actual work. A simple, prioritised task list is more efficient.
An organisationally immature environment. If the organisation isn't ready to embrace the concept of self-organising teams, neither Scrum nor Kanban will work. The organisational conditions have to be created first.
The decision framework
Four questions to help decide which methodology fits your project:
Are the requirements iterative, refinable through feedback? If yes → Scrum. If no → Kanban or a classic project.
Is the work continuous or project-based? Continuous → Kanban. Project-based with a defined end point → Scrum or a classic project.
Is a dedicated, stable team available? If yes → Scrum can work. If no → Kanban is more flexible.
How fast is decision-making? Fast and autonomous → Scrum. Slow and approval-based → Kanban or hybrid.
What we do at FrontX
FrontX projects aren't tied to a single methodology. The need and the organisational context determine the tool - not the other way round.
On development projects we work iteratively - with modular delivery, weekly status communication and continuous prioritisation. That is closer to the Scrum mindset, but without the Scrum ceremonies.
For ongoing support and BA work we use Kanban-style task management - visual overview, WIP awareness and continuous prioritisation.
Methodology is a tool. The goal is to deliver what we promised, on time, in a way the client understands.
If you are working on a project where the methodology question is still open, we are happy to talk: frontx.hu/en/company/contact
Frequently asked questions
What is the difference between Kanban and Scrum? Scrum creates value in iterations - sprints: it delivers working product increments in fixed time-boxed cycles and introduces new roles (Scrum Master, Product Owner) and ceremonies (daily stand-up, sprint planning, retrospective). Kanban creates value in a continuous flow: no sprints, no fixed time box; work flows through the system continuously, and WIP (work in progress) limits prevent overload.
When should you use Scrum on IT projects? Scrum is appropriate when the goal is to build a new product or feature iteratively, the team is dedicated and cross-functional, the product owner can prioritise and give feedback every sprint, and decision-making is fast enough that sprints don't stall. In large financial institutions these conditions are rarely all met.
When should you use Kanban? Kanban is appropriate when work is continuous and arrives at a variable pace - IT operations, support, legacy system maintenance and organising BA and SA work. It is also the better choice when team members work on several projects in parallel, or when the organisation isn't ready for the structural changes Scrum demands.
Can Kanban and Scrum be combined within the same organisation? Yes - and in financial services organisations this is the most common and most practical approach. The development team uses Scrum, operations and support use Kanban, and the BA/SA team uses Kanban. The two methodologies are not mutually exclusive - different parts of the organisation have different needs.
Are there situations where neither Scrum nor Kanban is the best choice? Yes. For one-off, well-defined projects with a fixed deadline and scope - especially regulatory compliance projects - the classic project-based approach is simpler and more transparent. For very short projects the methodology overhead doesn't pay off. And in an organisationally immature environment neither methodology works - the organisational conditions have to be created first.
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.
