Scrum vs Kanban in a Real Project: What Happens When the Process Starts to Crack

In this article, we’ll take a look at Scrum vs Kanban, and the use of both of these Agile frameworks as new projects come on board. What happens when things start to go south? How to manage and solve the “cracks” properly? Keep reading and learn more about this topic.

When we enter a new project, one of the strongest indicators of the organisation’s health is the presence or absence of clear processes. In this case, right after completing the Technology Due Diligence phase, it became clear that the client had significant gaps in how work was being planned, prioritised and delivered. There was no real operational framework. Requests arrived from everywhere: the CEO, marketing, the product owner and occasionally even from individuals who simply “noticed something was off” and sent a message. These requests then were given directly to the team, often without triage, context or discussion.

The team had to react to those requests and try to fulfil them, instead of planning and estimating them. Some work was important, some was urgent, some was neither. Still, everything felt equally “top priority”. There was no shared view of what mattered most or why certain things were being done. This setup was good enough while the team was small. At one point, when more people joined the team and when the project grew, it was difficult to keep things under control.

We knew this wouldn’t scale. Sooner or later it would start impacting both delivery and the team itself. That’s why our first step was to introduce more structure. Given the situation, Scrum felt like a natural starting point.

Why We Started With Scrum

The idea behind introducing Scrum was simple. We wanted to slow things down just enough so the team could actually finish what they started. A two-week sprint seemed like a good choice. Anything shorter felt too hectic and anything longer would just delay feedback. At the start of the sprint, we agreed on what the team would work on next, write it down and try not to change it unless we really had to.

We also put a bit more structure around estimations. We did this to detect what was risk, what was small and what was likely to take longer. This helped to achieve shared understanding within the team, rather than just talking about the numbers.

That was it. No big transformation, no process theatre. Just an attempt to make work a bit more predictable.

A Quick Refresher: What Scrum Actually Is (and Isn’t)

Scrum is a lightweight framework for solving complex problems and delivering value iteratively. It works by giving teams short cycles (sprints) during which they commit to a set of work, focus on that work without interruption and inspect and adapt through regular ceremonies: Sprint Planning, Daily Stand-ups, Sprint Review and Retrospective.

A few principles are key:

• Commitment over flexibility: Once the sprint starts, scope shouldn’t change.
• Cross-functional teams: Everyone needed to deliver the increment should be inside the team.
• Predictability through iteration: Velocity helps forecast future delivery.
• Clear ownership: A Product Owner prioritises the backlog; the team decides how to deliver.

This approach usually works well when the team is stable. Also, it works when there are not that many dependencies or when you can predict them on time.

In our case, that approach was not working well as we had both dependencies and the growing team.

Where Scrum Started Falling Apart

On paper, Scrum made sense for this project. Scrum was meant to give us structure and clearer planning. In reality, we quickly saw that it was taking a lot of effort to run, without delivering the benefits we expected.

Truth is, Scrum as a framework was not the problem. The problem was the environment we were trying to apply it in.

1. Constant changes in priorities, even inside the sprint

The client operates in a fast-moving setup where priorities change often. New requests would come in during an active sprint, usually triggered by external commitments or sudden business decisions. These weren’t edge cases. They happened regularly.

Sometimes these were small changes, but often they were high-priority, “must ship by Friday” tasks. And when the CEO or a senior manager says something must be done by Friday, any illusion of sprint stability disappears.

As a result, the team regularly had to break sprint commitments to handle urgent work. This created a ripple effect:

• Velocity became unreliable.
• The burndown chart stopped reflecting reality.
• Failed commitments needed to be explained every sprint.
• The team lost confidence in estimation, because estimates weren’t honoured.

We were trying to commit to stability in an environment that wasn’t stable.

2. Ad-hoc work for specialised team members

Beyond standard feature work, some team members (especially in data engineering and DevOps) were receiving tasks outside the backlog entirely. These were operational, urgent and unpredictable.

Scrum works when most of the work can be planned upfront. When a large part of someone’s workload is reactive, that quickly stops being true.

3. A dual-vendor setup created unavoidable delays

This project wasn’t unique in having multiple vendors, but the dynamics significantly impacted flow. The other vendor owned the codebase. Any change we made had to go through their code review, or their testing process, or sometimes both.

In theory, this is manageable. In practice, the other team wasn’t particularly open to collaboration and this created slowdowns that were outside our control. Tasks that should have been completed within a sprint often lingered in “Waiting for review/testing” from the other vendor.

This made our sprint burndown look worse than it should have. Work wasn’t “not done” because we didn’t do it. It was blocked elsewhere.

But burndown charts don’t know whose queue the task is stuck in.

Again, Scrum looked dysfunctional because the environment was dysfunctional.

4. Business deadlines trumped story points

Scrum works well when planning is driven by the backlog, not external fixed dates. But there were periods when the client would receive a deadline from their management or partners that something needed to be delivered by a specific date, regardless of our estimation.

In those moments, story points, velocity and sprint forecasts became irrelevant. Delivery trumped the process and the team would scramble to meet a hard date simply because the business required it.

5. The scope of work shifted away from the original engagement

Our initial scope was to address findings from the Technology Due Diligence. After the project started, that was no longer the main focus. Instead of focusing on improvements, optimisations and technical debt, work that fits well into Scrum, we found ourselves working on core product features and fast-moving requests.

In other words: the type of work shifted and the process had to shift with it.

The Turning Point: Scrum Alone Wasn’t Enough

After several sprints, we were aware that Scrum wasn’t giving us what we needed. We knew that the framework itself wasn’t the issue, the context was. We were trying to enforce stability in an environment that was inherently dynamic, with shifting priorities, external dependencies and irreversible deadlines.

We had two options:

1. Blame the environment and fight to “protect the sprint.”
2. Adapt the process to match reality.

We chose the second.

A Hybrid Model: Scrum Structure With Kanban Flexibility

So we’re not talking about Scrum vs Kanban, but rather a model that uses both of these Agile frameworks. We kept Scrum where it made sense and added Kanban practices where we needed flexibility. The goal was simply to have a process that worked for the team and gave the client visibility.

1. We kept the two-week sprints but removed the rigidity.

The sprint cadence gave the team rhythm and focus, so we kept it. But we stopped obsessing over velocity and story points, because they simply weren’t relevant in an environment where deadlines were often fixed externally.

Instead of asking:
“How many points can we commit to?”
we shifted to:
“What needs to be delivered by what date?”

2. Scope changes inside the sprint were no longer a sin.

Rather than pretending the world stops during a sprint, we allowed ourselves to swap items in or out when priorities changed. This removed the guilt and the sense of “breaking the rules.”

If a new priority came in:

• We pulled it into the sprint.
• We removed something of similar effort or lower urgency.
• We communicated openly with the client.

This made the process resilient instead of fragile.

3. We used Kanban principles to manage flow.

We visualised all work on the board, clarified what was blocked and highlighted delays caused by external vendors or waiting for reviews. But we did this inside a sprint structure, not instead of it.

The board wasn’t a burndown tool, it was a flow tool.

4. We planned one or two sprints ahead with the client.

Working closely with the Product Owner and the client’s technical director, we shaped the high-level scope for the next sprint or two. Then, at planning, we translated that scope into actionable items for the team.

This struck a balance between flexibility (Kanban) and structure (Scrum).

5. The team became less stressed and the client saw visible progress.

Removing unnecessary constraints and adding transparency had immediate impact:

• Developers had fewer interruptions during a sprint.
• The client saw continuous progress on the board.
• Changes no longer “broke the process.”
• We stopped spending so much time justifying what was on the board and could focus on doing the work that mattered.

More importantly, the process became something that actually supported the team and the client, instead of causing stress.

What Our Hybrid Approach Achieved

This blended model allowed us to:

• Maintain focus and organisation through fixed sprints.
• Accommodate real-world priority changes without ceremony violations.
• Handle external dependencies more effectively.
• Give the client clear visibility into progress.
• Protect the team from unnecessary pressure linked to story points or velocity.

It wasn’t Scrum.
It wasn’t Kanban.
It was a purpose-built delivery model shaped for this client, this context and this team.

And it works.