Scrum vs Kanban: Dwa filary Agile
W 2026 Agile dominuje w software development — 94% zespołów IT używa frameworków Agile (State of Agile Report 2026). Dwa najpopularniejsze:
- Scrum — 70% zespołów Agile (Scrum.org, Scrum Alliance certyfikacje: 1.5M+ Scrum Masters globalnie)
- Kanban — 25% zespołów (głównie operations, support, DevOps)
- Scrumban (hybrid) — coraz popularniejsze, 45% zespołów Scrum dodaje WIP limits po 2-3 latach
Decyzja Scrum czy Kanban wpływa na:
- Strukturę meetings — Scrum ma 5 formalnych eventów, Kanban brak
- Role w zespole — Scrum 3 jasne role, Kanban brak
- Predictability — Scrum forecast-driven (sprint goals), Kanban flow-driven (cycle time)
- Adaptability — Kanban szybciej reaguje na zmiany, Scrum bardziej structured
Tabela porównawcza — Quick Reference
| Aspekt | Scrum | Kanban |
|---|---|---|
| Filozofia | Iteracyjny + inkrementalny | Continuous flow |
| Czasoboksy | TAK (sprint 1-4 tyg.) | NIE (continuous) |
| Role | 3 (PO, SM, Devs) | Brak formalnych |
| Eventy | 5 (Planning, Daily, Review, Retro, Sprint) | Brak formalnych (opcjonalne) |
| Plan zmian | Zamrożony przez sprint | Może zmieniać się dynamicznie |
| Metryki | Velocity, Burndown, Predictability | Lead Time, Cycle Time, Throughput |
| Limit pracy | Sprint Backlog | WIP limits per kolumna |
| Idealne dla | Product development, projekty | Operations, support, maintenance |
| Krzywa uczenia | Stroma (formal training) | Łagodna (start z prostym board) |
| Certyfikacje | PSM I/II, CSM, PSPO | Kanban Foundation, KMP I/II |
| Czas startu | 2-4 tyg. (training + setup) | 1 dzień (board + WIP limits) |
| Adopcja w 2026 | 70% Agile teams | 25% Agile teams |
Scrum — Deep Dive
Czym jest Scrum
Scrum to lightweight framework dla complex product development, stworzony w 1995 przez Ken Schwaber & Jeff Sutherland. Definiowany w Scrum Guide (aktualna wersja 2020 — 13 stron).
Scrum opiera się na 3 filarach (empirical process control):
- Transparency — wszystko widoczne dla wszystkich
- Inspection — częste sprawdzanie postępu
- Adaptation — szybka korekta kursu
3 role w Scrum
-
Product Owner (PO):
- Maximizuje wartość produktu
- Zarządza Product Backlogiem (priorytetyzacja, ordering, refinement)
- 1 osoba (nigdy committee)
- Single point of accountability dla “co” jest robione
-
Scrum Master (SM):
- Coach zespołu i organizacji
- Servant leader (NIE PM, NIE manager)
- Removes impediments
- Facilitates Scrum events
- Supports PO w backlog management
-
Developers (formerly Development Team):
- Self-organizing
- Cross-functional (cały skill set wymagany do delivery)
- 3-9 osób (sweet spot 5-7)
- Accountable for: incrementu, Sprint Backlog, technical decisions
5 eventów w Scrum
- Sprint (1-4 tyg., zazwyczaj 2 tyg.) — container dla wszystkiego
- Sprint Planning (max 8h dla 4-week sprint, 4h dla 2-week) — co i jak będzie zrobione
- Daily Scrum (15 min dziennie) — synchronizacja zespołu
- Sprint Review (max 4h dla 4-week sprint, 2h dla 2-week) — demonstracja stakeholderom
- Sprint Retrospective (max 3h dla 4-week sprint, 1.5h dla 2-week) — improvement zespołu
3 artefakty w Scrum
- Product Backlog — wszystkie wymagania (zarządzany przez PO)
- Sprint Backlog — co będzie zrobione w sprincie (zarządzany przez Devs)
- Increment — działająca wersja produktu na koniec sprintu
Kiedy Scrum działa najlepiej
- Product development z definiowanym Product Vision
- Zespoły 5-9 osób (cross-functional)
- Stakeholders dostępni dla regular feedback
- Możliwość 2-4 tygodniowych iteracji
- Jasne Definition of Done
Kiedy Scrum NIE działa
- Operations/support (praca napływa nieprzewidywalnie)
- Solo work (Scrum dla zespołów 3+)
- Fixed-scope, fixed-time, fixed-cost projekty (Scrum embraces change)
- Kulturze “command and control” (Scrum wymaga self-organizing teams)
Kanban — Deep Dive
Czym jest Kanban
Kanban (jap. “tablica wizualna”) to metoda zarządzania pracą stworzona w Toyota (1940s) dla lean manufacturing, zaadaptowana dla software przez David Anderson (2010, książka “Kanban: Successful Evolutionary Change”).
Kanban to method, NIE framework — czyli można go nałożyć na istniejący proces bez “rewolucji”. Główna zasada: “Start with what you do now”.
6 praktyk Kanban
- Visualize — kanban board (kolumny = stages workflow)
- Limit Work in Progress (WIP) — max items na kolumnę
- Manage Flow — minimize cycle time, eliminate bottlenecks
- Make Policies Explicit — Definition of Done, criteria for moving
- Implement Feedback Loops — daily standup, replenishment meeting, service delivery review
- Improve Collaboratively, Evolve Experimentally — kaizen + Deming PDCA
Kanban board — przykład
┌─────────┬──────────┬───────────┬─────────┬───────┐
│ Backlog │ Selected │ In Progress │ Review │ Done │
│ │ WIP: 5 │ WIP: 3 │ WIP: 2 │ │
├─────────┼──────────┼───────────┼─────────┼───────┤
│ Item 8 │ Item 4 │ Item 3 │ Item 1 │ Item A│
│ Item 9 │ Item 5 │ Item 6 │ Item 2 │ Item B│
│ Item 10 │ Item 7 │ │ │ Item C│
└─────────┴──────────┴───────────┴─────────┴───────┘WIP limit blokuje zaczynanie nowej pracy gdy kolumna pełna — focus on completion.
Kanban metryki
- Lead Time — od request do delivered (whole journey)
- Cycle Time — od start work do delivered (active work only)
- Throughput — items completed/period (e.g., 15 stories/week)
- Cumulative Flow Diagram (CFD) — visualization of WIP, bottlenecks, predictability
- Aging WIP — jak długo item jest w danej kolumnie
Kiedy Kanban działa najlepiej
- Operations, support, maintenance
- DevOps teams (incidents + planned work mix)
- Content marketing (continuous publication)
- Help desk / customer service
- Mature teams (po 2-3 latach Scrum)
Kiedy Kanban NIE działa
- Greenfield product development bez ustalonego workflow
- Junior teams (brak struktur)
- Wymóg formal predictability (sprints + commitments)
Scrumban — Hybrid
Scrumban = Scrum framework + Kanban practices.
Implementacja Scrumban
- Scrum elementy: role (PO, SM, Devs), Daily Scrum, Sprint Retrospective, Sprint Goals
- Kanban elementy: WIP limits per kolumna, kanban board z explicit policies, cycle time metrics, continuous flow zamiast strict sprintów
Kiedy używać Scrumban
- 30%+ pracy to nieplanowane bugfixy/operations (sprint planning rozpada się)
- Zespół po 2-3 latach Scrum chce eliminate “sprint commitment stress”
- Mix product development + maintenance
- DevOps teams
Trend 2026
45% zespołów Scrum dodaje elementy Kanban po 2-3 latach (State of Agile 2026). Najpopularniejsza adopcja:
- WIP limits dla “In Progress” kolumny
- Cycle time tracking
- Cumulative Flow Diagram zamiast Burndown
Decision Matrix — Co wybrać?
Path 1: Scrum (default dla nowych zespołów)
Wybierz Scrum jeśli:
- Greenfield product development
- Junior team needing structure
- Stakeholders dostępni dla feedback co 2-4 tyg.
- Definiowany Product Vision i Roadmap
- Team size 3-9 osób
Time investment:
- 2-week sprints, 5 events, ~20% time on meetings
- Setup: 2-4 tyg. (training + 1-2 sprintów do flow)
- Certyfikacje: PSM I (USD 200), CSM (USD 1000)
Path 2: Kanban (operations choice)
Wybierz Kanban jeśli:
- Operations, support, maintenance work
- Praca napływa nieprzewidywalnie
- Zespół już ma istniejący workflow
- Nie potrzeba formal commitments
- Service Level Agreements (SLA) requirements
Time investment:
- Brak fixed iterations
- Setup: 1-3 dni (board + WIP limits)
- Certyfikacje: Kanban Foundation (USD 600), KMP I/II (USD 1500-3000)
Path 3: Scrumban (mature teams)
Wybierz Scrumban jeśli:
- Po 2-3 latach Scrum
- Mix product development + operations
- 30%+ pracy nieplanowane
- Team chce reduce sprint stress
Sequence:
- Start z czystym Scrum (rok 1-2)
- Identyfikuj problemy (operations dispute, sprint commitment stress)
- Dodaj WIP limits per kolumna (rok 2)
- Dodaj cycle time metrics (rok 2-3)
- Eliminate sprint planning (zachowaj Daily, Retrospective)
Kontekst polski 2026 — Kto używa czego
Branżowe preferencje
| Branża | Dominant framework |
|---|---|
| Banking/Fintech | Scrum (regulated, sprint demos for compliance) |
| Big Tech | Scrum + Scrumban (large teams, multiple products) |
| DevOps/SRE | Kanban (operations + incidents) |
| Software Houses | Scrum (project-based work) |
| Internal IT | Scrumban (mix of projects + maintenance) |
| Marketing teams | Kanban (continuous content) |
| Consulting (Big4) | Scrum (client-facing projects) |
Wynagrodzenia 2026 (PL)
| Rola | Lön (zł netto B2B/mc) |
|---|---|
| Junior Scrum Master | 12-18k |
| Mid Scrum Master | 18-25k |
| Senior Scrum Master | 25-35k |
| Agile Coach | 30-50k |
| Kanban Coach | 28-45k |
| RTE (Release Train Engineer, SAFe) | 35-55k |
Premium za certyfikacje:
- PSM I/CSM (entry): +5-8% nad bazą
- PSM II/CSM Advanced: +10-15%
- PSM III/CST/CSP: +20-30%
- Kanban KMP I/II: +8-12%
- SAFe SPC: +25-35%
Najczęstsze mity o Scrum i Kanban
❌ Mit 1: “Scrum to mini-waterfall” ✅ Reality: Scrum embraces change w/in sprintu (z negotiation), waterfall freezes scope
❌ Mit 2: “Kanban nie ma planning” ✅ Reality: Kanban ma replenishment meetings (planning) + service delivery review (review)
❌ Mit 3: “Scrum Master = Project Manager” ✅ Reality: SM jest servant leader, NIE PM. PO odpowiada za “co”, Devs za “jak”. SM facilitates.
❌ Mit 4: “WIP limits są ograniczające” ✅ Reality: WIP limits zwiększają throughput o 30-50% (mniej context switching)
❌ Mit 5: “Po Scrum/Kanban już nic nowego do nauki” ✅ Reality: SAFe, LeSS, DA, Spotify Model — scaling frameworks dla organizacji 100+ osób
Co dalej? Path Forward
Beginner → Scrum (PSM I)
EITT trainings:
- Professional Scrum Master I (PSM I)
- Cost: 3500 zł, czas trwania: 2 dni
- Egzamin: 80 pytań, 60 min, 85% pass rate
Mid → Kanban (KMP I)
EITT trainings:
- Kanban Foundation z egzaminem
- Cost: 4500 zł, czas trwania: 3 dni
Senior → SAFe Agilist or Agile Coach
- SAFe Agilist (USD 1000) — dla enterprise scale
- ICP-ACC (USD 2000) — dla Agile Coach role
- Plus advanced Scrum/Kanban (PSM II, KMP II)
Podsumowanie
Scrum = iteracyjny + inkrementalny + 3 role + 5 eventów, 70% Agile teams, idealne dla product development Kanban = continuous flow + WIP limits + brak ról, 25% teams, idealne dla operations Scrumban = hybrid, 45% Scrum teams adoptuje po 2-3 latach
W 2026 smart strategia to start z Scrum (jasne ramy, formal training), gdy zespół dojrzewa rozważyć Scrumban (eliminate sprint stress), a dla operations/support zacząć od Kanban. Najważniejsze: framework to NARZĘDZIE, nie cel — focus on outcomes (delivery + customer value), nie process compliance.
Szukasz pomocy w wyborze frameworka dla swojego zespołu? Skontaktuj się z EITT — pomożemy zaprojektować Agile transformation dostosowaną do specyfiki Twojej organizacji.