Per què funciona Kanban — i com saber si el teu equip està preparat per a això

La majoria d'equips adopten Kanban perquè algú va llegir una entrada de blog. La pregunta més intel·ligent és si els problemes que Kanban resol són realment els problemes que el teu equip té.

Hi ha un moment que la majoria d'equips reconeixen, generalment al voltant del moment en què tienen més de vuit o nou persones. La feina es fa — els correus electrònics s'envien, les característiques s'envien, els clients es gestionen — però ningú no té una sensació clara de quina feina està fent tothom més. Els projectes s'apilen. Les coses es prometen i després s'obliden silenciosament. Passes vint minuts abans de cada reunió descobrint on realment és un deu de feina. La resposta, generalment, és "enmig de tota part."

Aquell és el problema que Kanban va ser dissenyat per resoldre. No el problema de definir l'estratègia, o contractar les persones adequades, o construir una cultura — sinó el problema operacional específic i desgastador de saber quina feina fa el teu equip i quina cosa es comporta obstacle.

És una eina sorprenentment humil per a quelcom que ha atret tanta atenció. Kanban no pretén arreglar la teva organització. Només fa visible la feina. I resulta que la visibilitat, aplicada consistentment, canvia un nombre remarcable de coses enderrere.

D'on va venir realment Kanban

La paraula és japonesa — significa "tauler de senyals" o "pancarta" — i el sistema va ser desenvolupat per Toyota a finals dels anys quaranta com a forma de gestionar l'inventari a les seves plantes de fabricació. La idea era simple: en lloc de produir peces en un calendari fix, la fàbrica només les produïa quan una estació corrents-avall assenyalava que les necessitava. Una targeta física — el kanban — viatjaria cap amunt per la cadena com a sol·licitud. Res no es va fer especulatiu. Res no s'apilava innecessàriament.

La idea que Toyota va tenir, i que els equips de software més tard van demanar préstec, és que la majoria d'ineficiència en un sistema no prové de persones que treballen massa lentament, sinó de la feina equivocada que es fa a l'hora equivocada. Massa coses commencen alhora. Els coll d'ampolla que ningú nota fins que és massa tard. Feina que s'està acabada en un lloc mentre el pas següent està sobrellena alguna altra part.

Els desenvolupadors de software, particularment en empreses com Microsoft a principis dels anys 2000, van començar a adaptar aquestes idees per al treball de coneixement. Les targetes es van convertir en tasques. Les estacions de fàbrica es van convertir en etapes en un flux de treball. I el tauler de senyals es va convertir en una junta — físicament al principi, després digital — on tothom de l'equip podria veure, en un ullet, quina feina estava en curs, quina estava esperant, i quina estava feta.

Què una junta Kanban realment et mostra

Una junta Kanban bàsica té tres columnes: Per fer, En curs, i Fet. Això és suficient per a molts equips petits i un bon lloc per comenci. Però el valor real sorgeix quan comences a personalitzar aquestes etapes per coincidir amb com el teu flux de treball realment — no com desitges que fluïs.

Un equip de contingut pot usar: Idea, Breu, En esbós, En revisió, Planificat, Publicat. Un equip de software podria dividir "En curs" en columnes separades per desenvolupament, revisió de codi, i control de qualitat. Un equip de consultoria podria fer seguiment de Descoberta, Proposta, Actiu, Esperant client, i Tancat. Les etapes haurien de reflectir traspàs reals i temps d'espera reals — llocs on la feina canvia de mans, o on s'estàs fins que quelcom més passa.

Nota la targeta a la columna del mig — l'informe d'auditoria del magatzem, vuit dies dins, marcat com a bloquejat. En un sistema sense una junta, aquella tasca podria estar durant dues setmanes més abans que ningú es doni compte que no es mou. Algú espera un tercer. O una decisió és necessària per un manager que no sap que són el bloqueador. La junta fa visible el bloqueig. Això és la majoria de la feina.

La regla que ho fa funcionar: límits WIP

Si hi ha un concepte que separa els equips que utilitzen Kanban correctament dels equips que només tienen una llista de tasques més bonica, són els límits de treball en curs — límits WIP per a curts. La idea és que cada columna ta un nombre màxim d'elements que es permet que estiguin allà al mateix temps. Quan una columna està plena, no pots afegir més feina fins que quelcom es mogui.

Això sembla contraintuïtiu. Segurament que ser capaç de posar més tasques en curs significa que se'n fa més? No. El que realment passa quan la gent treballa en massa coses simultàniament és que tot porta més temps. El commutació de context és cara. El treball semi-acabat crea sobrecàrrega de coordinació. I quan deu coses són "en curs," és molt difícil dir quines són realment moviment i quines són només atrapades però sense marcar.

Un límit WIP de tres a la teva columna En curs significa que quan la quarta cosa arriba a la taula de quelcú, algú de l'equip ha de prendre una decisió: quina tasca existent es completa primer? Força prioritat. Force conversa. I tendeix a produir finalització més ràpida de elements individuals, fins i tot si la velocitat de comencement d'elements nous es ralenteix.

Kanban versus Scrum: la pregunta que els equips sempre fan

Si has passat temps al voltant d'equips de software o pensament d'operacions modernes, probablement has trobat Scrum — el marc que organitza la feina en sprints fixes de dos setmanes, amb sessions de planificació, retrospectives, i rols definits com Mestre de Scrum i Propietari de Producte. Molts equips tracten Scrum i Kanban com metodologies competitors i senten que han de triar. La distinció és realment més simple que això.

Molts equips — especialment els que no són equips de enginyeria de software pur — troben el ritual de Scrum pesat i la seva estructura de sprint fixa incòmoda d'aplicar al treball operacional continu. Els equips de màrqueting, equips d'èxit de clients, equips d'operacions, i fundadors gestionar tutto-at-once rarament ten feina que encaixa perfectament en cicles de dos setmanes. El model de flux continu de Kanban tendeix a convenir-los millor.

Dit això, molts equips combinen ambdós. Utilitzen cicles de planificació estil sprint per al desenvolupament de producte mentre corren una junta Kanban per al treball operacional i de suport que flueix independentment de quin sprint estigui. Això és un híbrid perfectament raonable.

Les tres preguntes que la teva junta hauria de respondre en trenta segons

Una junta Kanban és més útil quan pots mirar-la i, sense parlar amb ningú, respondre aquestes tres preguntes ràpidament: Quina feina està fent el teu equip en aquest moment? On estàs feina quedant atrapada? Hi ha quelcom que hauria de fer que no ha comencé?

Si no pots respondre totes tres dins de trenta segons de mirar la junta, probablement no s'està mantenint correctament. El mode de fracàs més comú és una junta on les tasques es creen però mai es mouen — es converteix en un cemiri de bones intencions en lloc d'un mapa viu de la feina real. Una junta que no és actual és pitjor que cap junta, perquè crea una fals sensació de visibilitat.

La disciplina requerida per mantenir una junta és real. Les tasques necessiten moure quan la feina es mou. Els elements bloquejats necessiten ser marcats el moment en què s'aturen, no dues setmanes més tard. Les targetes necessiten tenir propietaris clars, i els propietaris necessiten actualitzar les seves targetes. Cap d'això requereix molt temps — una pràctica Kanban ben executada podria prendre cinc a deu minuts per persona per dia — però requereix consistència. Els equips que més es beneficien de Kanban són els que tracten la junta com la font de veritat, no com una exercici de manteniment de registres suplementari.

Què Kanban no fa

Kanban no és una eina d'estratègia. No t'ajudarà a descobrir què fer — només ajudar-te a gestionar el que ja has decidit fer. Si la teva organització ha tingut un problema de prioritat, o un problema de mandat poc clar, o un problema "comecem massa projectes abans de acabar els antics" arrelat en comportament de lideratge en lloc de procés, una junta Kanban revelarà aquells problemes però no els resoldrà.

Tampoc és un substitut per a bones gestió. Una junta no reemplaça els un-a-un, o delegació reflexiva, o comunicació clara sobre per què certa feina importa. Els equips a vegades adopten eines de procés esperant que el procés farà el treball relacional i organizacional que és realment feina del manager. No ho farà.

El que farà és reduir la incertesa ambiental que ralenteix la majoria d'equips. Les preguntes de "qui treballa en quina feina," "està fet," i "quina feina hauria de recollir a continuació" generen enormes quantitats de comunicació de valor baix en organitzacions que no tienen un sistema compartit i visible. Kanban elimina la majoria del soroll. I pels equips on aquell soroll és el problema dominant, la diferència és significativa.

Com comença — sense un taller de tres dies

Les millors implementacions Kanban que he vist van comença petites i va evolucionar. Les pitjors implicaven un consultor, una retirada de dos dies, i una junta bellament dissenyada que ningú usava pel dia tres.

Comença amb el teu equip com realment és, amb la feina que realment tens. Crea tres columnes: Cartera de projectes, En curs, Fet. Gasta trenta minuts amb el teu equip posant cada element de treball actual en una targeta. Estar d'acord en una regla: quan comences quelcom, va a la junta. Quan es mou, moues la targeta. No fes res més per dues setmanes.

Després de dues setmanes, mira la junta junts. On va apilar les coses? Que va quedar a Cartera de projectes que tothom va dir era una prioritat? Que es va moure més ràpid que l'esperat? Que va quedar atrapada i per què? Usa el que observes per refina les columnes i afegir especificitat. Potser "En curs" ha necessitat dividir en "En curs" i "Esperant extern." Potser necessites una columna cridada "En revisió" perquè aquell pas segueix perdent-se. Deixa que la junta evolucioni en resposta al que la teva feina real revela, no en resposta al que un llibre de metodologia diu que hauria de semblar.

El joc més llarg: mètriques de flux

Una vegada que un sistema Kanban funciona, genera dades que la majoria d'equips mai usen. El temps de conducció — el temps total des de quan es crea una tasca fins que es completa — és la més important. Si el teu temps de conducció promig per una tasca típica és dotze dies, i vols que sigui cinc, ara tens un nombre a treballar i una junta que et mostra on aquells vuit dies addicionals van.

El temps de cicle mesura només el període de treball actiu, excloent el temps que una tasca segs a la cartera de projectes. El rendiment mesura quants elements el teu equip completa per setmana. Cap d'aquestes mètriques requereixen software especial si eres disciplinat sobre prendre nota quan les targetes es creen i quan es tanquen. I junts, et donen una imatge molt més honesta de la capacitat del teu equip que qualsevol procés de planificació basat en estimació.

La majoria d'equips petits i mitjans mai arribar aquí. Utilitzen Kanban com una eina de visibilitat — que és valuosa en si mateixa — i no van més lluny. Això està bé. Però si et trobes volent fer compromisos als stakeholders sobre quan quelcom es farà, o volent entendre per què una feina porta tres vegades tant de temps com es preveu, les mètriques estan allà quan les necessites.