How Scrum became a burden — and what we did about it

[#1]

A real story from the Planyway team — how we lost our way with Scrum and how we found our new way

Scrum is supposed to be this brilliant thing, right? Self-organizing teams. Fast feedback. Meaningful work. A steady rhythm of improvement. At first, it worked great. But over time, we lost that spark. 

We didn’t stop doing Scrum. In fact, we were following it more “by the book” than ever. The boards, the ceremonies, the roles, the points… all of it. But something felt off. 

Eventually, we had to face it: Scrum didn’t fail us, but it turned into something slow and overly focused on process. It crept in without us noticing, and before we knew it, it felt more like a routine than a solution. Here's where things went off track:

• Ritual trap. Scrum’s ceremonies became just routines. Retrospectives turned into a loop of complaints with no action. Daily stand-ups were more about status updates, and sprint planning felt like task breakdowns instead of creating value.
• Scrum Master as a cop. Our Scrum Master, meant to coach us, ended up just enforcing rules—like "Is the stand-up under 15 minutes?" and "Did we estimate in story points?" The team started following the process rather than owning it.
• The myth of the cross-functional team. Scrum assumes one team does it all, but as we grew, it didn’t fit. We had separate teams for front-end, back-end, QA, and infrastructure—each with different priorities. Instead of a self-sufficient unit, we had a chain of dependencies slowing us down.
• Too many teams, too many meetings. As more teams joined, things got more complicated. One Product Owner couldn’t keep up, and “Scrum of Scrums” just added more meetings and delays. The process became the work, not the solution.

So, what did we do about it?

We took a step back and asked ourselves: Is Scrum still working, or are we just sticking with it out of habit?

Instead of ditching Scrum, we evolved it. We adopted Scrumban—a mix of Scrum and Kanban—and the addition of Kanban practices breathed new life into our process. It felt so much more obvious and closer to reality than artificial two-week chunks:

• Continuous flow. Continuous flow which is exactly like how things happen in real life. 
• Pull system. We only pull in new tasks when we have the resources available.
• Prioritize completion. Our focus shifted to finishing existing tasks rather than constantly starting new ones.
• WIP limits. We set clear WIP limits to avoid getting bogged down.
• Statistical basis. A huge bonus is the statistical data we now gather that let us make data-driven decisions. Read how we estimate tasks with 80% probability.

Plus, we kept the practices that were truly good in Scrum:

• Dailies. We still have stand-ups, though not strictly every day. The principle is different now: we go through the board from right to left, top to bottom, asking: "What should we do to complete this task?"
• Retrospectives. Retrospectives remain crucial for continuous process improvement.
• Sprint-like periods. We have something akin to sprints, but they're essentially just time segments where we summarize progress or bring closure to certain initiatives, without disrupting the flow of tasks.

Was it perfect?

No. But it was real. It felt more in sync with how we work and what we value. And that made all the difference.

What we learned

Sometimes, it’s okay to question the process. Scrum isn’t sacred—it’s about what works for your team. So ask yourself: Are our meetings solving problems or draining energy? Is the team excited about their work or just going through the motions?

We’re still learning and improving, but the change made us more aligned, more focused, and way happier.