Agile fatigue is real. And nobody really dares to say it.
We have all experienced these rituals that resemble corporate theater. The 9 AM stand-up where everyone recites their little speech. The retrospective where we stick colorful post-its only to change nothing in the end. The sprint planning that lasts three hours and results in totally fanciful estimates. We apply the Scrum guide rules with religious fervor, convinced that the methodology will save the project. Spoiler: it is not the methodology that saves projects. It is the quality of human interactions and the clarity of objectives.
The problem is that agile has become a product. Certifications that cost a fortune, frameworks that pile up, coaches selling digital transformation at a high price. As a result, we end up with teams pretending to be agile while keeping the worst aspects of waterfall. We still plan six months ahead, change our minds at the last minute, and ask teams to deliver within unrealistic deadlines. Except now we call them sprints, so it is supposed to be different. It is not different. It is just more expensive and more exhausting.
I see this regularly in data and product teams. They undergo processes designed for pure software developers, without adaptation to their reality. A data team does not work like a frontend team. Tasks are not always decouplable into homogeneous small batches. Some analyses take the time they take. Some explorations lead in unexpected directions. Forcing all of this into two-week sprints with story points is organizational masochism.
This is where Scrumban comes in. And no, it is not just a buzzword to sound modern.
Scrumban takes what really works in Scrum, namely the regularity of rituals and the visibility of work in progress, and combines it with the fluidity of Kanban. No more rigid sprints. No more mandatory estimates that make no sense. No more artificial demonstrations just to say we did a demo. Instead, we have a continuous flow, work in progress limits that prevent the team from scattering, and rituals that only exist if they bring value.
The beauty of Scrumban is its flexibility. You keep your stand-up if you need it, but you shorten it to ten minutes maximum. You keep planning, but it becomes continuous rather than calendar-based. When a task is ready, you take another one. Period. No artificial stress linked to the end of a sprint. No forced demo of a half-finished feature just because it is Friday and the sprint is ending.
For data and product teams, it is often a relief. These teams need to explore, iterate, change priorities when new data calls the analysis into question. Scrumban gives them this permission without guilt. The Kanban board remains visible, transparent to everyone. Blockages are identified quickly. But the team is no longer a slave to an artificial rhythm that does not match their actual work.
So when to choose Scrumban over pure Scrum? As soon as your work is unpredictable, exploratory, or subject to frequent interruptions. If you spend your time saying this sprint is doomed, we had an emergency, Scrumban is for you. If your tasks vary enormously in size and estimating takes longer than doing the task itself, stop torturing yourself. If your team is mature and does not need a strict framework to move forward serenely, free them from these unnecessary constraints.
Pure Scrum makes sense when you are delivering software with predictable releases, a stable roadmap, and a team that needs protection from interruptions. It is a valid tool, but it is not the only possible answer.
At the core, the real question is not Scrum or Scrumban or Kanban. The real question is: what allows this specific team to deliver value sustainably? Sometimes the answer will be Scrum. Often, for data and product teams today, it will be Scrumban. And sometimes it will be something you invent yourself, because no existing methodology perfectly matches your context.
Pragmatism is the only true agile. Everything else is just corporate religion.
And you, is your team still trapped in rituals that serve no one? What would stop you from experimenting with something else starting next week?
0 commentaires