Nelle mie ultime esperienze mi sono trovato a lavorare in teams che dovevano gestire più progetti contemporaneamente ed ho potuto constatare come un team sia in grado di lavorare come singoli all’interno della stessa stanza o come vero team che collabora, si aiuta e consegna maggior valore al cliente.
Tutto sta nel come si gestiscono i progetti.
Quando la gestione prevede l’assegnazione di nomi ad un progetto si instilla la “paura” o la “competizione” negli sviluppatori, a seconda del contenuto tecnologico e/o di business dello stesso. Ma di fondo si sà che passeranno diversi mesi senza poter vedere qualcosa di nuovo o più interessante.
Io sono fortemente convinto invece che la gestione deve essere fatta assegnando i progetti ad un team.
Vediamo cosa cambia applicando i due approcci.
Se assegnamo i nomi ad un progetto:
- le persone non ruotano sui progetti per lunghi periodi, perchè il time-in è alto e deve essere ammortizzato su un periodo più lungo di tempo.
- le coppie che si possono formare sono poche e quindi si lavora molto spesso con le stesse persone.
- le coppie tendono a ruotare (all’interno del progetto) meno spesso, facendo lavorare per molti giorni di seguito la stessa coppia.
- gli stand up meeting sono noiosi perchè quando si parla di progetti su cui non si è coinvolti è molto difficile rimanere attenti.
Se assegnamo i progetti ad un team:
- le persone ruotano giornalmente sui progetti, facendo circolare velocemente idee, nuovi punti di vista, conoscenze.
- le coppie che si possono formare sono tutte quelle possibili e quindi si lavorerà con persone diverse tutti i giorni
- tutti partecipano attivamente e con attenzione allo stand up meeting rendendolo più efficace
Ovviamente per far funzionare bene il team e per evitare di creare confusione dal lato del cliente ogni UserStory dovrà essere “firmata” da uno sviluppatore che avrà la responsabilità di portarla a termine.
Questo comporta che tale sviluppatore non ruoterà su altre storie, ma una volta terminata potrà decidere se
- firmare una storia dello stesso progetto
- firmare una storia di un altro progetto
- non firmare alcuna storia in modo da poter cambiare progetto ogni giorno.
Come passare da un’organizzazione all’altra? per passi ovviamente.
All’inizio le persone che erano precedentemente assegnate al tal progetto saranno le uniche in grado di firmare le carte perchè saranno le sole che padroneggiano dominio e design e che permettono di continuare ad essere produttivi, così facendo otteniamo però che metà delle persone precedentemente assegnate al progetto saranno libere di lavorarne altri.
Il secondo passo è ruotare giornalmente le coppie in maniera da iniziare a far fluire le informazioni da una persona all’altra dando insieme il grosso vantaggio di avere un paio d’occhi nuovi e smaliziati sulle questioni correnti (es. P1:”ma perchè continuate a passare questa informazione che è già contenuta nel secondo parametro?”, P2:”oooops… hai ragione! Eliminiamolo!”)
Dopo qualche iterazione (qualche settimana) tutti i non-firmatari avranno preso confidenza con tutti i progetti in corso ed inizieranno a farsi avanti al momento della firma delle nuove storie andando a sostituire coloro che erano finora le sole possibili scelte, permettendogli, a loro volta, di ruotare sugli altri progetti e completare il processo di “osmosi”.
Questo permette di costruire un TEAM che non sia meramente un gruppo di singoli sviluppatori ognuno impegnato a coltivare il proprio orticello.
IL CLIENTE
Se non si ha il “customer on site”, ed in una configurazione multi-progetto è molto probabile, un area da gestire è il contatto con il cliente. Per farlo sentire a proprio agio all’inizio bisogna dare continuità alle persone con cui dialoga, dandogli il tempo di fidarsi dei “nuovi arrivati”.
Pian piano il cliente conoscerà tutti i componenti del team e il problema si andrà affievolendo. Qui la questione per me è ancora aperta nel senso che sto osservando le reazioni a questi cambiamenti da parte del customer.
IL NUMERO DI PROGETTI
Il numero di progetti che si possono seguire contemporaneamente dipende da come si decide di pianificare, il team ha una capacità determinata dal numero di coppie che si possono formare (team di 10 sviluppatori formano 5 coppie) quindi si può andare da un semplice “Un progetto -> una coppia” ad una gestione un pò più complessa fatta così:
data una velocità complessiva di 12 punti ad iterazione si allocano 6 punti al progetto A, 3 punti al progetto B, 3 punti al progetto C, in cui la ripartizione dei punti è decisa da come è stata venduta ai clienti.
A
)