Kanban vagy Scrum? Melyiket válasszam?
A Kanban kevésbé széleskörűen ismert módszertan, mint a Scrum, és sokan annak alternatívájaként emlegetik. Valójában van a két keretrendszer felhasználási területének egy jelentős közös halmaza, de jellemzőikben alapvetően eltérnek, ezért érdemes áttekinteni, mi alapján válasszunk.
Természetesen az alapelvünk most is az, mint mindig: az agilitás. A Scrum, a Kanban nem vallások. Tehát kerüljük a hitvitákat, inkább tekintsünk rájuk eszközként és úgy keressük meg a helyüket a világban.
A Kanban vonzereje és csapdái
A Kanban legnagyobb vonzereje az egyszerűségében rejlik. Mindösszesen 3+1 szabálya van:
1. Vizualizáld a workflow-t
2. Korlátozd a párhuzamosan folyamatban lévő feladatok számát (Work-In-Progress (WIP) limit)
3. Legyen minden résztvevő fő célja segíteni a feladatok áramlását a folyamatban.
+1: A feladatok ‘Pull’, azaz magunkra húzással történő feladatvállalással, nem pedig az elterjedt ‘Push’, azaz feladatkiosztással, rárakással történik.
Ennyi az egész. Látszólag triviális, és pont ezért kockázatos. A fő kockázatai:
• Könnyen lehet Kanbannak látszó módszertant összerakni. Ez főleg azoknál a szervezeteknél gyakori, ahol csak szóban cél az agilitás, de a valódi változásra nincs hajlandóság. A probléma természetesen az, hogy eredményt így mérsékelten hoz, cserébe viszont lejáratódik a keretrendszer. Ez nem csak a Kanban jellemzője: Igaz a Scrumra is, és minden átfogó módszertanra.
• Rugalmas keretrendszer, a sikerhez azonban önfegyelemre van szükség. Azok a szervezetek, amelyeknél pont a megengedőség az érv a Kanban mellett, vélhetően nem rendelkeznek a szükséges önfegyelemmel, és a szabályokat már a kezdetektől megszegik.
Mikor használjunk Kanbant?
Ez utóbbi miatt mondják tapasztalt tanácsadók, hogy termékfejlesztésben Kanbant csak akkor használjunk, ha a Scrum már nagyon jól működik. Ha a szervezet egy viszonylag szigorú módszertan játékszabályait már képes betartani, akkor lehet érdemes egy rugalmasabb irányba elindulni.
Mi egy másik helyzetben is alkalmazzuk a Kanbant: ha a Scrum feltételei nem adottak, és a megfelelő támogatás kialakításához szükség van az akadályok tiszta, egyértelmű felfedésére. Például ahhoz, hogy egy Scrum folyamat során minden sprint végén valóban kiadható működő termék inkrementumot tudjon szállítani a csapat, elengedhetetlen, hogy a tesztelés a csapaton belül történjen.
Találkoztunk olyan csapattal, akik bár nagyon szerettek volna scrumozni, tesztelői kompetencia és infrastruktúra nélkül dolgoztak; úgy, hogy míg egy-egy feature átlagos fejlesztési ideje 4-5 nap volt, a cég közös tesztelői poolja által végzett tesztelés 60-90 napig is elhúzódhatott. Természetesen így a Scrum nem opció, viszont egy tiszta, jól beállított Kanban folyamat nagyon szépen ki tudja hozni ezeket a szűk keresztmetszeteket és élesen rá tud mutatni a problémára.
A fentiek mellett azonban fontos kiemelni, hogy a Kanban sokkal több, mint a Scrum esetleges alternatívája a termékfejlesztésben; egy önálló és hatékony módszer, aminek bevezetése azonban komoly előkészítést kíván. Sok területen használható, az IT-n belül gyakorta alkalmazzák például maintenance/support jellegű feladatok során; IT-től függetlenül HR-folyamatokra, döntési folyamattámogatásra, értékesítésre is használják. Tulajdonképpen a módszer üzleti területtől függetlenül bárhol felhasználható (mint az egyik kedvenc szimulációs gyakorlatunk bizonyítja, akár egy pizzériában is); ahol folyamat van, ott egy jól bejáratott Kanban sokat segíthet a folyamat javításában.
Érdemes Scrumról Kanbanra váltani?
Összefoglalva tehát, éretlen szervezetnél a Kanban jó választás lehet a “bottleneck”-ek, szűk keresztmetszetek felfedezésére.
Ezután, ha a feltételek adottak, amíg kialakul a szervezetben a megfelelő érettség és fegyelem, inkább Scrumot javaslunk. Ha ez már jól megy, akkor el lehet gondolkodni a Kanbanra váltáson, ha egyáltalán szükség van rá, például mert túl feszesnek érezzük a befagyasztott iteráció okozta megkötéseket, és az üzleti környezet olyan fokú változékonyságot igényel, ahol akár egy két hétre előre tervezés is túl erős kényszer.
Természetesen ez a recept csak irányelv, minden esetben a konkrét szituáció, körülmények, feltételek stb. figyelembevételével érdemes dönteni, akár agilis coaching segítségével is.
Szeretnél többet megtudni a két keretrendszerről? Scrum és Kanban tréningjeink segítenek Neked!