Condizione necessaria e non sufficiente dei metodi agili
Per il principio già esposto che per dare importanza a un concetto bisogna dedicargli esplicitamente del tempo, i meeting di retrospettiva sono la pratica che si concentra sul miglioramento del processo di lavoro.
Come fa un team a dirsi agile se non è guidato da uno spirito di miglioramento ?
Un team non può professarsi 'agile' se non pratica la retrospettiva con regolarità. In alcuni team questa pratica non viene attuata con la scusa che si è sempre liberi di proporre miglioramenti o alzare una bandiera di soccorso quando ce n'è la necessità, ma in verità non ci vuole molto per capire che questo non può accadere spontaneamente.
Problemi comuni
Nei vari anni ho trovato poche retrospettive davvero utili. Ma per quelle vale comunque la pena averne fatte tante poco efficaci ! In ogni team ci sono uno o due persone che prendono a cuore l'argomento, e tendono a parlare sempre, e uno o due persone che sono introverse o disinteressate.
E' compito di un buon facilitatore far sì che tutti abbiano il loro spazio. Il fulcro della retrospettiva è la comunicazione, principalmente verbale. Ma se non tutti hanno avuto modo di esprimere il loro parere non è stata una buona retrospettiva!
Reputo la figura del moderatore fondamentale; probabilmente può venire a meno solo in team davvero esperti e affiatati (o forse nemmeno in quel caso?)
Ciò che cerco sempre di evitare è l'effetto "gruppo di ascolto". Concentrandosi sui problemi, è facile che le discussioni vertino sulle mancate responsabilità di altri reparti, di altri collaboratori.
Temi del tipo "il pm non sceglie con cura le priorità", "i sistemisti non rispondono ai ticket celermente", "gli analisti danno specifiche troppo incomplete" sono ricorrenti. Il piu delle volte sono inutili.
Vale solo la domanda di cosa puoi fare tu e il tuo team per migliorare l'ambiente, ed eventualmente anche la comunicazione con questi reparti.
Le azioni
E' diffuso il concetto che scopo delle retrospettive è generare azioni.
Non sono d'accordo.
Primo perchè le azioni dovrebbero essere meditate, e non inventante nel breve arco di tempo di una retrospettiva. Secondo perchè il valore di una retrospettiva è la comunicazione. Senza saggiare il parere di tutti su un argomento, senza una adeguata meditazione si rischia di proporre azioni deboli. E azioni deboli che non convincono verranno svolte poco impeto, risultando inefficaci.
Se non ci sono azioni forti, risolutive, non fate nulla!
L'iniziativa personale
La fase della retrospettiva in cui si generano azioni non deve essere la sola in cui attuare un cambiamento. Se una persona si prende a cuore un aspetto ed ha desiderio di migliorarlo, a mio avviso può e deve essere aiutato dal team in termini di tempo e supporto. Spesso mi è accaduto di ringraziare una persona per il lavoro personale che ha intrapreso spontaneamente.
Le idee e le iniziative personali vanno incoraggiate, non soppresse!
Team agili...appesantiti
Spesso le azioni di una retrospective mirano ad aggiungere regole al processo. Dopo un po di retrospective le regole -sensate- che si sono aggiunte sono davvero tante...e il team diventa tutto tranne che agile.
Le regole create sono da rivedere puntualmente e, a mio avviso, sono anche da limitare.
Esempio di azioni sensate che un generico team agile propone:
- verifichiamo le metriche prima di ogni commit
- facciamo code review ad ogni aggiornamento del codice
- al termine di una funzionalità implementata ci ritagliamo x ore per pulire / documentare
- prima di iniziare una carta scriviamo tutti gli acceptance test
- prima di iniziare una carta la dividiamo in task
- non si inizia una carta se ce ne sono altre in progess
- su ogni carta c'è un responsabile fisso e ogni giorno il resto del team ruota
