Az előző cikkben azt boncolgattam, hogy 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?
Mert az a tapasztalatom, hogy a két módszertant sokan összekeverik, sokan felváltva használják, és kevesen gondolják végig hogy melyik mire való.
A lényeg egyetlen mondatban
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 áramolnak át a rendszeren.
Ez a különbség első ránézésre technikai. Valójában szervezeti és üzleti következményei vannak.
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 - ahol az igények iteratív visszajelzés alapján finomíthatók, és ahol 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 cross-functional csapatot feltételez — fejlesztő, tesztelő, BA egy csapatban, dedikáltan a projekthez. Ha a csapat tagjai több projekten dolgoznak párhuzamosan és folyamatosan változnak, a Scrum overhead-je 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 kaphat visszajelzést. Ha az igény előre teljesen definiált és nem változhat — például egy szabályozói megfelelési projekt — a Scrum ceremóniái feleslegesek.
Döntéshozatali jogkör. A product owner tud dönteni arról, hogy mi kerül a következő sprintbe. Ha minden döntés egy bizottságon vagy jóváhagyási folyamaton megy keresztül, a sprint planning formális aktussá válik.
Mikor való a Kanban?
A Kanban akkor működik jól, ha a munka folyamatos és változó ütemű — ahol nincs jól definiált "projekt vége", hanem folyamatosan érkeznek feladatok, amelyeket prioritás szerint kell feldolgozni.
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, különböző prioritással, különböző komplexitással. A Kanban tábla vizuálisan mutatja mi van folyamatban, mi vár, mi kész — és a WIP limit megakadályozza, hogy a csapat egyszerre túl sok feladatba merüljön.
Legacy rendszer karbantartás. Egy biztosítói core rendszer karbantartásánál nincs "sprint" — van folyamatos változáskezelés, amelyet dokumentálni, priorizálni és végrehajtani kell. A Kanban erre tökéletes: látható a folyamat, látható az átfutási idő, látható a szűk keresztmetszet.
BA és SA csapat munkaszervezése. Az üzleti elemzők és solution architectek munkája nem sprintelhető — egyszerre több projekten dolgoznak, különböző fázisokban. A Kanban tábla láthatóvá teszi ki mivel foglalkozik és mi 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 Scrumba szervezett , sprintek, daily standupok, retrospective-ek. Az üzemeltetési csapat mellette 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.
Ahol problémát láttam: amikor a két csapat munkája összeért. A fejlesztés sprintenként szállított egy új funkciót — az üzemeltetésnek azonnal integrálni kellett a folyamatos rendszerükbe. Ez az átadási pont volt a feszültség forrása — és ezt sem Scrum, sem Kanban nem oldja meg önmagában. Ezt szervezeti megállapodással kell kezelni.
A harmadik út: hibrid megközelítés
A Kanban és Scrum közti választás függ attól is, hogy a szervezet mennyire kész átállni az új szemléletmódra — de valójában nem mindig kell választani. A két módszertan kombinálható.
A gyakorlatban ezt látom pénzügyi szektorbeli szervezeteknél működni:
Scrum a fejlesztési csapatnál — új funkciók, projektek, greenfield fejlesztések.
Kanban az üzemeltetésnél és 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ó.
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ó értéket.
Mikor egyik sem?
Vannak helyzetek ahol 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 projekt-alapú megközelítés (milestone-ok, Gantt-terv, change management) egyszerűbb és átláthatóbb. A Scrum overhead-je nem térül meg, a Kanban vizualitása nem ad hozzá értéket.
Nagyon rövid projektek. Egy 4-6 hetes fejlesztés esetén a Scrum ceremóniák felállítása aránytalanul sok időt vesz el a tényleges munkából. Ilyenkor egy egyszerű feladatlista prioritás sorrendben hatékonyabb.
Szervezetileg éretlen környezet. Ha a szervezet nem kész az önszerveződő csapatok koncepcióját befogadni — sem Scrum, sem Kanban nem működik. Először a szervezeti feltételeket kell megteremteni.
A döntési keretrendszer
Négy kérdés amely segít eldönteni melyik módszertan illik a projekthez:
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 projekt-alapú a munka? Folyamatos → Kanban. Projekt-alapú, definiált végponttal → Scrum vagy klasszikus projekt.
Dedikált, stabil csapat áll rendelkezésre? Ha igen → Scrum működhet. Ha nem → Kanban rugalmasabb.
Milyen a döntéshozatal sebessége? Gyors, autonóm → Scrum. Lassú, jóváhagyás-alapú → Kanban vagy hibrid.
Mit csinálunk a FrontX-nél
A FrontX projektek 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.
Ongoing support és BA munka szervezésénél Kanban-szemléletű feladatkezelést alkalmazunk — vizuális áttekinthetőség, WIP tudatosság, folyamatos prioritizálás.
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 projekteden dolgozol ahol a módszertan kérdése megoldatlan — szívesen konzultálunk: frontx.hu/kapcsolat
Gyakran ismételt kérdések
Mi a különbség a Kanban és a Scrum között? A Scrum iterációkban — sprintekben — teremt értéket: fix időkeretű ciklusokban szállít működő termékinkrementumokat, új szerepköröket (Scrum Master, Product Owner) és ceremóniákat (daily standup, sprint planning, retrospective) vezet be. A Kanban folyamatos áramlásban teremt értéket: nincs sprint, nincs fix időkeret, a feladatok folyamatosan áramolnak át a rendszeren, a WIP (Work In Progress) limitek akadályozzák a túlterhelést.
Mikor érdemes Scrumot használni IT projekteknél? A Scrum akkor megfelelő, 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 visszajelzést adni sprintenként, é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? A Kanban akkor megfelelő, ha a munka folyamatos és változó ütemű — IT üzemeltetés, support, legacy rendszer karbantartás, BA és SA csapat munkaszervezése. Kanban akkor is jobb választás, ha a csapat tagjai több projekten dolgoznak párhuzamosan, vagy ha a szervezet nem áll készen a Scrum által megkövetelt strukturális változásokra.
Kombinálható-e a Kanban és a Scrum ugyanazon szervezeten belül? Igen — és pénzügyi szektorbeli szervezeteknél ez a leggyakoribb és legpraktikusabb megközelítés. Fejlesztési csapat Scrummal, üzemeltetési és support csapat Kanbannal, BA/SA csapat Kanbannal. A két módszertan nem zárja ki egymást — a szervezet különböző részei különböző igényekkel rendelkeznek.
Van-e olyan helyzet amikor sem Scrum, sem Kanban nem a legjobb választás?Igen. Egyszeri, jól definiált projekteknél fix határidővel és scope-pal — különösen szabályozói megfelelési projekteknél — a klasszikus projekt-alapú megközelítés egyszerűbb és átláthatóbb. Nagyon rövid projekteknél a módszertani overhead nem térül meg. Szervezetileg éretlen környezetben egyik módszertan sem működik — először a szervezeti feltételeket kell megteremteni.
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.
