Miért működik a Kanban — és hogyan kell tudni, hogy a csapat készen áll-e rá

A legtöbb csapat a Kanban-t adoptálja, mert valaki elolvasott egy blogbejegyzést. Az okosabb kérdés az, hogy a Kanban által megoldott problémák tényleg a csapat problémái-e.

Van egy pillanat, amelyet a legtöbb csapat felismer, általában akkor, amikor több mint nyolc vagy kilenc ember van. A munka végzése — az e-maileket elküldenek, a funkciók szállnak, az ügyfeleket irányítják — de senkinek nincs világos képe arról, hogy mi mások mit csinálnak. A projektek felgyülemlnek. Dolgokat ígérnek meg, majd csendesen elfelejtik. Húsz percet töltesz minden megbeszélés előtt, hogy megtudja, hol van tényleg egy munkadarab. A válasz általában "valahol".

Ez az a probléma, amelyet a Kanban a megoldásra terveztek. Nem az stratégia meghatározásának problémája, vagy a megfelelő emberek felvételének, vagy a kultúra felépítésének — hanem az a konkrét, őrlő, működési probléma, hogy tudja, mit csinál a csapat és mi áll az útjában.

Ez egy meglepően szerény eszköz valamire, amely annyi figyelmet vonzott. A Kanban nem azt állítja, hogy megjavítja a szervezeted. Csak láthatóvá teszi a munkát. És kiderül, hogy a láthatóság, következetesen alkalmazva, meglehetősen sok mindent megváltoztat.

Honnan valóban a Kanban

A szó japán — "jelzőtáblát" vagy "hirdetményt" jelent — és a rendszert a Toyota fejlesztette ki az 1940-es évek végén, mint a készletkezelés módja a gyártóüzemekben. Az ötlet egyszerű volt: ahelyett, hogy a részeket rögzített ütemezés szerint gyártanák, a gyár csak akkor gyártotta volna őket, amikor egy alsó állomás jelzett volna, hogy szüksége van. Egy fizikai kártya — a kanban — visszavezetett volna a sorra, mint egy kérés. Semmi sem készült spekulatívan. Semmi sem halmozódott fel szükségtelenül.

A belátás, amelyet a Toyota volt, és amelyet szoftver csapatok később kölcsönöztek, az, hogy a legtöbb hatékonysághiány a rendszerben nem az emberek lassú munkájából, hanem a rossz munka végzéséből eredet a rossz időben. Túl sok dolog kezdődött egy időben. Szűk keresztmetszetek, amelyeket senki sem vesz észre, amíg túl késő nem lesz. Munka, amely egy helyen befejezettként ül, míg a következő lépés máshol túltöltött.

A szoftver fejlesztők, különösen olyan vállalatok, mint a Microsoft a 2000-es évek elején, elkezdték ezeket az ötleteket alkalmazni a tudásmunkához. A kártyák feladatokká váltak. A gyári állomások egy munkafolyamat szakaszaivá váltak. A jelzőtábla pedig egy tábla — először fizikai, majd digitális — ahol bárki a csapatból láthatott egy pillantásra, mi volt folyamatban, mi várt, és mi volt megtörtént.

Mit mutat meg ténylegesen egy Kanban tábla

Az alapvető Kanban táblának három oszlopa van: Tenni való, Folyamatban, Kész. Ez elég sok kis csapatnak és jó hely a kezdéshez. De az igazi érték akkor jelenik meg, amikor elkezded testreszabni ezeket a szakaszokat, hogy megfeleljenek ahhoz, hogyan folyik valóban a munka — nem ahogy szeretnéd, hogy az menjen.

Egy tartalomcsapat használhatja: Ötlet, Rövid, Vázlatban, Felülvizsgálatban, Ütemezettben, Publikált. Egy szoftver csapat szétválaszthatja az "Folyamatban" -t a fejlesztés, a kód áttekintés és a QA külön oszlopaiba. Egy tanácsadó csapat nyomozhatja meg a felfedezést, az ajánlatot, az aktív, az ügyfélre várakozást és a zártat. A szakaszok valós átadásokat és valós várakozási időket tükrözzenek — helyeket, ahol a munka kezet vált, vagy ahol ül, amíg valami más történik.

Figyelje meg a kártyát a középső oszlopban — a raktár audit jelentés, nyolc napja, blokkolásaként megjelölt. Egy rendszerben tábla nélkül, ez a feladat még két hétig ülhetett, mielőtt bárki rádöbben, hogy nem mozog. Valaki egy harmadik félre vár. Vagy egy döntésre van szükség egy managertől, aki nem tudja, hogy ő a blokkolók. A tábla a blokkelést láthatóvá teszi. Ez a legtöbb munka.

Az a szabály, amely működik: MUNKAVEZET korlátozások

Ha van egy koncepció, amely elválasztja a Kanban-t helyesen használó csapatokat azoktatól, akik csak egy szebb tennivalólista, ez a munka-in-progress korlátozások — rövid MUNKAVEZET korlátozások. Az ötlet az, hogy minden oszlopnak maximum szám van engedélyezett egyszerre. Ha egy oszlop megtelt, nem adhatsz hozzá több munkát, amíg valami ki nem mozdul.

Ez ellentétes az intuícióval. Biztos, hogy több feladat fel tudsz mutatni a munka során több végbement? Nem. Amit ténylegesen történik, amikor az emberek túl sok dolgon dolgoznak, egyszerre az, hogy minden tovább tart. A kontextus váltása drága. A félig befejezett munka koordinációs költségvetéseket hoz létre. És amikor tíz dolog van "folyamatban", nagyon nehéz megmondani, mely tételek mozognak ténylegesen és melyek csak elakadtnak, de megjelölve.

A MUNKAVEZET korlátja három az "Folyamatban" oszlopban azt jelenti, hogy amikor a negyedik dolog megérkezik valakihez, a csapat valakijének döntést kell hoznia: melyik meglévő feladat befejezze először? Ez kényszeríti a prioritást. Ezt beszélgetésre kényszerít. És általában a gyorsabb egyedi tételek befejezésénél hajlamos, még akkor is, ha az új tételek indításának sebessége lelassul.

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

Ha valaha is körül volt szoftver csapatokkal vagy modern üzemeltetési gondolkodással, valószínűleg Scrum-ot találtál — az a keret, amely a munkát rögzített kétéves sprintekre szervezi, tervezési ülésekkel, retrospektívekkel és meghatározott szerepekkel, például Scrum Master és Product Owner. Sok csapat a Scrumot és a Kanban-t versengő módszertanként kezeli, és úgy érzi, hogy választania kell. A megkülönböztetés egyszerűbb, mint ez.

Sok csapat — különösen azok, amelyek nem tiszta szoftver mérnöki csapatok — találja, hogy a Scrum szertartása nehéz és a rögzített sprint szerkezete kínos a folyamatos operatív munka alkalmazására. A marketing csapatok, az ügyfél siker csapatok, az operációs csapatok és az alapítók, akik mindent vezetnek, ritkán olyan munka van, amely gondosan illeszkedik a kétéves ciklusokba. A Kanban folyamatos flow modellje általában jobban megfelel nekik.

Ez azt mondta, sok csapat mindkettőt kombinálja. A szoftverfejlesztéshez sprint-style tervezési ciklusokat használnak, miközben egy Kanban táblát futtatnak az operatív és támogatási munka számára, amely függetlenül attól, hogy melyik sprintben vagy létezik. Ez egy teljesen ésszerű hibrid.

A három kérdés, amelyet a táblának harminc másodperc alatt meg kell válaszolni

Egy Kanban tábla a leghasznosabb, amikor rá lehet nézni és senki mással beszélgetés nélkül, válaszolja meg ezeket a három kérdést gyorsan: Mit csinál a csapat most? Hol akadályozza meg a munka? Van-e valami, amely meg kellene csinálni, amely nem indult meg?

Ha nem tudod mindhármat válaszolni harminc másodperc alatt a tábla megtekintése után, valószínűleg nem tartják megfelelően. A leggyakoribb meghibásodási mód egy tábla, ahol feladatokat hoznak létre, de soha nem mozog — jó szándékok temetőjévé válik, ahelyett, hogy az atual munka élő térképe lenne. A tábla, amely nem jelenlegi, rosszabb, mint nincs tábla, mivel hamis láthatóság érzetét hozza létre.

A tábla fenntartásához szükséges fegyelem valós. A feladatoknak akkor kell mozgatódni, amikor a munka mozog. A blokkolásos tételeket akkor kell megjelölni, amikor megstagnálnak, nem két hét múlva. A kártyáknak világos tulajdonosai kell legyenek, és a tulajdonosoknak frissíteniük kell a kártyáikat. Ez egyike sem igényli sok időt — egy jól futó Kanban gyakorlat naponta öt-tíz percet vehet igénybe személyenként — de konzisztenciát igényel. A csapatok, amelyek a legjobban hasznát veszik a Kanban-nak, azok, akik a táblát az igazság forrásaként kezelik, nem mint egy kiegészítő nyilvántartást.

Mit nem csinál a Kanban

A Kanban nem stratégiai eszköz. Ez nem segít abban, hogy megtudd, mit dolgozzál — csak az, amit már eldöntöttél, hogy mit dolgozzál meg. Ha szervezetednek prioritási problémája van, vagy egy tisztázatlan mandátum problémája van, vagy egy "túl sok projektet kezdünk el az öreg befejezése előtt" probléma a vezetői viselkedésből, nem a folyamatból, egy Kanban tábla felfedi azokat a problémákat, de nem oldja meg.

Ez nem a jó kezelésnek a helyettesítése sem. A tábla nem helyettesíti az egy-az-egy kommunikációt, vagy az átgondolt delegálást, vagy a világos kommunikációt arról, hogy miért fontos bizonyos munka. A csapatok néha folyamati eszközöket vesznek fel, remélve, hogy a folyamat elvégzi a relációs és szervezeti munkát, amely valójában a menedzser feladata. Ez nem fog.

Amit meg fog tenni, az a környezeti bizonytalanságot csökkent, amely lelassítja a legtöbb csapatot. A "kik dolgoznak", "kész-e ez", és "mit kellene felvennem" kérdéseiről nagy mennyiségű alacsony értékű kommunikációt generál azoknak a szervezeteknek, amelyeknek nincs megosztott, látható rendszere. A Kanban ezt a legtöbb zajt kiküszöbössé teszi. A csapatok számára, ahol az zaj a domináns probléma, a különbség jelentős.

Hogyan kell kezdeni — háromnapos workshop nélkül

A legjobb Kanban megvalósítás, amelyet láttam, kicsit kezdte és fejlesztett. A legrosszabb egy tanácsadó, egy kétnapos offsite és egy szépséges tábla volt, amelyet senki nem használt a harmadik hét által.

Kezdj a csapatoddal, ahogy ténylegesen van, azzal a munkával, amelyem valóban van. Hozz létre három oszlopot: Háttérbank, Folyamatban, Kész. Töltsd meg a csapatoddal harminc percet, hogy minden aktuális munkaelemet egy kártyára tegyen. Egyezzen meg egy szabályon: amikor elkezdesz valamit, az a tábla kerül. Amikor mozog, mozgatod a kártyát. Semmit sem csinálsz másért két hétig.

Két hét után, nézd meg a táblát együtt. Hol gyülemltek fel a dolgok? Mit hagytál meg a Háttérbank-ban, amelyet mindenki azt mondta, hogy prioritás? Mit mozgatott gyorsabban, mint várt? Mit akadt meg és miért? Használd azt, amit megfigyelsz az oszlopok finomítóásához és konkrétasabbá tételéhez. Talán az "Folyamatban" -t szétválasztani kell az "Folyamatban" és a "Külső várakozásban". Talán szüksége van egy olyan oszlopra, mint az "Felülvizsgálatban", mert ezt a lépést mindig elvesztik. Hagyja, hogy a tábla fejlődjön az, amit a valós munka felfed, nem azt, amit egy módszertani könyv azt mondja, hogy kellene kinézni.

Az hosszabb játék: munkafolyamat metrikák

Miután egy Kanban rendszer működik, adatokat generál, amelyeket a legtöbb csapat soha nem használ. Vezet idő — az teljes idő attól, hogy egy feladat létrejön, ameddig kész — a legfontosabb. Ha az átlagos vezet idő egy tipikus feladathoz tizenkét nap, és azt szeretnéd, hogy öt legyen, most már egy szám van dolgozni és egy tábla, amely megmutatja, hol mennek az extra hét nap.

A ciklus idő csak az aktív munkaperiódust méri, kizárva azt az időt, amikor egy feladat a háttérben ül. A teljesítmény azt méri, hogy hány tételt befejez a csapat hetente. Ezek közül egyik sem igényli a különleges szoftvert, ha fegyelmezett vagy a kartonok létrehozásakor és zárásáról jegyzetelésben. Együtt egy sokkal őszintébb képet adnak a csapat kapacitásáról, mint bármely becslés alapú tervezési folyamat.

A legtöbb kis és közepes méretű csapat soha sem jut el ideig. A Kanban-t láthatóság eszközként használják — amely önmagában értékesek — és ne menjenek tovább. Ez semmi. De ha azt találod, hogy azt szeretnéd, hogy az érdekelt feleknek ígérj arról, hogy mikor lesz meg valami, vagy azt szeretnéd, hogy megértsd, miért tart meg a munka háromszor hosszabbnak, mint várt, a mutatók ott vannak, amikor szükséged van rá.