Una transizione pragmatica dal micro caos ai metodi agili

Un team tanto eterogeneo dispone inevitabilmente di diversi tipi abilità:
- le doti analitiche maggiormente sviluppate in chi ha maturato più anni di esperienza
- il coraggio misto all’ingenuità di chi ha appena iniziato a lavorare
- le doti innate e indipendenti dall’esperienza quali quelle algoritmiche o di relazione

Per quanto riguarda la parte tecnologica il team ha quasi sempre dimostrato di essere in grado di soddisfare in autonomia le richieste del progetto.
Sono però da sottolineare due avvenimenti importanti che hanno evidenziato l’immaturità del team: il primo riguarda il progetto del motore dei suggerimenti, il secondo le ferie del coach a settembre.
Nel 2007 è stato assegnato ai Wallabiez il compito di progettare e sviluppare un motore di suggerimenti. Inizialmente si pensava che avremmo avuto autonomia nello scegliere come procedere allo sviluppo, nello scegliere chi allocarvi e nella scelta delle tecnologie da utilizzare. Il software doveva essere integrato in un progetto molto più ampio (il progetto Feltrinelli) sviluppato da un team tradizionale (il team Fcom) e gestito da un project manager e da un technical leader. Le prime imposizioni vennero però dall’allora responsabile della produzione che volle due specifiche persone sul progetto. Iniziammo lo sviluppo, utilizzando le tecnologie secondo noi maggiormente adeguate: contemporaneamente Sinapsi stava assumendo nuovo personale per creare il team autonomo Fcom.

Al primo incontro col team Fcom, il technical leader richiese un costoso adeguamento tecnologico poiché riteneva fondamentale che tutto il software sviluppato per il progetto Feltrinelli utilizzasse le medesime tecnologie. Avevamo scartato le tecnologie imposte perché non giustificate, a nostro avviso, dalla contenuta complessità del problema. Queste imposizioni fecero in modo che il progetto non fosse sentito come appartenente ai Wallabiez, e nei momenti critici, il team non si è dimostrato autonomo.
Come coach ho commesso l’errore gravissimo di non seguire adeguatamente il progetto e le persone, tanto che queste hanno dovuto rivolgersi al responsabile di produzione. Inoltre non ho capito che, nonostante le imposizioni, o forse proprio per quelle, ciò che mi avevano offerto era un’importante occasione di crescita.

Un altro momento importante durante il quale il team non si è dimostrato autonomo si è verificato durante le mie ferie a settembre. Proprio nei giorni della mia assenza, Banca Popolare di Sondrio decise di realizzare un importante rinnovamento tecnologico mirato a risolvere problemi di performance. L’intervento consisteva nel migrare i web services da una tecnologia di pubblicazione proprietaria e non più manutenuta all’attuale standard de facto. Si parlava di questa migrazione (o porting) da tempo: avevamo infatti già prodotto un’analisi dettagliata delle attività con le relative stime. I tentativi di far partire questa attività prima della mia partenza erano stati inefficaci: le attività legate a un’imminente scadenza ministeriale avevano la priorità. Durante la mia assenza il team era in formazione ridotta a causa dell’accavallarsi delle ferie e di un’operazione al ginocchio di altri due membri del team. Priorità e attività erano state definite: nessuna urgenza era stata prevista.

Dopo la prima settimana di ferie, una telefonata dal responsabile della produzione mi avvisava che, in mia assenza, era stato contattato dal responsabile del reparto Information Technologies (IT) di BPS per realizzare il porting che ritenevano urgentissimo. Il responsabile della produzione, non avendo ottenuto un riscontro positivo dal team, ha deciso a questo proposito di affidare il porting ad una società esterna. In mia assenza nessuno del team era stato in grado di andar dal cliente per parlare con lui al fine di capire la reale urgenza di questa attività: tutti hanno pensato solo a portare a termine l’attività assegnata prima della mia partenza.