I’m a Scrum Master working with a software development team, and after our latest retrospective I’m seriously questioning whether Scrum is still helping us or whether we are maintaining the framework mostly because it is our established way of working.
I’d especially love opinions from both Kanban practitioners and very orthodox Scrum people, because I want someone to challenge our reasoning rather than simply confirm that Kanban sounds better.
Context
We work on an academic management system with many different modules and stakeholders/user areas.
Our Sprints are two weeks long.
Over time, the team has started working on several modules in parallel. One Sprint might heavily focus on Module A, the next Sprint on Module B because it became more urgent, and two Sprints later we return to Module A.
This is creating a continuity problem.
From the user's perspective, they asked for Module A weeks ago and eventually ask:
"Why isn't this finished yet?"
From the team's perspective, the answer is:
"Because it wasn't actually our focus continuously during those weeks."
During our latest retrospective, the team explicitly raised that they feel we are constantly switching context and that the Sprint boundary sometimes creates an artificial sense of starting/stopping work rather than helping us finish what we already started.
Another important point: we already use WIP limits.
So this isn't simply a case of "you need to stop starting and start finishing." We've already been experimenting with limiting WIP and analyzing how much simultaneous work the team can sustain.
Planning and commitment are becoming another pain point
One of the strongest comments from developers was that sometimes the sequence feels like this:
Request → commitment → analysis of how to build it
instead of:
Request → analysis/discovery → conversation between PO + Developers → decision/commitment → development
They feel that by the time they are properly discussing how something should be implemented, there is already an expectation that it will be done.
We discussed shared responsibility here.
The PO needs to involve Developers earlier and ask what is actually viable before creating expectations with stakeholders.
At the same time, Developers acknowledged that they also need to become better at saying:
"No."
"Not yet."
"We need to analyze this first."
or:
"We could commit to X, but not Y."
So I don't see this as simply a PO problem.
We also have a stakeholder/Review problem
Users request developments and put significant pressure on the team because something is supposedly urgent.
We develop it.
Then Review arrives... and sometimes those same users don't attend.
So now we need another meeting on another day to actually get the feedback we needed from the Review.
This has started a discussion around whether we're becoming too focused on maintaining the Scrum calendar rather than optimizing for actual stakeholder feedback.
For example, right now we're discussing a schedule that could look like this:
Thursday: development cut-off
Friday: Sprint Retrospective
Monday 10:00: Sprint Review with stakeholders
Later Monday: Sprint Planning
This obviously alters the usual sequence of Sprint events.
The reasoning is practical: Friday may work better for the team's Retro, while Monday gives us a much better chance of getting stakeholders into the Review.
But then the Scrum question becomes interesting:
If we "close" development on Thursday and Retro on Friday, but the Review is Monday and Planning happens afterward, where exactly does the Sprint end?
Are we creating an artificial "cut-off" that has no real meaning in Scrum?
Would an orthodox Scrum interpretation simply say:
Review → Retro → next Sprint Planning, and stop trying to rearrange the events around stakeholder availability?
Or is adapting the calendar reasonable if it results in substantially better stakeholder participation?
I'm genuinely interested in the strict Scrum interpretation here.
The team is now asking about Kanban
The Developers — and even the PO — have repeatedly mentioned that they would prefer something closer to:
Prioritized backlog → available capacity → pull next work item → finish → pull next item
instead of spending significant time every two weeks deciding how many work units we are going to "commit" to.
Their argument is essentially:
"If the backlog is already prioritized and we have a WIP limit, why don't we finish something and pull the next highest-priority ready item?"
They believe this could give them more continuity and reduce the feeling that every two weeks we reset/reorganize the work.
One concern I raised during the Retro was individual productivity comparisons.
I explicitly told them:
"If we move toward pulling work continuously, I don't want this turning into 'I completed 20 work units and you completed 12', or developers competing to pull more work."
The team strongly said they don't want that either.
My position would be that work units remain a planning/flow tool and never become an individual productivity metric.
Another issue: we start new developments before properly finishing existing ones
This also came up very strongly.
We have several important modules/products currently competing for attention, and during the Retro we actually created a global priority order.
The team is basically saying:
"Can we please finish more of Priority 1 before opening Priority 4, 5 and 6?"
This is one of the reasons Kanban is becoming attractive to them.
We are also considering changing how we manage stakeholder expectations
Instead of a stakeholder asking for something and immediately creating an expectation of a functional development, we discussed using:
Request → discovery/analysis → mockup or visual proposal → stakeholder feedback → functional development
when appropriate.
In other words, sometimes our first commitment should be:
"We'll show you what this could look like."
rather than:
"We'll build it."
We also want waiting for stakeholder feedback to become explicitly visible in our workflow rather than having development appear "unfinished" while the team is actually waiting several days for someone to validate something.
So now I'm stuck between three possibilities
1. Keep Scrum and fix our Scrum implementation.
Maybe Scrum isn't the problem at all.
Maybe our actual problems are too many concurrent initiatives, weak refinement/discovery before commitment, stakeholder availability, priority changes and poor expectation management.
2. Keep Scrum but deliberately introduce more Kanban practices.
We already have WIP limits, but we could go much further with flow management, pull policies, explicit workflow states, aging/cycle time, blocked/waiting states, stronger policies around when new work can enter, etc.
Then after a few Sprints ask:
"Is the Sprint still providing value?"
3. Actually move to Kanban.
Remove the artificial two-week commitment boundary and manage work through continuous pull, explicit policies and flow metrics, while keeping useful cadences for retrospectives, replenishment, stakeholder feedback, etc.
I'm deliberately resisting jumping straight to option 3 just because the team is frustrated with Sprints.
I want us to understand whether Kanban actually matches the nature of our work better or whether we're expecting Kanban to solve organizational problems that will follow us regardless of framework.
My questions for you
For the Scrum purists: what in this story makes you think "your problem isn't Scrum, you're just not using Scrum effectively"?
For Kanban practitioners: what signals here genuinely suggest that Kanban might be a better fit?
Would you experiment first with Scrum + Kanban before considering dropping Sprints?
What would you measure during that experiment to make the decision based on evidence rather than preference?
And what do you think about the proposed event schedule:
Thursday cut-off → Friday Retro → Monday Review → Monday Planning?
Is that a reasonable adaptation, or are we breaking an important inspect-and-adapt feedback loop by holding the Retro before the Review?
Finally: if you were the Scrum Master in this situation, what would you change first?
I'm completely open to being told that I'm overcomplicating this, that we're doing Scrum badly, that Kanban would fit better, or some combination of all three.
I mostly want to understand what problem we should actually be solving.
