Retrospectives d'sprint que de debò canvien alguna cosa
Si la retro del teu equip produeix les mateixes queixes cada sprint, no tens una retrospectiva: tens una sessió per desfogar-se. N'he viscut centenars. El patró sempre és el mateix: post-its, agrupació per temes, votació, deu minuts de conversa i, després, res. Al cap de dues setmanes, els mateixos problemes tornen a sortir. L'equip deixa de creure que la retro pugui canviar res i, tard o d'hora, algú proposa de suprimir-la.
La retro és la cerimònia més valuosa de qualsevol procés àgil. És l'única reunió pensada explícitament perquè l'equip es millori a si mateix. Quan funciona, l'efecte es compon: petites millores cada sprint que, al cap d'uns quants trimestres, donen un equip fonamentalment millor. Quan falla, l'equip s'estanca.
Per què fallen la majoria de retros
Cap seguiment de les accions. El motiu número u. L'equip acorda una acció, ningú no se'n fa responsable i, a la retro següent, ja s'ha oblidat. Després de tres cicles, l'equip aprèn que els compromisos de la retro no valen res.
Quedar-se en el símptoma. «Els desplegaments són lents», diu un post-it. L'equip acorda que «hauríem de desplegar més ràpid» i passa al punt següent. Però el pipeline de CI està inflat? Hi ha un pas d'aprovació manual? Els tests són inestables? Sense gratar més avall, l'acció queda vaga i ningú no sap què ha de fer.
Les veus que més se senten ho dominen tot. Dues o tres persones fan el 80% de la conversa. Els enginyers callats — sovint els qui tenen les observacions més fines — no diuen res perquè el format no els deixa espai.
El mateix format cada vegada. El clàssic «què ha anat bé / què no / què podem millorar» serveix per a les primeres retros. Al cap de sis mesos, està gastat. I l'avorriment mata la participació.
Els 5 perquès: arribar a la causa arrel
La tècnica de retro més potent són els 5 perquès — nascuda a Toyota, però que es trasllada perfectament als equips de software. Quan algú planteja un problema, continua preguntant «per què?» fins a arribar a la causa arrel.
Exemple:
- «Dimecres vam tenir una caiguda a producció.» — Per què?
- «Una migració de base de dades es va executar en ple pic de trànsit.» — Per què?
- «No teníem cap política sobre quan executar migracions.» — Per què?
- «Ningú no hi havia pensat: el trànsit mai no havia estat prou alt perquè importés.» — Per què?
- «No tenim cap checklist de preparació del desplegament.» — Causa arrel.
L'acció no és «no executar migracions en hores punta». Això és un pedaç. L'acció és «crear una checklist de preparació del desplegament». Això és una solució sistèmica.
Un format que funciona
Pas 1: repassar les accions de l'sprint anterior (5 minuts)
Comença cada retro repassant les accions de la vegada anterior. Les hem fetes? Si no, per què? Aquest pas, tot sol, crea responsabilitat i deixa clar que els compromisos van de debò. La regla: si una acció no s'ha completat, o es torna a comprometre amb un responsable clar o es descarta explícitament. Res no s'arrossega més de dos sprints.
Pas 2: pluja d'idees en silenci (5 minuts)
Tothom escriu les seves observacions pel seu compte. Sense parlar. El silenci evita l'efecte àncora: que qui parla primer marqui el to de tota la sessió. Vés canviant les preguntes per mantenir-ho fresc:
- «Què hauríem de començar a fer / deixar de fer / continuar fent?»
- «On ens hem sentit encallats? On hem anat fluids?»
- «Si poguéssim canviar una sola cosa de com treballem, quina seria?»
Pas 3: agrupar i votar (5 minuts)
Agrupa les observacions per temes. Vota amb punts. Tria els 2-3 temes principals — ni 5, ni 7. Voler-ho cobrir tot vol dir no cobrir res bé.
Pas 4: aprofundir amb els 5 perquès (15 minuts)
Per a cada tema, condueix una conversa estructurada. El facilitador insisteix amb el «per què?» i talla les culpes i les tangents. Regla de joc: aquí no s'assenyala ningú pel nom. «El procés de desplegament és lent» val. «En Joan endarrereix les revisions de codi», no.
Pas 5: comprometre's amb les accions (10 minuts)
Cada acció ha de tenir:
- Un responsable. Una persona concreta, no «l'equip».
- Una definició de fet. No «millorar els desplegaments», sinó «afegir una fase de tests en paral·lel per deixar el pipeline per sota dels 10 minuts».
- Un termini. Normalment, «abans de la retro següent».
Limita-ho a 2-3 accions. Dues accions completades per sprint valen més que cinc d'abandonades.
Fes rotar el facilitador, o la dinàmica es fossilitza
No deixis que sempre dirigeixi la retro la mateixa persona. Quan el tech lead facilita sempre, la dinàmica es fossilitza. Fes rotar el rol per tot l'equip — sí, també entre els enginyers més callats. Dona'ls una guia senzilla: el format d'aquí dalt, els temps de cada bloc i un repertori de preguntes. La majoria de gent facilita més bé del que es pensa.
La feina del facilitador: controlar el temps. Assegurar-se que tothom parla. Preguntar «per què?» quan el grup es queda en els símptomes. Apuntar les accions amb responsable i termini.
La responsabilitat es juga entre retro i retro
La retro dura 40 minuts. El que fa que aquests minuts comptin és el sistema de responsabilitat que hi ha al voltant.
Fes visibles les accions. Posa-les al tauler de l'equip, al costat de la feina normal. Si l'equip fa servir Jira o Linear, les accions de la retro són tiquets de l'sprint en curs. Millorar el procés no és un extra voluntari: és feina, i prou.
Fes una parada a mig sprint. Una menció de dos minuts a l'standup: «Un moment — Sara, com va la millora del pipeline de CI?» Això deixa clar que els compromisos que l'equip pren amb si mateix importen.
Mesura el percentatge d'accions completades. Si l'equip completa el 80% de les accions de retro, el procés funciona. Per sota del 50%, vol dir que les accions són massa ambicioses, massa vagues o que ningú no les ha prioritzat.
Quan la confiança està tocada
Si el teu equip arrossega mesos de retros que no serveixen de res, pensen que tot plegat és una pèrdua de temps. I, francament, fan bé de pensar-ho: una retro que no canvia mai res és sobrecost pur, i cancel·lar-la és la resposta racional. Aquesta discussió no la guanyaràs amb paraules — recupera la confiança amb victòries ràpides. Tria un problema petit i concret que l'equip pugui resoldre dins del mateix sprint. «A la plantilla de PR ens falta la secció del pla de proves.» Arregla-ho. Ensenya el resultat a la retro següent. Després de tres sprints d'accions completades, la fe torna. I aquesta fe ho és tot.
A Conectia, els enginyers sèniors que incorporem als equips dels clients porten l'experiència de diversos equips d'alt rendiment. Quan un enginyer ha vist resoldre el mateix coll d'ampolla de desplegament de tres maneres diferents en tres empreses diferents, la seva aportació a la retro val més que una altra ronda de pluja d'idees partint de zero.
Necessites enginyers que aportin maduresa de procés, a més de múscul tècnic? Parla amb un CTO — els nostres enginyers sèniors de LATAM reforcen tant la teva base de codi com les teves pràctiques d'enginyeria.
