From Zero Process to 100+ Tickets Delivered in 6 Months

The Problem

A SaaS/e-commerce platform supporting webshop owners had no formal software development methodology. The team shipped code continuously but never released to customers. Momentum was lost, meetings were disorganized, workload swung between congested and insufficient, and tickets were vague — no clear definition of done, no way to know if a feature was actually complete.

A year's worth of backlog had accumulated: bugs customers had reported, features that had been promised, and tech debt that kept compounding. Nothing was getting picked up.

Constraints

• Frequent scope changes driven by urgent customer bugs
• Team size too small for textbook Scrum
• Stakeholders and product owner too busy to commit to full Scrum ceremony discipline
• Existing customers growing frustrated with unfixed bugs and delayed features
• No prior process culture — the team had never worked with a formal methodology

My Role

Scrum Master + Technical Lead. I stepped up to own the process problem while simultaneously leading technical execution and a development squad. I worked directly with the CEO, CTO, product owner, developers, QA, DevOps, and UI/UX.

The Approach

Phase 1: Introduced Scrum

I proposed and implemented Scrum as the starting framework. It worked for several months — the team gained structure, retrospectives drove real improvements, and we started releasing.

But it broke down. Three constraints killed it:

• Frequent customer bugs created constant scope changes that disrupted sprint commitments
• The team wasn't large enough for proper Scrum roles and ceremonies
• The product owner and stakeholders couldn't commit to the discipline Scrum demands

Phase 2: Pivoted to Kanban

I switched to Kanban's continuous flow model to accommodate the interruption-heavy reality. It solved the scope change problem — work could be reprioritized without breaking a sprint.

But it created new problems:

• Without timeboxed sprints, we lost goals and deadlines — work just flowed endlessly
• The pull-based system removed the leadership structure the team needed
• Retrospectives — which had been our strongest improvement tool — disappeared

Phase 3: Designed Custom Scrumban

I synthesized what worked from both methodologies and tailored it to the team's constraints:

• Timeboxed iterations (from Scrum) — kept goals and momentum
• Flexible scope (from Kanban) — scope swaps instead of scope additions when urgent bugs arrived
• Buffer capacity — reserved team capacity for inevitable scope creep rather than pretending it wouldn't happen
• Preserved retrospectives — the single most valuable Scrum ceremony, kept regardless of framework
• Adapted ceremonies — shorter, focused meetings that respected stakeholders' limited availability

Key Decisions

• Scope swap, not scope add: When the product owner wanted to inject urgent work, I'd frame it as a tradeoff — "we can do X, but Y gets pushed out. Which matters more?" This forced prioritization instead of overloading the team.
• Built-in buffer for reality: Instead of planning at 100% capacity and failing when interruptions hit, I planned at ~80% and used the buffer for the inevitable urgent bugs and scope changes.
• Never sacrificed quality for speed: When something couldn't be delivered in time, I'd break it into smaller deliverables rather than rushing a fragile implementation.

The Outcome

• Delivered 100+ tickets in approximately 6 months — including new features, bug fixes, tech debt, and stale backlog items that had been ignored for over a year
• Existing customers saw their long-standing issues resolved — direct impact on customer satisfaction
• The team gained a sustainable, repeatable process that matched their actual working constraints
• Engineering workflows improved: stronger code reviews, clearer release processes, better cross-functional collaboration
• The framework was designed for the team's reality, not for a textbook — built to be sustainable beyond any single person

What I'd Do Differently

I'd introduce the hybrid framework sooner. The months spent on pure Scrum and pure Kanban were valuable learning, but in hindsight, the constraints (small team, busy stakeholders, frequent interruptions) were visible from day one. I could have reached the Scrumban solution faster by acknowledging those constraints upfront instead of trying to make textbook methodologies work first.