Kanban vs. Scrum: un marc de decisió, no una guerra de religió
Pocs temes de la gestió d'enginyeria aixequen tanta polseguera i aporten tan poca llum com el debat entre Kanban i Scrum. He estat en reunions on gent normalment assenyada discutia la durada dels sprints amb la passió d'uns constitucionalistes debatent esmenes. He vist equips fracassar amb Scrum i concloure que «l'agile no funciona», quan el problema de debò era que volien collar un cargol a cops de martell.
Després d'anys dirigint i assessorant equips d'enginyeria, n'he tret una conclusió: la metodologia importa molt menys que el fet que encaixi amb el tipus de feina, la maduresa de l'equip i la fase del producte. Scrum no és millor que Kanban. Kanban no és millor que Scrum. La bona és la que ajuda el teu equip concret a lliurar valor amb la mínima fricció.
Construïm un marc per prendre aquesta decisió, en lloc de triar bàndol.
La diferència de fons: iteracions tancades o flux continu
Abans de decidir, siguem precisos sobre què fa exactament cada enfocament.
Scrum és un marc de treball construït al voltant d'iteracions de durada fixa (els sprints). L'equip es compromet amb un abast de feina a l'inici de cada sprint, hi treballa entre una i quatre setmanes, i al final lliura un increment potencialment lliurable. Ve amb rols definits (Product Owner, Scrum Master, equip de desenvolupament) i amb cerimònies (planificació de sprint, standup diari, revisió de sprint, retrospectiva).
Kanban és un mètode construït al voltant del flux continu. No hi ha iteracions. Les tasques entren en un tauler, avancen per etapes (pendent, en curs, revisió, fet) i en surten quan estan acabades. El mecanisme central són els límits de WIP: un sostre de quants elements pot haver-hi alhora en cada etapa. Quan queda un buit, s'hi incorpora feina nova.
La diferència fonamental: Scrum agrupa la feina en blocs de temps tancats; Kanban la tracta com un corrent continu. Tota la resta —cerimònies, rols, mètriques— es deriva d'aquesta distinció.
Quan encaixa Scrum
Scrum funciona millor quan l'equip necessita ritme, previsibilitat i cicles de planificació estructurats. En concret:
Desenvolupament de producte amb fites clares. Si estàs construint funcionalitats de cara a un llançament, una demo per a inversors o un roadmap trimestral, els sprints et donen punts de control naturals. «Què lliurarem d'aquí a dues setmanes?» és una pregunta que Scrum respon bé.
Equips que han de rendir comptes enfora. Startups amb inversors que demanen avenços, agències amb lliuraments a client, equips que reporten a stakeholders que volen terminis previsibles. Els compromisos de sprint creen una cadència de lliuraments que els perfils no tècnics poden entendre.
Equips nous o en formació. L'estructura de Scrum fa de barana. Les cerimònies prescrites forcen la comunicació. Els standups diaris fan aflorar els bloquejos. Les retros obliguen a reflexionar. Per a un equip que encara està aprenent a treballar plegat, aquesta bastida té molt de valor.
Feina transversal amb dependències. Quan frontend s'ha de coordinar amb backend, que s'ha de coordinar amb disseny, la planificació de sprint és el moment d'alinear-se. «Aquest sprint tots dos treballem en el flux de pagament» és com evites que dos equips construeixin peces que no encaixen.
Quan encaixa Kanban
Kanban funciona millor quan la feina és contínua, de mida variable i guiada per interrupcions. En concret:
Manteniment i operacions. Correccions de bugs, incidències reportades per clients, incidents de producció, tasques d'infraestructura. Aquesta feina no s'empaqueta bé en sprints de dues setmanes: arriba quan menys t'ho esperes, varia moltíssim de mida i ha de travessar el sistema tan de pressa com sigui possible.
Equips de suport i SRE. Si la feina principal de l'equip és respondre a peticions entrants, i no construir funcionalitats planificades, encabir-la en sprints és antinatural. Kanban et permet prioritzar i processar la feina a mesura que arriba.
Equips amb una taxa d'interrupcions alta. Si més del 30% de la feina de l'equip no està planificada (incidents, bugs urgents, peticions ad-hoc dels stakeholders), el compromís de sprint de Scrum esdevé una ficció. No assoliràs mai els objectius de sprint, i l'equip tindrà la sensació de fracassar constantment fins i tot quan fa bona feina.
Equips madurs i autoorganitzats. Enginyers experimentats que no necessiten cerimònies per comunicar-se, que agafen feina nova pel seu compte, que entenen les prioritats sense una sessió de planificació. Kanban els dona autonomia sense sobrecàrrega.
El marc de decisió
Així és com avaluo quin enfocament encaixa amb un equip. Valora cada factor i mira cap a on decanta la balança.
Tria Scrum quan:
- La feina és majoritàriament planificada (el 70% o més de la capacitat va a funcionalitats previstes)
- L'equip és nou o s'ha reorganitzat fa poc
- Els stakeholders necessiten cadències de lliurament previsibles
- El producte està en desenvolupament actiu, amb roadmap
- L'equip és de 3 a 7 persones
- Necessites forçar la reflexió (retros) perquè a l'equip no li surt sola
Tria Kanban quan:
- La feina és majoritàriament reactiva (el 50% o més no està planificada o ve d'interrupcions)
- L'equip gestiona tipus de feina diversos (funcionalitats + bugs + operacions)
- El cycle time importa més que la previsibilitat
- L'equip és madur i autoorganitzat
- Necessites el màxim rendiment amb feina de mida variable
- Reduir el lead time és l'objectiu principal
Considera Scrumban (híbrid) quan:
- Tens una barreja de feina planificada i no planificada
- Vols el ritme dels sprints però el flux de Kanban
- L'equip està en transició d'un enfocament a l'altre
- Necessites planificació de sprint per al roadmap però flux Kanban per al manteniment
Scrumban: el punt intermedi pràctic
A la pràctica, la majoria d'equips amb qui treballo acaben fent alguna versió de Scrumban, encara que no en diguin així. Té aquesta pinta:
- Cadència de sprint per planificar i fer retros. Mantens cicles de dues setmanes per a la planificació, la revisió i la retrospectiva. Això preserva el ritme i el retiment de comptes enfora.
- Tauler Kanban amb límits de WIP per a l'execució diària. En lloc d'un backlog de sprint rígid, la feina flueix pel tauler. Si a mig sprint arriba un bug urgent, entra al tauler sense «trencar el sprint».
- Cap compromís de sprint: un objectiu de sprint. L'equip té un objectiu («publicar la integració de pagaments»), però no una llista rígida d'històries compromeses. Això redueix la ficció dels compromisos de sprint que no sobreviuen mai al contacte amb la realitat.
- Mètriques dels dos mons. Mesura la velocitat per planificar capacitat (Scrum) i el cycle time per a l'eficiència del flux (Kanban).
Aquest híbrid funciona especialment bé en equips de 4 a 8 enginyers que desenvolupen producte amb un 20-40% de capacitat reservada per a bugs i deute tècnic.
La variable de debò: la maduresa de l'equip
Després de desenes d'equips, he observat una cosa: el debat sobre metodologia sol amagar un problema de maduresa de l'equip.
Als equips immadurs (no pas en habilitats, sinó en la manera de treballar junts) Kanban els costa, perquè exigeix autodisciplina. Sense límits de WIP, tot està «en curs». Sense cerimònies, ningú no es comunica. Sense compromisos de sprint, res no s'acaba. Aquests equips necessiten l'estructura de Scrum no perquè Scrum sigui millor, sinó perquè necessiten baranes.
Als equips madurs els costa Scrum, perquè la sobrecàrrega els sembla burocràcia. La planificació de sprint és un tràmit: ja saben en què treballen. Els standups són informes d'estat que ningú no necessita. El compromís de sprint o bé és trivialment assolible o bé el trenca el primer incident de producció. Aquests equips necessiten la flexibilitat de Kanban no perquè Kanban sigui millor, sinó perquè la bastida els ha quedat petita.
La progressió que veig més sovint: començar amb Scrum, evolucionar cap a Kanban a mesura que l'equip madura, i acabar en un híbrid Scrumban que conserva les cerimònies útils i descarta la resta.
Errors habituals
Fer Scrum sense retrospectives. Les retros són el mecanisme de millora contínua. Si te les saltes, estàs fent waterfall en blocs de dues setmanes.
Fer Kanban sense límits de WIP. Un tauler Kanban sense límits de WIP és una simple llista de tasques. La gràcia és precisament limitar la feina en curs per millorar el flux i fer aflorar els colls d'ampolla.
Canviar de metodologia enmig d'una crisi. «Això no funciona, passem a Kanban» és gairebé sempre un error. Arregla primer el problema de fons. Cap metodologia no arregla una comunicació trencada, unes prioritats difuses o unes expectatives irreals.
Mesurar el que no toca. Els punts d'història completats per sprint no mesuren la qualitat de l'equip. El cycle time, tot sol, no captura el valor per al client. Fes servir les mètriques per millorar el procés, no per jutjar les persones.
L'adhesió rígida al marc. Si les cerimònies de Scrum es mengen el 20% del temps de l'equip, ho estàs fent malament. Si el teu tauler Kanban té 12 columnes, ho estàs fent malament. Tots dos marcs estan pensats per ser adaptats, no per seguir-los com textos sagrats.
Com avaluar-ho i canviar
Si tens dubtes sobre el teu enfocament actual, prova això:
- Mesura la taxa d'interrupcions. Durant dues setmanes, registra quin percentatge de la feina era planificada i quin no. Si la feina no planificada supera el 40%, els compromisos de Scrum fallaran sistemàticament.
- Pregunta-ho a l'equip. De debò. «El procés actual us ajuda o us fa nosa?» Tindràs respostes honestes.
- Fes un experiment de sis setmanes. Passa a l'enfocament alternatiu durant tres sprints (o sis setmanes). Mesura el cycle time, el rendiment i la satisfacció de l'equip abans i després.
- No cantis victòria ni derrota massa aviat. Qualsevol canvi de metodologia es fa estrany les dues primeres setmanes. Dona-li temps d'assentar-se.
A Conectia, quan integrem enginyers sènior en equips de clients, ajustem la seva experiència a la metodologia de l'equip, tant si és un Scrum estricte, com un Kanban pur o un híbrid. Els nostres enginyers han treballat amb els tres, perquè la realitat de la consultoria sènior és que t'adaptes al que funciona per a l'equip, i no a l'inrevés.
El millor procés és el que el teu equip segueix de veritat i l'ajuda a lliurar. Tota la resta és ideologia.
Necessites enginyers sènior que s'adaptin al teu procés en lloc de barallar-s'hi? Parla amb un CTO: els nostres enginyers de LATAM s'integren al teu flux de treball, tant si treballes amb Scrum, com amb Kanban o amb alguna cosa entremig.
