L’agile non è affatto semplice

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.

Il project manager in un mondo agile

Tra gli interventi proposti quest’anno a Better Software ce ne sono alcuni che possono essere considerati un ideale completamento al mio “Guerrilla Web Project Management“. “Il project manager e lo sviluppo agile: separati in casa?“, di Jacopo Romei e Stefano Leli, è sicuramente uno di questi. Ecco alcune domande che ho rivolto a Jacopo Romei sul rapporto tra project management e agile.

Il titolo di uno dei workshop che terrai a Better Software è “Il project manager e lo sviluppo agile: separati in casa?”. Perché un project manager potrebbe temere l’introduzione di un approccio agile?

Perché in generale le persone amano lo status quo e un cambiamento utile all’azienda potrebbe essere visto come un pericolo per i propri obiettivi personali. Perché potrebbe non aver chiaro che un approccio anarchico non è l’unica alternativa ad un approccio “command & control”. Perché la funzione del management nello sviluppo agile è diversa da quello che decenni di ingegneria taylorista hanno saputo insegnarci, con successi enormi, ma anche disfunzionalità intrinseche che nel settore software diventano estremamente dannosi.

E quali potrebbero essere, invece, le ripercussioni positive sul suo lavoro?

L’adesione ad un modello di leadership più produttivo e solo in secondo luogo più… bello. Abilitando le persone che introducono il maggior valore nella filiera (sviluppatori, ma anche interaction designer, grafici, sistemisti…) a prendere decisioni tattiche in modo indipendente, il project manager può, per esempio, concentrarsi sulla strategia di portfolio e, solo un secondo esempio, sullo sviluppo di asset preziosi per una azienda software: i cervelli. Molte funzioni ritenute indispensabili del project manager tradizionale sono effettivamente disfunzionali da un punto di vista più sistemico. Il manager, concentrandosi sul flusso di valore e sulla rimozione degli impedimenti, può invece creare le condizioni per cui il team può produrre a livelli altrimenti impossibili e partecipare a questo successo.

Quali sono le principali difficoltà che incontra un project manager che decide ad avvicinarsi all’agile e come può essere aiutato a superarle?

La prima difficoltà è proprio a monte: molti project manager fraintendono la cultura agile. “Agile” non significa né “facile”, né “gratuito”, né “incasinato” né necessariamente “veloce”. Chi si avvicina allo sviluppo agile convinto che ci sarà meno lavoro da fare è completamente fuori strada. Chi invece entra nel mondo agile pronto a installare progressivamente un processo che faccia da cornice ad un miglioramento continuo, scoprirà che a parità di lavoro potrà ottenere molto di più. Per aiutare un project manager ad installare quel processo e a ritagliarlo sul proprio peculiare contesto io cerco sempre di partire attaccando il cosiddetto “wishful thinking“, il pensiero arbitrario. Cercare di basare le proprie analisi e decisioni sui fatti più che sulle percezioni è uno sforzo primario. Non tutto è misurabile numericamente, certo, ma quasi tutto può essere reso empiricamente evidente. Il mio sforzo principale all’inizio è quello di installare dei “manometri” di progetto e nel frattempo educare tutto il team a 2-3 concetti utilissimi, ma largamente ignorati, dell’ingegneria gestionale, tanto per ricordarci che non stiamo parlando di aria fritta: sapete quanti ingegneri hanno studiato la teoria delle code e non la usano mai più?

Jacopo è un coach agile oltre che sviluppatore, scrittore e cantante. È coautore, insieme a Francesco Trucchia, di Pro PHP Refactoring, pubblicato da Apress. E’ anche speaker a diverse conferenze italiane che parlano di agile e lean software development, oltre che uno degli organizzatori di Italian Agile Day, la principale conferenza italiana dedicata all’agile.

Project management 2.0

Lo scorso mercoledì 6 Maggio ho partecipato alla prima edizione della conferenza Better Software, a Firenze, con un intervento dal titolo “Project management 2.0”.

L’intervento è dedicato all’evoluzione di questa disciplina anche grazie all’influenza delle metodologie agili e alla nascita di veri strumenti di collaborazione nell’ambito del cosiddetto web sociale.

La presentazione è suddivisa in due parti: nella prima cerco di ripercorrere le tappe evolutive del project management, passando per il manifesto agile e la dichiarazione di interdipendenza del moderno project management. Nella seconda l’approccio è un po’ più pratico e evidenzio quelle che dovrebbero essere le caratteristiche principali degli strumenti software in aiuto dei project manager, passando in rassegna anche qualche prodotto.

Molti dei presenti, che ringrazio per le interessanti discussioni seguite all’intervento, mi hanno chiesto la possibilità di scaricare da qualche parte le slide. Visto però che la presentazione è composta quasi esclusivamente da immagini senza testo, ho pensato di includere anche un commento audio, che trovate alla fine di questa pagina.

Mi sarebbe piaciuto utilizzare l’audio registrato in sala, ma per una mia leggerezza non ci sono riuscito. Gli organizzatori hanno però una registrazione audio e video di tutti gli interventi. Appena saranno disponibili sostituirò l’audio che ho realizzato in casa, decisamente monotono, con quello della conferenza che è sicuramente più interessante.

Alcuni mi hanno anche chiesto come ho realizzato una presentazione di questo tipo, atipica rispetto ai canoni di presentazioni a cui di solito si è abituati. A questo dedicherò il prossimo intervento qui su Fucinaweb (trovate parte della bibliografia che ho usato in Progettare una presentazione).

Per il momento buona visione e buon ascolto.

Aggiornamento del 15 Maggio 2009: su Slideshare sono in fase di caricamento le presentazioni di Better Software
Aggiornamento del 28 luglio 2009: sono online i video con l’audio preso in sala di tutta la conferenza.