A Kanban ismert módszertan, sokan a Scrum alternatívájaként is emlegetik. Valóban van a két módszertan felhasználási területének egy jelentős közös halmaza, 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 legnagyobb vonzereje - sajnos - az egyszerűségében rejlik. Mindösszesen három szabálya van:
- Vizualizáld a workflow-t
- Korlátozd a párhuzamosan folyamatban lévő feladatok számát
- Legyen minden résztvevő fő célja segíteni a feladatok áramlását a folyamatban.
Ennyi az egész. Látszólag triviális, és pont ezért nagyon veszélyes. 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 nem hoz, cserébe viszont lejáratja a módszertant.
- Mivel nagyon megengedő módszertan, a sikerhez hatalmas önfegyelemre van szükség. Azok a szervezetek, amelyeknél pont a megengedőség az érv a Kanban mellett, egyértelműen nem rendelkeznek a szükséges önfegyelemmel, így a kimondatlan szabályokat már rögtön a kezdetektől megszegik, és idővel a három alapszabály is sérül.
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 “potentially shippable product increment”-et 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 az adatokat és élesen rá tud mutatni a problémára.
Összefoglalva tehát, éretlen szervezetnél a Kanban jó választás lehet a “bottleneck”-ek, szűk keresztmetszetek felfedezésére. Önmagában javulást nem fog hozni, csak rámutat a problémás részekre.
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 nagyon 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.
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ódszertan, 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ódszertan ü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.
