A Scrum és a Kanban nem egymás versenytársai, hanem két különböző munkatípusra kitalált eszköz. A Scrum iterációkban szállít, a Kanban folyamatos áramlásban. A rossz választás nem a módszertan hibája: a munka természete és a szervezet adottságai döntik el, melyik működik.
Az előző cikkben azt boncolgattam, kell-e egyáltalán Scrum Master egy pénzügyi szektorbeli IT projektbe. A válaszom: feltételektől függ, és a feltételek pénzügyi szektorbeli nagyvállalatoknál ritkán teljesülnek. Most egy lépéssel hátrébb lépek: mikor Scrum, mikor Kanban, és mikor egyik sem? Az a tapasztalatom, hogy a két agilis módszertant sokan összekeverik vagy felváltva használják, és kevesen gondolják végig, melyik mire való.
Röviden
- A Scrum új termék vagy funkció iteratív építésére való: legfeljebb egyhónapos sprintek, dedikált csapat, gyors döntéshozatal.
- A Kanban folyamatosan érkező, változó ütemű munkára való: üzemeltetés, support, legacy karbantartás, BA/SA csapatok.
- Pénzügyi szektorbeli szervezeteknél a leggyakrabban a kettő kombinációja működik: fejlesztés Scrummal, üzemeltetés és elemzés Kanbannal.
- Fix scope-ú, fix határidős (például szabályozói) projektnél sokszor a klasszikus projektmódszer az egyszerűbb.
Mi a különbség a Scrum és a Kanban között?
A Scrum iterációkban teremt értéket: sprintenként szállít egy működő termékinkrementumot. A Kanban folyamatos áramlásban teremt értéket: nincs sprint, nincs fix időkeret, a feladatok folyamatosan haladnak át a rendszeren. Ez első ránézésre technikai különbség. Valójában szervezeti és üzleti következményei vannak.
| Szempont | Scrum | Kanban |
|---|---|---|
| Ritmus | Fix hosszú sprintek, legfeljebb 1 hónap | Folyamatos áramlás, nincs kötelező iteráció |
| Szerepek | Product Owner, Scrum Master, fejlesztők | Nincs előírt szerepkör |
| Események | Sprint planning, daily scrum, sprint review, retrospektív | Nincs kötelező esemény, a folyamat javítása folyamatos |
| Változás menet közben | A sprint céljához igazodva | Bármikor, a prioritási sor szerint |
| Fő mérőszámok | Sprintcél teljesülése, inkrementum | WIP, áteresztőképesség, átfutási idő, feladat kora |
| Tipikus terület | Új termék, új funkciók, greenfield fejlesztés | Üzemeltetés, support, karbantartás, elemzés |
Mikor való a Scrum?
A Scrum akkor működik jól, ha a projekt célja egy új termék vagy funkció felépítése: az igények iteratív visszajelzés alapján finomíthatók, és a csapat sprintenként szállítani tud valamit, ami valódi értéket ad. Három feltétel, ami nélkül a Scrum nem működik:
Stabil csapat. A Scrum Guide szerint a csapat cross-functional és jellemzően legfeljebb 10 fős: fejlesztő, tesztelő, BA egy csapatban, dedikáltan a termékhez. Ha a tagok több projekten dolgoznak párhuzamosan, és a csapat összetétele folyamatosan változik, a Scrum ráfordítása nem térül meg.
Iterálható igény. A Scrum akkor ad értéket, ha a product owner tud prioritizálni, és a csapat sprintenként visszajelzést kaphat. Ha az igény előre teljesen definiált és nem változhat, például egy szabályozói megfelelési projektnél, a Scrum eseményei feleslegesek.
Döntéshozatali jogkör. A product owner maga dönt arról, mi kerül a következő sprintbe. Ha minden döntés bizottságon vagy jóváhagyási folyamaton megy keresztül, a sprint planning formális aktussá válik. (Erről bővebben: BA vagy Product Owner?)
Mennyibe kerül a Scrum? A Scrum Guide egyhónapos sprintre legfeljebb 8 óra sprint planninget, 4 óra review-t, 3 óra retrospektívet és napi 15 perces daily scrumot ír elő, rövidebb sprintnél arányosan kevesebbet. Kéthetes sprintnél ez felső becslésként fejenként kb. 10 óra, vagyis a munkaidő nagyjából 12 százaléka. Jól működő csapatnál ez megtérül, félig működő Scrumnál tiszta veszteség.
Mikor való a Kanban?
A Kanban akkor működik jól, ha a munka folyamatos és változó ütemű: nincs jól definiált „projekt vége”, hanem folyamatosan érkeznek feladatok, amelyeket prioritás szerint kell feldolgozni. A Kanban Guide szerint a módszer három gyakorlatra épül: a munkafolyamat definiálása és vizualizálása, a folyamatban lévő feladatok aktív kezelése, és a folyamat folyamatos javítása. Három tipikus Kanban-területet látok pénzügyi szektorbeli szervezeteknél:
IT üzemeltetés és support. Hibabejelentések, változáskérelmek, kisebb fejlesztési igények: ezek nem sprintelhetők. Folyamatosan érkeznek, eltérő prioritással és komplexitással. A Kanban tábla megmutatja, mi van folyamatban, mi vár és mi kész, a WIP-limit (a párhuzamosan futó feladatok felső korlátja) pedig megakadályozza, hogy a csapat egyszerre túl sok feladatba kezdjen.
Legacy rendszer karbantartása. Egy biztosítói core rendszer karbantartásánál nincs „sprint”, hanem folyamatos változáskezelés van, amelyet dokumentálni, priorizálni és végrehajtani kell. A Kanban erre kiváló: látható a folyamat, az átfutási idő és a szűk keresztmetszet.
BA és SA csapat munkaszervezése. Az üzleti elemzők és a solution architectek egyszerre több projekten dolgoznak, különböző fázisokban, ezért az ő munkájuk nem sprintelhető. A Kanban tábla láthatóvá teszi, ki mivel foglalkozik, és hol van az áteresztőképesség korlátja.
A pénzügyi szektorbeli tapasztalat
Egy nagyvállalati biztosítónál dolgoztam, ahol a fejlesztési csapat Scrumban dolgozott: sprintek, daily standupok, retrospektívek. Mellette az üzemeltetési csapat Kanbant használt: folyamatos feladatáramlás, vizuális tábla, WIP-limitek.
Ez a kettős struktúra működött, de nem véletlenül. Tudatos döntés volt: a fejlesztés iteratív, az üzemeltetés folyamatos. Nem próbálták az üzemeltetést sprintelni, és nem próbálták a fejlesztést Kanbanba kényszeríteni.
A problémát ott láttam, ahol a két csapat munkája összeért. A fejlesztés sprintenként szállított egy új funkciót, az üzemeltetésnek pedig azonnal be kellett illesztenie a saját folyamatos rendszerébe. Ez az átadási pont volt a feszültség forrása, és ezt sem a Scrum, sem a Kanban nem oldja meg önmagában. Ezt szervezeti megállapodással kell kezelni: közös „kész” definícióval, előre egyeztetett élesítési ablakokkal és az üzemeltetés bevonásával már a sprint review-ba.
A harmadik út: hibrid megközelítés (Scrumban)
Nem mindig kell választani, a két módszertan kombinálható. A Scrum.org ki is adott egy útmutatót arról, hogyan használhatnak a Scrum csapatok Kanban-gyakorlatokat (Kanban Guide for Scrum Teams). A köznyelv ezt sokszor Scrumbannek hívja. A gyakorlatban ezt látom működni pénzügyi szektorbeli szervezeteknél:
- Scrum a fejlesztési csapatnál: új funkciók, projektek, greenfield fejlesztések.
- Kanban az üzemeltetésnél és a supportnál: folyamatos változáskezelés, hibajavítás, karbantartás.
- Kanban a BA és SA csapatnál: párhuzamos projektek, igényfeltárás, specifikáció.
- Kanban-tábla a Scrum csapaton belül: a sprinten belüli munka áramlásának és elakadásainak láthatóvá tételére.
Ez nem elméleti konstrukció, hanem az a megközelítés, amely a legkevesebb szervezeti ellenállással bevezethető, és a leggyorsabban hoz látható eredményt.
Mikor egyik sem?
Vannak helyzetek, amikor sem a Scrum, sem a Kanban nem az elsődleges válasz.
Egyszeri, jól definiált projektek. Ha egy szabályozói megfelelési projektet kell leszállítani fix határidőre, fix scope-pal, a klasszikus projektalapú megközelítés (mérföldkövek, Gantt-terv, változáskezelés) egyszerűbb és átláthatóbb. A Scrum ráfordítása nem térül meg, a Kanban vizualitása pedig keveset tesz hozzá. Ha mégis menet közben bővül a scope, az már scope creep, és külön kezelni kell.
Nagyon rövid projektek. Egy 4-6 hetes fejlesztésnél a Scrum keretek felállítása aránytalanul sok időt vesz el a tényleges munkából. Ilyenkor egy prioritás szerint rendezett feladatlista hatékonyabb.
Szervezetileg éretlen környezet. Ha a szervezet nem kész az önszerveződő csapatok és a delegált döntési jogkör befogadására, a Scrum nem fog működni, csak a formája marad meg. Itt a Kanban jobb kiindulópont, mert nem ír elő új szerepeket: a meglévő folyamatot teszi láthatóvá, és lépésenként javítja. A Scrumra csak akkor érdemes átállni, ha a szervezeti feltételek megvannak.
Ellenőrzőlista: négy kérdés a módszertan kiválasztása előtt
- Van-e iterálható, visszajelzés alapján finomítható igény? Ha igen, Scrum irány. Ha nem, Kanban vagy klasszikus projekt.
- Folyamatos vagy projektalapú a munka? Folyamatos: Kanban. Projektalapú, definiált végponttal: Scrum vagy klasszikus projekt.
- Van-e dedikált, stabil csapat? Ha igen, a Scrum működhet. Ha nem, a Kanban rugalmasabb.
- Milyen gyors a döntéshozatal? Gyors, autonóm: Scrum. Lassú, jóváhagyásalapú: Kanban vagy hibrid.
Amit a FrontX-nél másképp csinálunk
- A projektjeink nem kötődnek egyetlen módszertanhoz: az igény és a szervezeti kontextus határozza meg az eszközt, nem fordítva.
- Fejlesztési projekteken iteratív megközelítéssel dolgozunk: moduláris szállítással, heti státuszkommunikációval, folyamatos prioritizálással. Ez közelebb áll a Scrum szemléletéhez, de nem Scrum-ceremóniákkal.
- Folyamatos support és üzleti elemzés esetén Kanban-szemléletű feladatkezelést alkalmazunk: vizuális áttekinthetőség, WIP-tudatosság, folyamatos prioritizálás.
- Ha csapatkiterjesztésben csatlakozunk egy ügyfél csapatához, az ügyfél módszertanában dolgozunk, legyen az Scrum, Kanban vagy klasszikus projekt.
A módszertan eszköz. A cél: szállítani, amit ígértünk, határidőre, az ügyfél számára érthetően.
Ha olyan projekten dolgozol, ahol a módszertan kérdése még nyitott, szívesen segítünk végiggondolni: kérj ingyenes konzultációt.
Gyakran ismételt kérdések
Mi a különbség a Kanban és a Scrum között?
A Scrum fix időkeretű sprintekben, legfeljebb egyhónapos ciklusokban szállít működő termékinkrementumot, meghatározott szerepekkel (Product Owner, Scrum Master, fejlesztők) és eseményekkel (sprint planning, daily scrum, review, retrospektív). A Kanban folyamatos áramlásban dolgozik: nincs sprint és nincs előírt szerepkör, a túlterhelést WIP-limitek akadályozzák meg, a teljesítményt pedig az átfutási idő és az áteresztőképesség mutatja.
Mikor érdemes Scrumot használni IT projektekben?
Ha a fejlesztés célja egy új termék vagy funkció iteratív felépítése, a csapat dedikált és cross-functional, a product owner tud priorizálni és sprintenként visszajelzést adni, és a döntéshozatal elég gyors ahhoz, hogy a sprint ne akadjon el. Pénzügyi szektorbeli nagyvállalatoknál ez a feltételrendszer ritkán teljesül maradéktalanul.
Mikor érdemes Kanbant használni?
Ha a munka folyamatos és változó ütemű: IT üzemeltetés, support, legacy rendszer karbantartása, BA és SA csapatok munkaszervezése. A Kanban akkor is jobb választás, ha a csapat tagjai több projekten dolgoznak párhuzamosan, vagy ha a szervezet még nem áll készen a Scrum által megkövetelt szervezeti változásokra.
Kombinálható a Kanban és a Scrum ugyanazon a szervezeten belül?
Igen, és pénzügyi szektorbeli szervezeteknél ez a leggyakoribb és legpraktikusabb megközelítés: a fejlesztési csapat Scrummal, az üzemeltetés, a support és a BA/SA csapat Kanbannal dolgozik. Egy Scrum csapat a sprinten belül is használhat Kanban-táblát és WIP-limiteket. A kritikus pont a csapatok közötti átadás, ezt közös szabályokkal kell rendezni.
Mikor nem jó választás sem a Scrum, sem a Kanban?
Egyszeri, jól definiált, fix határidős és fix scope-ú projekteknél, különösen szabályozói megfelelési projekteknél, a klasszikus projektalapú megközelítés egyszerűbb és átláthatóbb. Nagyon rövid, néhány hetes projekteknél a módszertani ráfordítás nem térül meg.
Behán László a FrontX Kft. ügyvezetője és társalapítója. Korábban a Signal Biztosító CIO-ja, a Groupama Biztosító fejlesztési és adattárház-vezetője, valamint a LeasePlan Hungaria igazgatóságának tagja volt operációs igazgatóként. 25 év IT és üzleti vezetői tapasztalattal rendelkezik a pénzügyi szektorban. LinkedIn-profil
