Caspita, ne è passato di tempo dal mio ultimo post, e tante cose sono cambiate nel frattempo!
La cosa più importante che mi è capitata è che da oramai un anno ho felicemente cambiato lavoro, e grazie a Sourcesense ho avuto la possibilità di continuare a lavorare in un team agile, dopo la passata esperienza nel team XPlayers di Quinary, iniziata nel 2002.
E’ giusto giusto passato un anno da quando lavoro nel team Orione di Sourcesense, e, dopo diversi progetti di sviluppo e di mentoring, ho avuto l’occasione di fare il coach di una piccola parte del team.
Quest’ultima esperienza mi ha portato anche a fare una riflessione più generale sul coaching di un team agile, riflessioni che vorrei cercare di esprimere in senso più o meno compiuto qui di seguito.

E’ vero, verissimo, come spesso si dice e si sente dire, che ogni membro del team dovrebbe avere a cuore il processo e farsi carico di ricordare a tutti (per primo a sè stesso) le pratiche, i principi e i valori alla base del team stesso, soprattutto in condizioni di pressione o difficoltà. E’ quindi ragionevole dire che il team agile *maturo* è un team “senza coach”.
Eppure questa conclusione non mi soddisfa, e non mi convince del tutto.
Io penso che qualunque team, dal più “green” al piu’ navigato ed esperto, abbia bisogno comunque di un coach. Questo perchè ci sono alcuni “ruoli” che, sebbene possano essere interpretati da molti membri del team (da tutti i membri, in un team maturo), devono avere un interprete primario “designato” dal team.

Faccio un esempio: ognuno di noi sa che in caso di conflitti tra membri del team, o di atti di mancanza di rispetto, dovremmo tutti intervenire per riprendere la persona che ha “alzato i toni”, ma il coach, se presente, di certo interverrà per primo.
Stessa cosa se un customer o qualunque persona “esterna” al team di sviluppo cerca di “forzare” il team a lavorare in modi che contrastano con i valori o i principi alla base del team. In tal caso ognuno di noi, indistintamente, dovrebbe intervenire. Ma non si puo’ intervenire tutti, “in mucchio”. Ci vuole una persona che si faccia carico della cosa e che *per prima* protegga il team da interferenze e pressioni esterne, e per me quella persona è il coach.
So che magari a molti risulterà una metafora un pò lontana, ma pensiamo alle squadre sportive (per esempio di calcio). Lì esiste la figura del capitano, che spesso e volentieri non è neanche la persona più brava della squadra (ad es nel Milan(*) il capitano è Pirlo, non Kaka’ o Ronaldinhio), ma che certo interverrà per prima per riprendere un proprio giocatore se si comporta scorrettamente o se non segue gli schemi, o lo difenderà se è vittima di una decisione arbitrale giudicata ingiusta. Ancora, questo non vuol dire che gli altri giocatori non interverrano ugualmente in questi casi, ma di certo il capitano interverrà per primo e tutti i giocatori lo sanno, e quindi da questo punto di vista sono più “tranquilli”.

Per me questo è il ruolo primario e insostituibile del coach: è quello che c’è sempre e per primo. Se poi lui non può esserci, di certo gli altri faranno in modo che la sua assenza non si senta.

Tutto questo lungo e verboso discorso per dire che non penso basti chiedere che “ognuno di noi si prenda cura del processo”, anche se questo sforzo è condizione assolutamente necessaria al buon funzionamento del team.

P.S. Ricordo che nel team Xplayers in Quinary per un certo periodo il buon Piergiuliano Bossi (a cui devo moltissimo), come esercizio a margine degli studi teorici fatti sul libro bianco di XP di Beck, ci faceva, a turno, essere coach del team, per una iterazione. Questo ci serviva per capire che ruolo avesse davvero il coach.

(*) Nota: non sono milanista, è solo per fare un esempio.

Su InfoQ si parla di tal Jay Bazuzi, “Development Lead for the C# Editor“, che lascia Microsoft e che in occasione di questo “evento”, ha postato sul suo blog delle riflessioni su alcuni punti deboli nello sviluppo del sw in Microsoft.

A parte le osservazioni su come in Microsoft si usa l’OO o si applica refactoring, l’ultimo punto e’ particolarmente interessante, quando parla di “doing better”.

Le domande che Jay raccomanda di farsi per migliorare (e che lui personalmente si faceva e faceva al suo team) sono

• “How can I make sure this problem goes away forever?”
• “How can I produce fewer bugs?”
• “How can I make it easier to fix the bugs I have?”
• “How can I make it easier to respond to change quickly?”
• “How can I make it easier to make my software fast enough?”

Mica paglia!

Che sotto sotto Jay volesse rendere piu’ agile Microsoft? :-)

La mia piccola illuminazione di oggi riguarda il modo tradizionale di pianificare e gestire un progetto software, ovvero con un bel GANTT e MS Project.

Per la prima volta ho dovuto analizzare il GANTT per la nuova release di un progetto su cui sto lavorando, e rivedere alcune attivita’ a nostro carico per capire se mancava qualcosa e verificare le dipendenze e le stime. Ci mancherebbe, se c’e’ da fare, si fa’, ma ho sentito pian piano sorgere un senso di frustrazione…
Ho poi capito il senso di fastidio che provavo: il GANTT (almeno, questo GANTT) e’ piuttosto “tecnical-task centrico”, ovvero organizza le attivita’ “tecniche”, ma non considera in nessun modo le features dal punto di vista del customer.

Tutto il contrario della pianificazione in XP, che e’ “business-value centrica”, ovvero usa le user stories (“units of customer-visible functionality”) per pianificare pezzi di funzionalita’, a prescindere poi dai task tecnici che possono esserci dietro (e che vanno certo esplicitati, se e’ il caso, ma che non hanno valore di business di per se’).

Ma perche’ questa differenza?

Forse questo e’ dovuto al fatto che, mentre il GANTT e’ uno strumento del project manager per guidare il team di sviluppo (il customer lo vedra’ mai?), le user stories sono invece uno strumento del customer per guidare lo stesso team.
In altre parole la pianificazione in XP coinvolge in prima persona il team dei customers (project manager, product manager, marketing, utenti, …), mentre in un progetto tradizionale la dinamica e’ del tipo “eccoti le specifiche, ci si rivede a fine progetto”.

Sta di fatto che io, abituato a ragionare innanziutto per user stories, mi sono ritrovato piuttosto a disagio a ragionare per task tecnici, perche’ facevo fatica a vederci dietro le funzionalita’, e spesso anzi trovavo che la somma dei task tecnici non bastava a coprire la funzionalita’ che il sistema dovrebbe realizzare.

E’ un po’ come descrivere un quadro attraverso la somma dei tratti del pennello che lo compongono… si rischia di perdere il senso complessivo dell’opera.
Il rischio nel caso del software e’ quello perdere tra i tanti task tecnici i veri obbiettivi di una feature, ovvero produrre qualcosa che risponde a delle necessita’ del customer.