Per què funciona el Kanban i com saber si el teu equip hi està preparat

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

Hi ha un moment que reconeixen la majoria d'equips, normalment quan passen de vuit o nou persones. La feina es fa (s'envien correus, es lliuren funcionalitats, s'atén els clients), però ningú no té una idea clara de què fa la resta. Els projectes s'acumulen. Es prometen coses i després s'obliden en silenci. Dediques vint minuts abans de cada reunió a descobrir en quin punt és realment una feina. La resposta, normalment, és «per algun lloc».

Aquest és el problema que el Kanban va néixer per resoldre. No el problema de definir l'estratègia, de contractar les persones adequades o de construir una cultura, sinó el problema operatiu concret i esgotador de saber en què treballa el teu equip i què l'està frenant.

És una eina sorprenentment humil per a tota l'atenció que ha rebut. El Kanban no pretén arreglar la teva organització. Simplement fa visible la feina. I resulta que la visibilitat, aplicada amb constància, canvia un nombre notable de coses aigües avall.

D'on va sorgir realment el Kanban

La paraula és japonesa (vol dir «cartell» o «tauler de senyals») i el sistema el va desenvolupar Toyota a finals dels anys quaranta per gestionar l'inventari a les seves plantes de fabricació. La idea era senzilla: en lloc de produir peces segons un calendari fix, la fàbrica només les produïa quan una estació posterior indicava que les necessitava. Una targeta física, el kanban, anava enrere per la cadena com a petició. No es fabricava res de manera especulativa. No s'acumulava res de manera innecessària.

La intuïció de Toyota, que més tard van agafar els equips de programari, és que la major part de la ineficiència d'un sistema no ve de gent que treballa massa a poc a poc, sinó de feina equivocada feta en el moment equivocat. Massa coses començades alhora. Colls d'ampolla que ningú no detecta fins que és massa tard. Feina acabada que espera en un lloc mentre el pas següent està desbordat en un altre.

Els desenvolupadors de programari, sobretot en empreses com Microsoft a principis dels anys 2000, van començar a adaptar aquestes idees al treball del coneixement. Les targetes van passar a ser tasques. Les estacions de la fàbrica, etapes d'un flux de treball. I el tauler de senyals va esdevenir un tauler (físic al principi i després digital) on tothom de l'equip podia veure d'un cop d'ull què estava en curs, què esperava i què estava acabat.

Què et mostra realment un tauler Kanban

Un tauler Kanban bàsic té tres columnes: Per fer, En curs i Fet. Per a molts equips petits n'hi ha prou, i és un bon punt de partida. Però el valor real apareix quan comences a personalitzar aquestes etapes perquè s'ajustin a com flueix de debò la teva feina, no a com voldries que flueixi.

Un equip de contingut pot fer servir: Idea, Briefing, En esborrany, En revisió, Programat, Publicat. Un equip de programari podria dividir «En curs» en columnes separades per al desenvolupament, la revisió de codi i el control de qualitat. Un equip de consultoria podria fer el seguiment de Descoberta, Proposta, Actiu, Esperant el client i Tancat. Les etapes haurien de reflectir traspassos reals i temps d'espera reals: llocs on la feina canvia de mans o on s'atura fins que passa una altra cosa.

Fixa't en la targeta de la columna del mig: l'informe d'auditoria del magatzem, amb vuit dies, marcat com a bloquejat. En un sistema sense tauler, aquesta tasca podria estar dues setmanes més aturada abans que ningú s'adonés que no avança. Algú espera un tercer. O es necessita una decisió d'una persona responsable que no sap que és qui bloqueja. El tauler fa visible el bloqueig. Això és la major part de la feina.

La regla que ho fa funcionar: els límits WIP

Si hi ha un concepte que separa els equips que fan servir bé el Kanban dels que només tenen una llista de tasques més maca, són els límits de feina en curs, o límits WIP. La idea és que cada columna té un nombre màxim d'elements que hi poden ser alhora. Quan una columna és plena, no pots afegir més feina fins que alguna cosa en surti.

Això sembla contraintuïtiu. Segurament poder posar més tasques en curs vol dir que se'n fan més? No. El que passa de debò quan la gent treballa en massa coses alhora és que tot triga més. Els canvis de context són cars. La feina mig acabada crea una sobrecàrrega de coordinació. I quan deu coses són «en curs», és molt difícil saber quines avancen de debò i quines són encallades però sense marcar.

Un límit WIP de tres a la columna En curs vol dir que, quan arriba un quart element a la taula d'algú, algú de l'equip ha de prendre una decisió: quina de les tasques existents s'acaba primer? Obliga a prioritzar. Obliga a conversar. I tendeix a fer que els elements individuals s'acabin més de pressa, encara que el ritme d'inici de feines noves es ressenti.

Kanban o Scrum: la pregunta que els equips sempre es fan

Si has passat temps entre equips de programari o has seguit el pensament modern sobre operacions, probablement t'has trobat amb Scrum, el marc que organitza la feina en sprints fixos de dues setmanes, amb sessions de planificació, retrospectives i rols definits com el Scrum Master i el Product Owner. Molts equips tracten Scrum i Kanban com a metodologies rivals i senten que n'han de triar una. La distinció és en realitat més senzilla.

Molts equips, sobretot els que no són d'enginyeria de programari pura, troben feixuc el ritual de Scrum i incòmoda l'estructura d'sprints fixos per al treball operatiu continu. Els equips de màrqueting, d'èxit de clients, d'operacions i els fundadors que gestionen tot alhora poques vegades tenen una feina que encaixi bé en cicles de dues setmanes. El model de flux continu del Kanban sol anar-los millor.

Dit això, molts equips combinen tots dos. Fan servir cicles de planificació a l'estil sprint per al desenvolupament de producte i, alhora, un tauler Kanban per a la feina operativa i de suport que arriba sigui quin sigui l'sprint en curs. És un híbrid perfectament raonable.

Les tres preguntes que el teu tauler hauria de respondre en trenta segons

Un tauler Kanban és més útil quan el pots mirar i, sense parlar amb ningú, respondre ràpidament aquestes tres preguntes: en què treballa ara mateix l'equip? On s'encalla la feina? Hi ha alguna cosa que s'hauria de fer i que encara no s'ha començat?

Si no pots respondre les tres en trenta segons de mirar el tauler, probablement no s'està mantenint bé. La manera més habitual de fracassar és un tauler on es creen tasques però mai es mouen: es converteix en un cementiri de bones intencions i no en un mapa viu de la feina real. Un tauler que no està al dia és pitjor que no tenir-ne cap, perquè crea una falsa sensació de visibilitat.

La disciplina necessària per mantenir un tauler és real. Les tasques s'han de moure quan es mou la feina. Els elements bloquejats s'han de marcar en el moment que s'aturen, no dues setmanes després. Les targetes han de tenir responsables clars, i els responsables han d'actualitzar les seves targetes. Res d'això no requereix gaire temps (una pràctica de Kanban ben portada pot costar de cinc a deu minuts per persona i dia), però requereix constància. Els equips que més es beneficien del Kanban són els que tracten el tauler com la font de veritat, no com un exercici addicional de registre.

Què no fa el Kanban

El Kanban no és una eina d'estratègia. No t'ajudarà a descobrir en què has de treballar, només a gestionar el que ja has decidit fer. Si la teva organització té un problema de priorització, o de mandat poc clar, o un problema de «comencem massa projectes abans d'acabar els antics» arrelat en el comportament del lideratge i no en el procés, un tauler Kanban farà aflorar aquests problemes però no els resoldrà.

Tampoc no substitueix una bona gestió. Un tauler no reemplaça les converses individuals, ni la delegació meditada, ni la comunicació clara sobre per què importa una determinada feina. De vegades els equips adopten eines de procés esperant que el procés faci la feina relacional i organitzativa que de fet correspon a qui dirigeix. No ho farà.

El que sí que farà és reduir la incertesa de fons que alenteix la majoria d'equips. Les preguntes «qui treballa en què», «això està fet?» i «què hauria d'agafar ara» generen una quantitat enorme de comunicació de poc valor en les organitzacions que no tenen un sistema compartit i visible. El Kanban n'elimina la major part, d'aquest soroll. I per als equips en què aquest soroll és el problema principal, la diferència és considerable.

Com començar, sense un taller de tres dies

Les millors implantacions de Kanban que he vist van començar amb poc i van anar evolucionant. Les pitjors van implicar un consultor, dos dies de retir i un tauler preciosament dissenyat que ningú no feia servir a la tercera setmana.

Comença amb el teu equip tal com és i amb la feina que tens de veritat. Crea tres columnes: Backlog, En curs, Fet. Dedica trenta minuts amb l'equip a posar cada element de feina actual en una targeta. Acordeu una sola regla: quan comenceu una cosa, va al tauler. Quan es mou, moveu la targeta. No feu res més durant dues setmanes.

Passades dues setmanes, mireu el tauler junts. On s'ha acumulat feina? Què ha quedat al Backlog que tothom deia que era una prioritat? Què s'ha mogut més de pressa del que s'esperava? Què s'ha encallat i per què? Fes servir el que observis per afinar les columnes i afegir-hi precisió. Potser «En curs» s'ha de dividir en «En curs» i «Esperant un tercer». Potser necessites una columna anomenada «En revisió» perquè aquest pas continua perdent-se. Deixa que el tauler evolucioni segons el que revela la teva feina real, no segons el que diu un llibre de metodologia que hauria de semblar.

El joc a més llarg termini: les mètriques de flux

Quan un sistema Kanban funciona, genera dades que la majoria d'equips no fan servir mai. El lead time, és a dir, el temps total des que es crea una tasca fins que s'acaba, és la més important. Si el lead time mitjà d'una tasca típica és de dotze dies i voleu que sigui de cinc, ara teniu un número amb què treballar i un tauler que us mostrarà on van a parar aquells set dies de més.

El cycle time mesura només el període de feina activa, sense comptar el temps que una tasca passa al backlog. El throughput mesura quants elements completa el teu equip per setmana. Cap d'aquestes mètriques no requereix programari especial si ets disciplinat a anotar quan es creen les targetes i quan es tanquen. I, plegades, donen una imatge molt més honesta de la capacitat del teu equip que qualsevol procés de planificació basat en estimacions.

La majoria d'equips petits i mitjans no arriben mai a aquest punt. Fan servir el Kanban com a eina de visibilitat, que ja té valor per si mateixa, i no van més lluny. No passa res. Però si et trobes volent comprometre't amb els interessats sobre quan estarà feta una cosa, o volent entendre per què una feina triga tres vegades més del que es preveia, les mètriques són allà quan les necessitis.