Kanban vagy Scrum?

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:

  1. Vizualizáld a workflow-t
  2. Korlátozd a párhuzamosan folyamatban lévő feladatok számát
  3. 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:

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.