De ce funcționează Kanban — și cum să știi dacă echipa ta este gata pentru el

Majoritatea echipelor adoptă Kanban pentru că cineva a citit un articol pe blog. Întrebarea mai inteligentă este dacă problemele pe care Kanban le rezolvă sunt cu adevărat problemele echipei tale.

Există un moment pe care majoritatea echipelor îl recunoaște, de obicei în jurul momentului în care au mai mult de opt sau nouă persoane. Munca se face — e-mailurile se trimit, funcțiile se lansează, clienții sunt gestionați — dar nimeni nu are o idee clară despre ceea ce fac toți ceilalți. Proiectele se acumulează. Lucrurile sunt promise și apoi tacit uitate. Petreci douăzeci de minute înainte de fiecare întâlnire să aflii unde este de fapt o bucată de muncă. Răspunsul, de obicei, este „undeva".

Aceasta este problema pe care Kanban a fost proiectat să o rezolve. Nu problema de a stabili strategie, sau de a angaja persoane potrivite, sau de a construi o cultură — ci problema operațională specifică și obositoare de a ști ce lucrează echipa ta și ce stă în drum.

Este o unealtă surprinzător de modest pentru ceva care a atras atât de multă atenție. Kanban nu pretinde că vă va remediat organizația. Se face pur și simplu munca vizibilă. Și se dovedește că vizibilitatea, aplicată în mod consecvent, schimbă un număr remarcabil de lucruri în aval.

De unde provine cu adevărat Kanban

Cuvântul este japonez — înseamnă „panou indicativ" sau „tablă de afișaj" — și sistemul a fost dezvoltat de Toyota la sfârșitul anilor 1940 ca modalitate de a gestiona inventarul în fabricile lor de producție. Ideea era simplă: în loc să producă piese conform unui program fix, fabrica le-ar produce doar atunci când o stație din aval semnala că are nevoie de ele. Un card fizic — kanban-ul — ar fi călătorit înapoi pe linie ca o cerere. Nimic nu a fost făcut speculativ. Nimic nu s-a acumulat în mod inutil.

Intuiția pe care a avut-o Toyota, și pe care o vor mai târziu echipele de software, este că cea mai mare parte a ineficienței dintr-un sistem nu provine din oamenii care lucrează prea lent, ci din faptul că se execută o muncă greșită la momentul nepotrivit. Prea multe lucruri au fost începute în același timp. Blocaje pe care nimeni nu le observă până să fie prea târziu. Munca care se află terminată într-un loc în timp ce pasul următor este copleșit în altul.

Dezvoltatorii de software, în special la companii precum Microsoft la începutul anilor 2000, au început să adapteze aceste idei pentru munca de cunoaștere. Cărțile au devenit sarcini. Stațiile de fabrică au devenit etape într-o fluxă de lucru. Și panoul indicativ a devenit o tablă — mai întâi fizică, apoi digitală — unde oricine în echipă putea vedea, dintr-o privire, ce era în progres, ce era în așteptare și ce era făcut.

Ce arată cu adevărat o tablă Kanban

O tablă Kanban de bază are trei coloane: De făcut, În progres și Gata. Aceasta este suficientă pentru multe echipe mici și un loc bun pentru a începe. Dar adevărata valoare apare atunci când începi să personalizezi acele etape pentru a se potrivi cu modul în care munca ta curge de fapt — nu cum ai dori s-o curgă.

O echipă de conținut ar putea folosi: Idee, Scurt, În ciornă, Revizuit, Planificat, Publicat. O echipă de software ar putea separa „În progres" în coloane separate pentru dezvoltare, revizuire a codului și QA. O echipă de consultanță ar putea urmări Descoperire, Propunere, Activ, În așteptarea clientului și Închis. Etapele ar trebui să reflecte real transferuri și timpi reali de așteptare — locuri în care munca schimbă mâni, sau unde se întinde până când altceva se întâmplă.

Observă cartea din coloana din mijloc — raportul de audit al depozitului, opt zile în, marcat ca blocat. Într-un sistem fără o tablă, acea sarcină ar putea sta încă două săptămâni înainte ca cineva să realizeze că nu se mișcă. Cineva așteaptă un terț. Sau este nevoie o decizie de la un manager care nu știe că este blocherul. Tabla face blocajul vizibil. Acesta este cea mai mare parte a muncii.

Regula care o face să funcționeze: limitele WIP

Dacă există un concept care separă echipele care folosesc Kanban corect de echipele care au doar o listă de lucru mai frumoasă, aceasta sunt limitele de lucru în progres — limitele WIP pe scurt. Ideea este că fiecare coloană are un număr maxim de articole care sunt permise acolo în același timp. Când o coloană este plină, nu poți adăuga mai multă muncă până când ceva nu se mișcă.

Aceasta se simte contraintuitiv. Sigur, a putea pune mai multe sarcini în progres înseamnă că se face mai mult? Nu. Ce se întâmplă de fapt atunci când oamenii lucrează la prea multe lucruri în același timp este că totul durează mai mult. Schimbul de context este costisitor. Munca pe jumătate finalizată creează cheltuieli de coordonare. Și atunci când zece lucruri sunt „în progres", este foarte greu de spus care se mișcă de fapt și care sunt doar blocate, dar nemarcate.

O limită WIP de trei pe coloana „În progres" înseamnă că atunci când al patrulea lucru ajunge pe birou cuiva, cineva din echipă trebuie să ia o decizie: care sarcină existentă se completează mai întâi? Forțează prioritizarea. Forțează conversația. Și tinde să producă o finalizare mai rapidă a articolelor individuale, chiar dacă rata de începere a lucrurilor noi se încetinește.

Kanban versus Scrum: întrebarea pe care echipele o pun întotdeauna

Dacă ai petrece timp în jurul echipelor de software sau gândire de operații moderne, probabil că ai întâlnit Scrum — cadrul care organizează munca în sprinturi fixe de două săptămâni, cu sesiuni de planificare, retrospective și roluri definite cum ar fi Scrum Master și Product Owner. Multe echipe tratează Scrum și Kanban ca metodologii concurente și simt că trebuie să aleagă. Distincția este de fapt mai simplă decât atât.

Multe echipe — în special cele care nu sunt echipe pure de inginerie de software — găsesc ceremonia Scrum greu și structura sprintului fix ciudată de aplicat muncii operaționale continue. Echipele de marketing, echipele de succes al clienților, echipele de operații și fondatorii care gestionează totul rareori au muncă care se potrivește perfect în cicluri de două săptămâni. Modelul de flux continuu al Kanban tinde să li se potrivească mai bine.

Adică, multe echipe combină ambele. Folosesc cicluri de planificare în stil sprint pentru dezvoltarea de produs în timp ce rulează o tablă Kanban pentru munca operațională și de asistență care curge indiferent de ce sprint ești. Aceasta este o hibridă perfect rezonabilă.

Cele trei întrebări pe care tabla ta ar trebui să le răspundă în treizeci de secunde

O tablă Kanban este cea mai utilă atunci când poți să te uiți la ea și, fără să vorbești cu nimeni, să răspunzi la aceste trei întrebări rapid: Pe ce lucrează echipa ta chiar acum? Unde se blochează munca? Există ceva care ar trebui făcut pe care nu a fost început?

Dacă nu poți răspunde la toate trei în treizeci de secunde de la uitarea la tablă, probabil nu este menținută corect. Cel mai comun mod de defecțiune este o tablă în care sarcinile sunt create dar niciodată mutate — devine un cimitir de intenții bune în loc de o hartă vie a muncii reale. O tablă care nu este actuală este mai rău decât nicio tablă, deoarece creează o fals simț de vizibilitate.

Disciplina necesară pentru a menține o tablă este reală. Sarcinile trebuie să se mute atunci când se mișcă munca. Articolele blocate trebuie marcate în momentul în care se stagnează, nu două săptămâni mai târziu. Cărțile trebuie să aibă proprietari clari, iar proprietarii trebuie să-și actualizeze cărțile. Nimic din aceasta nu necesită o mulțime de timp — o practică Kanban bine rulată ar putea dura cinci până la zece minute per persoană pe zi — dar necesită consecvență. Echipele care beneficiază cel mai mult de Kanban sunt acelea care tratează tabla ca sursă de adevăr, nu ca exercițiu suplimentar de tinere.

Ce nu face Kanban

Kanban nu este un instrument de strategie. Nu te va ajuta să afli pe ce să lucrezi — doar să gestionezi ceea ce ai decis deja. Dacă organizația ta are o problemă de prioritizare, sau o problemă de mandat neclar, sau o problemă „pornim prea multe proiecte înainte de a termina vechi" înrădăcinată în comportamentul de conducere mai degrabă decât în proces, o tablă Kanban va dezvălui acele probleme, dar nu le va rezolva.

Nu este, de asemenea, un substitut pentru gestionare bună. O tablă nu înlocuiește unu la unu, delegare reflexivă sau comunicare clară despre de ce anumite lucruri contează. Echipele uneori adoptă instrumente de proces cu speranța că procesul va face munca relațională și organizațională care este de fapt sarcina managerului. Nu va.

Ce va face este să reducă incertitudinea ambiantă care încetinește majoritatea echipelor. Întrebările de „cine lucrează la ce", „este asta gata" și „ce ar trebui să iau mai departe" generează cantități uriașe de comunicare cu valoare mică în organizații care nu au un sistem partajat și vizibil. Kanban elimină cea mai mare parte a acestei zgomote. Și pentru echipele în care acel zgomot este problema dominantă, diferența este semnificativă.

Cum să începi — fără un atelier de trei zile

Cele mai bune implementări Kanban pe care le-am văzut au început mic și au evoluat. Cele mai proaste au implicat un consultant, o retragere de două zile și o tablă frumos proiectată pe care nimeni nu a folosit-o la săptămâna trei.

Pornind cu echipa ta așa cum este de fapt, cu munca pe care o ai de fapt. Creează trei coloane: Backlog, În progres, Gata. Petrece treizeci de minute cu echipa ta punând fiecare articol de muncă curent pe o carte. Fii de acord cu o regulă: atunci când începi ceva, merge pe tablă. Când se mișcă, mișcă cartea. Nu face nimic altceva timp de două săptămâni.

După două săptămâni, privește-te la tablă împreună. Unde s-au acumulat lucrurile? Ce s-a păstrat în Backlog pe care toată lumea a spus că era o prioritate? Ce s-a mișcat mai rapid decât era de așteptat? Ce s-a blocat și de ce? Folosește ceea ce observi pentru a rafina coloanele și a adăuga specificitate. Poate „În progres" trebuie împărțit în „În progres" și „În așteptarea extern". Poate ai nevoie de o coloană numită „În revizuire" deoarece acel pas se pierde continuu. Lăsați tabla să evolueze în răspuns la ceea ce munca ta reală dezvăluie, nu în răspuns la ceea ce spune o carte de metodologie ar trebui să arate.

Jocul mai lung: metrici de flux

Odată ce un sistem Kanban funcționează, generează date pe care cele mai multe echipe niciodată nu le folosesc. Timp de conducere — timp total de la moment în care o sarcină este creată până când se completează — este cea mai importantă. Dacă timp mediu de conducere pentru o sarcină tipică este douăsprezece zile, și vrei ca acesta să fie cinci, acum ai un număr pe care să lucrezi și o tablă care îți va arăta unde merg acele șapte zile suplimentare.

Timpii ciclului măsoară doar perioada de lucru activ, excluzând timp pe care o sarcină stă în backlog. Throughput măsoară câte articole completează echipa ta pe săptămână. Niciunul dintre aceste cuvintele cheie nu necesită software special dacă ești disciplinat despre notarea când cărți sunt create și când sunt închise. Și împreună, vă dau o imagine mult mai onestă a capacității echipei tale decât orice proces de planificare bazat pe estimări.

Majoritatea echipelor mici și de mărime medie nu ajung niciodată aici. Folosesc Kanban ca instrument de vizibilitate — care este valoros în sine — și nu merg mai departe. Asta e bine. Dar dacă te găsești vrand să faci angajamente față de părțile interesate despre când va fi făcut ceva, sau vrând să înțelegi de ce unele lucrări durează de trei ori mai mult decât era de așteptat, metricile sunt acolo când ai nevoie de ele.