La Sprint Retrospective (la “Retro”) és una reunió en què el protagonista és la recerca de la millora en tots els aspectes de la gestió i la construcció del producte
Només hi ha una reunió al marc de treball Scrum on el Scrum Master és responsable d’organitzar-la, pilotar-la i aplicar les decisions que es desprenguin. I és la Sprint Retrospective. A la resta de reunions proposades al marc de treball els responsables són els mateixos tècnics (Sprint Planning i la Daily), o el Product Owner (Sprint Review)
Com hem dit, l’objectiu d’aquesta reunió és proporcionar a l’equip un espai per poder debatre sobre quins aspectes poden millorar d’ara endavant en les accions de construcció del producte. Per a fer-ho, és molt bona pràctica fer servir l’experiència immediata obtinguda en l’execució del Sprint que tot just ha finalitzat. En aquest sentit, hi ha algunes fonts de dades que el Scrum Master i l’equip poden utilitzar per cercar àrees de millora:
Algunes qüestions que el Scrum Master i l’equip tècnic poden posar sobre la taula en la Retro:
La Retro duu a terme (o s’hauria) tot just en acabar la Sprint Review del Sprint. Perquè la informació en calent proporcionada en aquesta reunió és de molt valor per a la Retro. Els resultats de la Review van més enllà de si els stakeholders ens han acceptat o no l’increment. I inclou altres variables objectives i subjectives:
El Scrum Master és responsable de la llista dels incidents, bloquejos o problemes apareguts durant el Sprint. Aquesta llista es sotmet a debat en la Retro per tal de treure’n algunes propostes de millora.
Al final, els temps són sempre una font necessària d’informació. Els temps de resolució de les històries d’usuari i de les tasques tècniques ens dona informació sobre la complexitat real front a la inicialment estimada. Casar allò que vàrem estimar amb el que ha resultat a la pràctica és un bon exercici per aprendre i afinar en futures estimacions.
No podem fer una Retro basada únicament en els problemes.
Fer això és no tenir al cap a les persones que tenim davant. Som persones, no màquines. Els èxits, és a dir, allò que hem fet bé, és tant o més valuós que un problema de la llista d’incidents.
El Scrum Master ha de prendre bona nota de les coses que s’han fet bé i exposar-les a la reunió, per tal que l’equip adquireixi consciència d’allò que fa bé i ho reforci per als Sprints següents.
Una Retro que acaba sense decidir res no és una Retro. Les retros han d’acabar amb una sèrie de propostes consensuades per l’equip. A aquest respecte existeixen algunes dinàmiques que el Scrum Master pot encetar per tal que l’equip participi, debati, classifiqui i decideixi les accions de millora més interessants.
Una activitat força estesa consisteix a classificar les nostres propostes de millora en funció d’aspectes o accions que ens interessa potenciar o mitigar. El diagrama anterior il·lustra accions que:
Un cop treballada aquesta llista de millores, l’equip en selecciona algunes (almenys una) per executar-la durant el sprint següent. Les accions de millora poden ser molt diverses:
L’organització ha de ser conscient que les accions de millora són feina. És a dir, ocupen temps. Per tant, és lògic esperar que al Sprint següent farem feina en favor del producte, però no del valor del sprint. Hem de trobar un equilibri, amb l’ajuda del Product Owner, perquè aquestes accions de millora puguin encabir-se en el Sprint d’una forma proporcionada i raonable.
| Review-Retro o Planning-Retro | No hi ha temps | Retrospectives amb pressa |
|---|---|---|
| No fer la retro. O bé, fer-la en l’àmbit d’una altra reunió | Es reserva espai per la retro, però aquesta té tendència a cancel·lar-se per atendre altres temes “més importants” | No es reserva el temps suficient. No es tracten els objectius de la reunió assegurant la qualitat d’aquesta |
| Mai estan presents els stakeholders | Stakeholders o direcció sempre present | Tot el que passa a Las Vegas es queda en Las Vegas |
|---|---|---|
| Encara que la reunió és per a l’equip, sovint és interessant conèixer les propostes dels stakeholders. O que aquests coneguin de primera mà la realitat de l’equip | Al contrari que l’anterior, si la direcció o persones interessades rellevants sempre estan presents a la retro, es perd espai per a que l’equip pugui tractar problemes domèstics | Tot el que passa a la retro no surt de la retro |
| Dominadors | Victimisme | Dia de la marmota |
|---|---|---|
| Un o diversos membres dominen la reunió i coarten la participació de la resta | La retro no serveix per exposar dramatismes sobre la situació del projecte o de l’equip. Hem de fer un esforç en trobar solucions, i no només exposar els problemes | La retro sempre es desenvolupa igual. No s’innova |
| Quina millora? | Passivitat | Sense documentació |
|---|---|---|
| La retro ha de servir per avaluar les propostes de millora provinents de retros anteriors | Els membres de l’equip no participen en la dinàmica establerta perquè s’interpreta com una pèrdua de temps, o no es creu en les propostes de millora | La retro ha de servir per prendre nota de les decisions i fer seguiment en el futur |
Descarrega l’esquema per imprimir aquí
