Miért működik a Kanban — és honnan tudod, hogy a csapatod készen áll rá

A legtöbb csapat azért vezeti be a Kanbant, mert valaki elolvasott egy blogbejegyzést. Az okosabb kérdés az, hogy a Kanban által megoldott problémák valóban a csapatod problémái-e.

Van egy pillanat, amelyet a legtöbb csapat felismer, általában akkor, amikor nyolcnál vagy kilencnél több emberből áll. A munka halad — elmennek az e-mailek, élesednek a funkciók, kezelik az ügyfeleket —, de senkinek sincs világos képe arról, mit csinál a többi ember. A projektek halmozódnak. Dolgokat ígérnek meg, aztán csendben elfelejtik őket. Minden megbeszélés előtt húsz percet töltesz azzal, hogy kiderítsd, valójában hol tart egy munka. A válasz általában az, hogy „valahol”.

Pontosan ezt a problémát hivatott megoldani a Kanban. Nem a stratégiaalkotás, a megfelelő emberek felvétele vagy a kultúraépítés problémáját, hanem azt a konkrét, őrlő, működési problémát, hogy tudd, min dolgozik a csapatod, és mi akadályozza.

Meglepően szerény eszköz ahhoz képest, mennyi figyelmet kapott. A Kanban nem állítja, hogy rendbe hozza a szervezetedet. Csak láthatóvá teszi a munkát. Kiderül, hogy a láthatóság, ha következetesen alkalmazzák, rengeteg mindent megváltoztat.

Honnan ered valójában a Kanban

A szó japán — „cégtáblát” vagy „hirdetőtáblát” jelent —, a rendszert pedig a Toyota fejlesztette ki az 1940-es évek végén, hogy a gyártóüzemekben a készleteket kezelje. Az ötlet egyszerű volt: ahelyett, hogy az alkatrészeket rögzített ütemterv szerint gyártanák, a gyár csak akkor gyártotta őket, amikor egy későbbi munkaállomás jelezte, hogy szüksége van rájuk. Egy fizikai kártya — a kanban — kérésként visszautazott a gyártósoron. Semmi sem készült találgatásra. Semmi sem halmozódott fel feleslegesen.

A Toyota felismerése, amelyet később a szoftveres csapatok is átvettek, az, hogy a rendszerek hatékonysági veszteségének nagy része nem abból ered, hogy az emberek túl lassan dolgoznak, hanem abból, hogy rossz munkát végeznek rossz időben. Túl sok dolog indul egyszerre. A szűk keresztmetszeteket senki sem veszi észre, amíg túl késő nem lesz. A munka az egyik helyen befejezve hever, miközben a következő lépés valahol máshol túlterhelt.

A szoftverfejlesztők, különösen az olyan cégeknél, mint a Microsoft a 2000-es évek elején, elkezdték ezeket az ötleteket a tudásmunkára alkalmazni. A kártyákból feladatok lettek. A gyári munkaállomásokból a munkafolyamat szakaszai. A jelzőtáblából pedig tábla — eleinte fizikai, később digitális —, ahol a csapat bármely tagja egy pillantással láthatta, mi van folyamatban, mi vár, és mi készült el.

Mit mutat valójában egy Kanban-tábla

Az alap Kanban-táblának három oszlopa van: Teendő, Folyamatban, Kész. Ez sok kis csapatnak elég, és jó kiindulópont. Az igazi érték viszont akkor jelenik meg, amikor elkezded testre szabni ezeket a szakaszokat, hogy illeszkedjenek ahhoz, ahogyan a munka valójában halad — nem ahhoz, ahogyan szeretnéd, hogy haladjon.

Egy tartalomcsapat használhatja ezeket: Ötlet, Brief, Vázlat, Átnézés, Ütemezve, Publikálva. Egy szoftveres csapat a „Folyamatban” oszlopot felbonthatja külön oszlopokra a fejlesztésnek, a kódátvizsgálásnak és a QA-nak. Egy tanácsadó csapat követheti a feltárást, az ajánlatot, az aktív munkát, az ügyfélre várakozást és a lezárást. A szakaszoknak valós átadásokat és valós várakozási időket kell tükrözniük — azokat a pontokat, ahol a munka gazdát cserél, vagy ahol addig áll, amíg valami más meg nem történik.

Figyeld meg a középső oszlopban lévő kártyát — a raktári auditjelentést, amely nyolc napja blokkoltként van megjelölve. Tábla nélküli rendszerben ez a feladat akár még két hétig is állhatna, mielőtt bárki rájönne, hogy nem halad. Valaki egy harmadik félre vár. Vagy egy olyan vezető döntésére van szükség, aki nem tudja, hogy ő a blokkoló tényező. A tábla láthatóvá teszi az elakadást. A munka nagy része ennyi.

A szabály, amitől működik: a WIP-limitek

Ha van egy fogalom, amely elválasztja a Kanbant helyesen használó csapatokat azoktól, amelyeknek csak egy szebb teendőlistájuk van, az a folyamatban lévő munka korlátozása — röviden WIP-limit. Az ötlet az, hogy minden oszlopban egyszerre legfeljebb meghatározott számú tétel lehet. Ha egy oszlop megtelt, nem adhatsz hozzá újabb munkát, amíg valami ki nem kerül belőle.

Ez ellentmond az intuíciónak. Hiszen ha több feladat lehet folyamatban, az azt jelenti, hogy több készül el, nem? Nem. Ha az emberek egyszerre túl sok dolgon dolgoznak, valójában az történik, hogy minden tovább tart. A kontextusváltás drága. A félig kész munka koordinációs többletterhet okoz. És amikor tíz dolog van „folyamatban”, nagyon nehéz megmondani, melyek haladnak valóban, és melyek akadtak el csak úgy, hogy senki sem jelezte.

A háromra állított WIP-limit a „Folyamatban” oszlopban azt jelenti, hogy amikor a negyedik tétel megérkezik valakihez, a csapatnak döntenie kell: melyik meglévő feladat fejeződjön be előbb? Ez prioritásokat kényszerít ki. Beszélgetésre kényszerít. És általában az egyes tételek gyorsabb befejezését eredményezi, még akkor is, ha az új tételek indításának üteme lassul.

Kanban és Scrum: a kérdés, amelyet a csapatok mindig feltesznek

Ha foglalkoztál valaha szoftveres csapatokkal vagy a modern üzemeltetési szemlélettel, valószínűleg találkoztál a Scrummal — azzal a keretrendszerrel, amely a munkát rögzített, kéthetes sprintekbe szervezi, tervezési üléssel, retrospektívekkel és meghatározott szerepekkel, például Scrum Masterrel és Product Ownerrel. Sok csapat a Scrumot és a Kanbant egymással versengő módszertanként kezeli, és úgy érzi, választania kell. A különbség valójában egyszerűbb ennél.

Sok csapat — különösen azok, amelyek nem tisztán szoftverfejlesztő csapatok — nehézkesnek találja a Scrum szertartásosságát, a rögzített sprintszerkezetet pedig kényelmetlennek a folyamatos operatív munkához. A marketingcsapatoknak, az ügyfélsikercsapatoknak, az operációs csapatoknak és a mindent egyszerre vezető alapítóknak ritkán van olyan munkájuk, amely szépen beleillik a kéthetes ciklusokba. A Kanban folyamatos áramlási modellje általában jobban illik hozzájuk.

Ennek ellenére sok csapat kombinálja a kettőt. A termékfejlesztéshez sprintszerű tervezési ciklusokat használnak, miközben Kanban-táblán viszik az operatív és támogatási munkát, amely attól függetlenül befut, hogy éppen melyik sprintben vagy. Ez teljesen észszerű hibrid.

A három kérdés, amelyre a táblának harminc másodperc alatt válaszolnia kell

A Kanban-tábla akkor a leghasznosabb, ha ránézésre, bárkivel való beszélgetés nélkül gyorsan megválaszolhatod ezt a három kérdést: Mit csinál most a csapat? Hol akad el a munka? Van-e valami, aminek el kellene készülnie, de még el sem indult?

Ha nem tudsz mind a háromra válaszolni a tábla megnézése után harminc másodpercen belül, valószínűleg nem tartják megfelelően karban. A leggyakoribb hibajelenség az a tábla, amelyen létrehozzák a feladatokat, de soha nem mozgatják őket — a jó szándékok temetőjévé válik ahelyett, hogy a tényleges munka élő térképe lenne. Az elavult tábla rosszabb, mint a tábla hiánya, mert hamis láthatóságérzetet kelt.

A tábla fenntartásához szükséges fegyelem valódi követelmény. A feladatoknak akkor kell mozdulniuk, amikor a munka mozdul. Az elakadt tételeket abban a pillanatban jelezni kell, ahogy megakadnak, nem két héttel később. A kártyáknak világos felelősük legyen, a felelősöknek pedig frissíteniük kell a kártyáikat. Ez nem igényel sok időt — egy jól vezetett Kanban-gyakorlat személyenként naponta öt-tíz percet vehet igénybe —, de következetességet igényel. Azok a csapatok profitálnak a Kanbanból a legtöbbet, amelyek a táblát az igazság forrásaként kezelik, nem pedig kiegészítő nyilvántartásnak.

Mit nem csinál a Kanban

A Kanban nem stratégiai eszköz. Nem segít kitalálni, min dolgozz — csak abban, hogy kezeld, amiről már eldöntötted, hogy dolgozni fogsz rajta. Ha a szervezetednek prioritási problémája van, vagy tisztázatlan a megbízatása, vagy olyan problémája van, hogy „túl sok projektet kezdünk el, mielőtt a régiek befejeződnének”, ami a vezetői magatartásból ered, nem a folyamatból, a Kanban-tábla feltárja ezeket a problémákat, de nem oldja meg őket.

A jó vezetést sem helyettesíti. A tábla nem pótolja az egyéni (1:1) beszélgetéseket, az átgondolt delegálást, sem a világos kommunikációt arról, miért fontos bizonyos munka. A csapatok néha azért vezetnek be folyamateszközöket, mert remélik, hogy a folyamat elvégzi azt a kapcsolati és szervezeti munkát, amely valójában a vezető feladata. Nem fogja.

Amit viszont megtesz, az a mindennapos bizonytalanság csökkentése, amely a legtöbb csapatot lelassítja. A „ki min dolgozik”, „kész van-e ez” és „mit vegyek fel legközelebb” kérdései rengeteg kis értékű kommunikációt generálnak azokban a szervezetekben, amelyeknek nincs közös, látható rendszerük. A Kanban ennek a zajnak a nagy részét megszünteti. Azoknál a csapatoknál pedig, ahol ez a zaj a fő probléma, a különbség jelentős.

Hogyan kezdj hozzá — háromnapos workshop nélkül

A legjobb Kanban-bevezetések, amelyeket láttam, kicsiben indultak és fokozatosan fejlődtek. A legrosszabbak egy tanácsadóval, egy kétnapos offsite-tal és egy gyönyörűen megtervezett táblával jártak, amelyet a harmadik hétre már senki sem használt.

Indulj a csapatoddal úgy, ahogy valójában van, azzal a munkával, amid valóban van. Hozz létre három oszlopot: Backlog, Folyamatban, Kész. Töltsetek el harminc percet a csapattal azzal, hogy minden aktuális munkatételt kártyára tesztek. Állapodjatok meg egy szabályban: amikor elkezdesz valamit, felkerül a táblára. Amikor halad, mozgatod a kártyát. Két hétig semmi mást ne csinálj.

Két hét után nézzétek meg együtt a táblát. Hol halmozódtak fel a dolgok? Mi maradt a Backlogban, pedig mindenki azt mondta, hogy prioritás? Mi haladt gyorsabban a vártnál? Mi akadt el, és miért? Amit megfigyelsz, abból finomítsd az oszlopokat, és tedd őket konkrétabbá. Talán a „Folyamatban” oszlopot szét kell bontani „Folyamatban” és „Külső félre vár” oszlopra. Talán kell egy „Átnézés alatt” oszlop, mert ez a lépés mindig elvész. Hagyd, hogy a tábla azzal együtt fejlődjön, amit a valódi munka felfed, ne azzal, amit egy módszertani könyv szerint kinéznie kellene.

A hosszabb táv: áramlási metrikák

Amint egy Kanban-rendszer működik, olyan adatokat termel, amelyeket a legtöbb csapat soha nem használ. Az átfutási idő — a feladat létrehozásától a befejezéséig eltelt teljes idő — a legfontosabb. Ha egy tipikus feladat átlagos átfutási ideje tizenkét nap, és azt szeretnéd, hogy öt legyen, akkor van egy számod, amelyhez mérheted magad, és egy táblád, amely megmutatja, hová tűnik az a többlet hét nap.

A ciklusidő csak az aktív munkaidőszakot méri, a backlogban töltött időt nem számítja bele. Az áteresztőképesség azt méri, hány tételt fejez be a csapat hetente. Ezek egyike sem igényel különleges szoftvert, ha fegyelmezetten jegyzed fel, mikor jönnek létre és mikor záródnak le a kártyák. Együtt sokkal őszintébb képet adnak a csapat kapacitásáról, mint bármely becslésalapú tervezési folyamat.

A legtöbb kis és közepes méretű csapat sosem jut el idáig. A Kanbant láthatósági eszközként használják — ami önmagában is értékes —, és nem mennek tovább. Ez rendben van. De ha azt veszed észre, hogy az érdekelteknek határidőt szeretnél vállalni arra, mikorra lesz kész valami, vagy meg szeretnéd érteni, miért tart egy munka háromszor tovább a vártnál, a metrikák ott vannak, amikor szükséged lesz rájuk.