Beyond Scrum: Scaling Down to Scale Up

I remember a time before Scrum. We had separate teams of 30 developers, 20 QA specialists and 10 business analysts. We had fixed-price contracts that somehow never quite matched the reality of what we delivered. The era of "big design up front" and waterfall development.

Then came Scrum, and what a relief that was. Scrum gave us structure. It gave us ceremonies. It gave us… meetings. So. Many. Meetings.

Don’t get me wrong—Scrum was definitely progress. It helped us escape the six-month development cycles and requirements that were obsolete before coding even began. But over time, I’ve begun to wonder if Scrum itself has become the very thing it sought to replace: a rigid framework that sometimes impedes rather than enables.

We determine story points because “that’s how we’ve always done it” not because they meaningfully guide our work. We hold retrospectives where the same issues resurface sprint after sprint, while new challenges are often resolved ad hoc well before it’s retro time. We cram features into artificial sprint timeboxes that are either too long or too short for what we’re actually building. And did I mention meetings?

“But you’re not doing Scrum right,” I can hear the certified Scrum scientists protest. Perhaps they’re correct. Perhaps we’re not.

Or perhaps it’s time for something new.

Lately, I’ve been dreaming of what might come after Scrum. Not a rejection of its core principles, but an evolution. A lighter pack for the next stage of our journey.

Here’s what I envision:

First, teams of three or four diverse developers. Total. They should be able to handle development, QA, business analysis, and product ownership between them. I’m convinced that smaller is better. Shorter communication paths. Complete shared context. Focused delivery. Faster pace.

Second, no more sprints. Instead, the team tackles one story together from start to finish. When it’s done, it’s pushed to production. Then and only then do they move to the next priority. (Of course, there’s still space for preparation and analysis work).

Third, no more story points. Let the team work with a roadmap covering several months, indicating what can likely be achieved while leaving room for high-priority adjustments that pop up along the way.

(And fourth, I’m not proposing to use Kanban. I want to go beyond Kanban too if we can, in both focus and flow.)

This isn’t the whole picture. I still wonder what might replace retrospectives and reviews. Something more continuous, perhaps? Something that happens in the moment rather than on a schedule?

Scrum helped us get this far. But there has to be a next path ahead, one where agility means truly being light on your feet rather than following a prescribed set of movements.