Hybrid Agile Methodologies | Scrumban & Custom Approaches
Combine Scrum, Kanban, and other agile practices with GitScrum. Build Scrumban workflows, customize methodology, and evolve your process based on team needs.
9 min read
No single methodology fits everyone. GitScrum supports hybrid approaches, letting teams combine practices from Scrum, Kanban, and other frameworks.
Understanding Hybrid Approaches
Why Hybrid
REASONS FOR HYBRID METHODOLOGIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PURE SCRUM: │
│ ─────────── │
│ ✅ Good for: Feature development, predictable work │
│ ❌ Challenges: Support work, frequent interruptions │
│ │
│ PURE KANBAN: │
│ ──────────── │
│ ✅ Good for: Support, maintenance, continuous flow │
│ ❌ Challenges: Planning capacity, sprint commitments │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ HYBRID WHEN: │
│ ──────────── │
│ │
│ MIXED WORK TYPES: │
│ Features (planned) + Support (unplanned) │
│ Need structure AND flexibility │
│ │
│ ORGANIZATIONAL CONSTRAINTS: │
│ Company uses sprints for planning │
│ But team needs Kanban flow for work │
│ │
│ TRANSITIONING: │
│ Moving from waterfall to agile │
│ Gradual adoption of practices │
│ │
│ TEAM PREFERENCE: │
│ Team experimented and found what works │
│ Mix of practices delivers best results │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ THE GOAL: │
│ ───────── │
│ Use practices that help YOUR team deliver value │
│ Not follow a framework for the framework's sake │
└─────────────────────────────────────────────────────────────┘
Scrumban
Combining Scrum and Kanban
SCRUMBAN OVERVIEW:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FROM SCRUM: FROM KANBAN: │
│ ─────────── ──────────── │
│ • Sprints (optional) • Visual board │
│ • Sprint planning • WIP limits │
│ • Retrospectives • Pull system │
│ • Daily standup • Flow metrics │
│ • Backlog • Continuous improvement │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ SCRUMBAN BOARD: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BACKLOG │ READY │ DEV (3) │REVIEW(2)│ QA (2) │ DONE ││
│ │ │ │ │ │ │ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ ││
│ │ │A │ │ │D │ │ │G │ │ │J │ │ │L │ │ │N │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ ┌──┐ ││
│ │ │B │ │ │E │ │ │H │ │ │K │ │ │M │ │ │O │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ │ └──┘ ││
│ │ ┌──┐ │ ┌──┐ │ ┌──┐ │ │ │ ││
│ │ │C │ │ │F │ │ │I │ │ │ │ ││
│ │ └──┘ │ └──┘ │ └──┘ │ │ │ ││
│ │ │ │ │ │ │ ││
│ │ │ │ WIP │ WIP │ WIP │ ││
│ │ │ │ LIMIT │ LIMIT │ LIMIT │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ KEY PRACTICES: │
│ ────────────── │
│ • Sprint planning for prioritization │
│ • Kanban board with WIP limits for execution │
│ • Pull work when capacity available │
│ • Flow metrics for improvement │
│ • Retros at end of sprint │
└─────────────────────────────────────────────────────────────┘
When to Use Scrumban
SCRUMBAN USE CASES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MAINTENANCE TEAMS: │
│ ────────────────── │
│ Mix of planned improvements and reactive fixes │
│ Sprint planning + continuous flow │
│ │
│ SUPPORT + DEVELOPMENT: │
│ ────────────────────── │
│ Dedicated feature work with support interruptions │
│ Reserve capacity for unplanned work │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CAPACITY ALLOCATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ SPRINT CAPACITY: 40 points ││
│ │ ││
│ │ PLANNED WORK: 30 points (75%) ││
│ │ ┌────────────────────────────────────────────────────┐ ││
│ │ │████████████████████████████████████████████████████│ ││
│ │ │ Features, Improvements, Tech Debt │ ││
│ │ └────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ UNPLANNED BUFFER: 10 points (25%) ││
│ │ ┌────────────────────┐ ││
│ │ │████████████████████│ ││
│ │ │ Support, Bugs, Urgent │ ││
│ │ └────────────────────┘ ││
│ │ ││
│ │ If buffer unused, pull from backlog ││
│ │ If exceeded, deferred to next sprint ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SWIMLANES: │
│ ────────── │
│ Separate lanes for planned vs unplanned work │
│ Different WIP limits per lane │
│ Track separately for analysis │
└─────────────────────────────────────────────────────────────┘
Building Your Methodology
Customization Process
CUSTOMIZING YOUR APPROACH:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STEP 1: START WITH A BASE │
│ ───────────────────────── │
│ Choose Scrum or Kanban as starting point │
│ Don't start from scratch │
│ Learn the framework first │
│ │
│ STEP 2: IDENTIFY PAIN POINTS │
│ ──────────────────────────── │
│ What's not working? │
│ What causes friction? │
│ What doesn't fit your context? │
│ │
│ STEP 3: EXPERIMENT │
│ ────────────────── │
│ Try one change at a time │
│ Run for 2-4 sprints │
│ Measure impact │
│ │
│ STEP 4: EVALUATE │
│ ──────────────── │
│ Did it help? │
│ Keep, adjust, or revert? │
│ Document the decision │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CUSTOMIZATION EXAMPLES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PAIN POINT EXPERIMENT RESULT ││
│ │ ────────── ────────── ────── ││
│ │ Sprints too rigid Kanban-style Kept: Better ││
│ │ continuous flow for support ││
│ │ ││
│ │ No planning Added weekly Kept: Better ││
│ │ visibility planning review predictability ││
│ │ ││
│ │ Standups too long Walk the board Kept: Faster, ││
│ │ right-to-left focused ││
│ │ ││
│ │ Retros boring Tried new format Reverted: Team ││
│ │ (4Ls) preferred old ││
│ └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
Documentation
DOCUMENTING YOUR METHODOLOGY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TEAM WORKING AGREEMENT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ TEAM: Platform Engineering ││
│ │ METHODOLOGY: Scrumban (Custom) ││
│ │ LAST UPDATED: January 2025 ││
│ │ ││
│ │ CADENCE: ││
│ │ • 2-week sprints for planning ││
│ │ • Continuous flow for execution ││
│ │ • Sprint planning: Monday Week 1 ││
│ │ • Retro: Friday Week 2 ││
│ │ • Daily standup: 9:30am (15 min) ││
│ │ ││
│ │ BOARD SETUP: ││
│ │ • Columns: Backlog, Ready, Dev, Review, QA, Done ││
│ │ • WIP limits: Dev(3), Review(2), QA(2) ││
│ │ • Swimlanes: Features, Bugs, Support ││
│ │ ││
│ │ CAPACITY: ││
│ │ • 70% planned work ││
│ │ • 30% buffer for support/urgent ││
│ │ ││
│ │ CEREMONIES: ││
│ │ • Planning: 1.5 hours ││
│ │ • Standup: 15 min (walk the board) ││
│ │ • Retro: 1 hour ││
│ │ • Refinement: As needed (1hr/week typically) ││
│ │ ││
│ │ METRICS TRACKED: ││
│ │ • Cycle time ││
│ │ • Throughput ││
│ │ • Planned vs unplanned ratio ││
│ │ ││
│ │ WHAT WE DON'T DO: ││
│ │ • Story points (we count items) ││
│ │ • Sprint commitment (we have targets) ││
│ │ • Sprint demos (we demo when ready) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Document helps: │
│ • Onboard new team members │
│ • Explain to stakeholders │
│ • Remember why decisions were made │
│ • Review and evolve intentionally │
└─────────────────────────────────────────────────────────────┘
Evolution
Continuous Improvement
EVOLVING YOUR METHODOLOGY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ REGULAR REVIEW: │
│ ─────────────── │
│ │
│ EVERY RETRO: │
│ "Is our process working?" │
│ Small adjustments │
│ │
│ QUARTERLY: │
│ Dedicated process review │
│ Bigger changes considered │
│ │
│ ANNUALLY: │
│ Full methodology assessment │
│ Still fit for purpose? │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ EVOLUTION EXAMPLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ METHODOLOGY EVOLUTION - TEAM ALPHA ││
│ │ ││
│ │ 2023 Q1: Started with Scrum ││
│ │ - 2-week sprints ││
│ │ - All ceremonies ││
│ │ - Story points ││
│ │ ││
│ │ 2023 Q3: Added WIP limits ││
│ │ - Too much WIP causing delays ││
│ │ - Added Kanban WIP limits to board ││
│ │ - Cycle time improved 30% ││
│ │ ││
│ │ 2024 Q1: Dropped sprint commitments ││
│ │ - Pressure causing poor estimates ││
│ │ - Switched to throughput tracking ││
│ │ - Team happier, similar delivery ││
│ │ ││
│ │ 2024 Q3: Added support swimlane ││
│ │ - Support work disrupting sprints ││
│ │ - Dedicated capacity (25%) for support ││
│ │ - Better visibility and balance ││
│ │ ││
│ │ 2025 Q1: Current state = Scrumban ││
│ │ - Sprints for planning, Kanban for flow ││
│ │ - Continuous improvement continues ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ KEY: Evolve intentionally based on evidence │
└─────────────────────────────────────────────────────────────┘