Manca una settimana a Better Software e questa è l’ultima delle interviste che ho realizzato con alcuni speaker. Dopo Luca Mearelli (Quel che resta del backoffice) e Jacopo Romei (Il project manager in un mondo agile) è la volta di Alberto Brandolini, che parlerà di come gestire la transizione verso l’agile nell’intervento dal titolo “Non è affatto semplice“. Per quanto mi riguarda, vi aspetto lunedì 27 giugno alle 13.15 in auditorium per “Guerrilla Web Project Management“.

“Non è affatto semplice” gestire la transizione verso un approccio agile, come spiegherai nel tuo intervento a Better Software. Come mai?

Se posso individuare una causa prima per gran parte dei problemi in ottica di gestione dei progetti di sviluppo software, è nel perdurante tentativo di adottare strumenti e modalità di ragionamento che non sono adeguati ad un Sistema Adattivo Complesso quale un team di sviluppo.

Cercare di maneggiare questo tipo di complessità con un diagramma di Gantt, ad esempio, è come cercare di fare il bagno al vostro gatto (vi si rivolterà contro ed i costi supereranno di gran lunga i benefici). Ma non è sempre facile accettare questo tipo di transizione: istintivamente siamo a portati a credere che il sistema debba essere deterministico, ed ammettere che non lo sia (non lo può essere) per molti suona come una resa, o una mancanza di professionalità. L’altro aspetto “rivoluzionario” è legato alla trasparenza. Spesso un sacco di energie sono dedicate a nascondere o non dire certe cose, o semplicemente a comunicare solo con “alcuni” nella convinzione che “altri non necessitino di essere informati” o “non debbano essere informati”. Non ho ancora avuto modo di vedere progetti messi nei guai dalla trasparenza.

E’ chiaro che un approccio trasparente cambia anche la natura della gestione dei rischi. Molti rischi sono trattati esplicitamente, e l’approccio è diametralmente opposto al “potete fidarvi di me” che caratterizza alcuni colleghi. Il primo step spesso è proprio l’opposto: terrorizzare il management, per rassicurare il team. Ma la direzione è quella di una reciproca fiducia nella capacità di team e management di gestire i rischi ed uscire dalle situazioni critiche.

Il ruolo di cui si sente molto la mancanza è quello di un “portatore di Visione”: se la visione è condivisa con il team, le scelte che vengono fatte in corso d’opera saranno coerenti con questa visione, ed il prodotto rifletterà questo approccio. La User Experience spesso è una grande cartina al tornasole della capacità di condividere una visione.

Come cambia la figura del project manager nell’agile?

La maggior trasparenza sul reale stato di avanzamento del progetto, permette di giocare d’anticipo. Fin dalle prime settimane del progetto si può capire se gli obiettivi sono realizzabili nella configurazione attuale, oppure se è necessario intervenire su date, scope del progetto o skills del team. Aspettare non è un’opzione consigliata.

La conseguenza di questo approccio è che le cattive notizie vanno date presto. Per poter portarne di buone al termine del progetto.

L’altro aspetto forse più difficile da digerire è la riduzione della componente decisionale. Non è sensato che un Project Manager si faccia personalmente carico di un gran numero di decisioni. Il PM è responsabile del fatto che determinate decisioni vengano prese, nel modo più efficace possibile. E’ tutto da dimostrare che prendere certe decisioni in autonomia, a porte chiuse e, successivamente <sarcasmo>con grandissima capacità comunicativa</sarcarsmo> informare il team della decisione presa sia la strategia migliore per il successo del progetto.

Può il team di sviluppo aiutare il project manager in questo nuovo ruolo, e come?

Deve. Anche in questo caso la trasparenza è fondamentale. Ci sono esigenze reciproche che vanno comprese. Il Project Manager deve avere accesso a tutta una serie di informazioni sull’andamento del progetto e queste devono essere reali. L’enfasi sulla scomposizione in User Story ad esempio serve anche a dare una misura dell’avanzamento reale, in termini di features completate anziché di “lavoro svolto”. Ma dal punto di vista dello sviluppatore, l’approccio può non essere intuitivo o apparire sub-ottimale. Nello sviluppo agile ci sono meno cose da fare (es. il gantt) ma molte più cose da fare insieme. E la comprensione del punto di vista degli altri ruoli coinvolti è fondamentale.

Alberto Brandolini è un professionista dell’information technology con il pallino di vedere tutto da un’angolazione diversa e di cercare di risolvere il prossimo problema. Consulente, docente, speaker, imprenditore, blogger, autore, in Italia ed all’estero, in determinate circostanze riesce anche a sembrare una persona seria.