Why did I build a custom Scrumban instead of using standard Scrum?

Context

I joined a SaaS team with no formal development methodology. The immediate instinct — and the industry default — was to implement Scrum. I did, and it worked for months. But three constraints made pure Scrum unsustainable: frequent scope changes from urgent customer bugs, a team too small for proper Scrum roles, and stakeholders too busy to commit to full Scrum discipline.

Decision

I designed a custom Scrumban framework that preserved the parts of Scrum and Kanban that worked while discarding what didn't.

From Scrum, I kept: timeboxed iterations (goals and momentum), retrospectives (our strongest improvement tool), and structured planning.

From Kanban, I took: flexible scope handling (work can be reprioritized mid-iteration), visual flow management, and reduced ceremony overhead.

What I added: scope swap discipline (new urgent work replaces planned work, never adds to it), built-in buffer capacity (~20% reserved for inevitable interruptions), and adapted ceremonies that respected stakeholders' limited availability.

Consequences

Positive:

• Team delivered 100+ tickets in 6 months including a year's worth of stale backlog
• Process survived because it was designed for the team's real constraints, not textbook ideals
• Retrospectives continued driving improvement even without full Scrum structure

Negative:

• The framework is custom — new team members needed extra onboarding to understand it
• Purists might argue it's "not real Scrum" and "not real Kanban" — which is true, and intentional

Neutral:

• Required ongoing calibration — the buffer percentage and ceremony cadence needed regular tuning