Smettere di fare progetti software in 4 mosse: #noprojects
Viviamo un’epoca che può essere definita come l’era del digitale. E’ fondamentale spostare l’attenzione da un mindset orientato ai progetti ad una cultura che porta il cliente al centro. Nelle organizzazioni di questo tipo i prodotti sono cittadini di prima classe, e #noprojects è un atto deliberato di gestione continua del prodotto.
In questo webinar, organizzato da Agile Talks Roma insieme a Codemotion Tech Community e a Scrum Agile Milano, Dimitri Favre esplora il mismatch tra software e lavoro organizzato per progetti per poi spiegarci le sue quattro mosse per uscire dal paradigma “progetto-centrico”.
Sono le 18:30, siamo a fine giornata (quantomeno lavorativa) e Dimitri ci accoglie con una bella bottiglia di birra in mano. Dopotutto è orario di aperitivo, perciò volete sapere qual è la prima delle quattro mosse suggerita? Bersi un sorso di birra.
Scherzi a parte, Dimitri non è nuovo su questa tematica del #noprojects. Permettetemi una piccola divagazione storica.
#noprojects – Alcune premesse
Tutto nacque da un hashtag che qualche anno fa stimolò la curiosità di Dimitri. Iniziò a documentarsi, fare dei ragionamenti, organizzare dei talk. Ebbi l’occasione di sentirlo parlare sull’argomento per la prima volta all’Agile Venture di Prato nel 2018 (1). In quell’occasione mi disse qualcosa a riguardo di un suo progetto di scrittura di un libro.
Passa del tempo, dai suoi profili social noto che Dimitri continuava nella sua divulgazione sulla tematica. Lo incontrai all’Agile Venture di Firenze (2) tenutosi nel Settembre dello scorso anno e, tra una chiacchiera e l’altra, gli chiesi come stesse andando la stesura del libro.
“Procede, ci siamo quasi.”
Arriviamo così al Gennaio 2020, con l’annuncio che era disponibile alla vendita un libro dal titolo “Live Happily Ever After Without Projects: A #noprojects book” (3). Dimitri ha portato a termine il suo progetto, complimenti!
Ora torniamo al racconto della serata.
#noprojects – Che cosa vuol dire progetto software
Oggigiorno tutti parlano di progetto. Progetto di vita familiare, progetto di una casa o progetto scolastico per fare alcuni esempi.
Che vuol dire progetto?
Il Project Management Institute (4) fornisce la seguente definizione estratta dal PMBOK® Guide-Fourth edition:
a temporary endeavor undertaken to create a unique project service or result.
Uno sforzo temporaneo per realizzare un risultato o un servizio unico.
Non dimentichiamoci che siamo nell’ambito del software, e il concetto di progetto cambia e non poco. Il software non è temporaneo, anzi perdura nel tempo. E negli anni è soggetto a modifiche, sia per correzione di errori che per aggiunta di nuove funzionalità che per feedback dagli utilizzatori. E’ una longevità diversa da quella di una piramide, come dice Dimitri. Una piramide rimane tale, non verrà mai più ritoccata. Il software sì.
Il concetto di temporaneità insito nella definizione del PMI è quindi diversa per il software.
Facendo sempre riferimento al PMI, per realizzare un un software viene organizzato un team. Composto da persone che magari non hanno mai lavorato assieme.
E qui entra in gioco Tuckman con il suo modello
Il modello di Tuckman
Secondo lo psicologo Bruce Wayne Tuckman lo sviluppo di un gruppo passa attraverso cinque fasi all’interno delle quali il gruppo stesso presenta caratteristiche peculiari. Tuckman introdusse inizialmente il suo modello (5) sviluppato in 4 fasi (nel 1965), basandosi su osservazioni dirette e sull’analisi delle dinamiche all’interno dei team. Successivamente, nel 1977 ed in collaborazione con Mary Ann Jensen, raffinò il modello aggiungendo una quinta fase (aggiornando, in inglese adjourning).
Eccovi uno dei tanti grafici delle quattro fasi del modello:
Forming
Durante questa fase, grazie anche alla mediazione del responsabile di progetto, le persone condividono le informazioni sui loro ambiti di provenienza, i loro interessi e le esperienze pregresse. Nel fare ciò, ciascuno matura le prime impressioni su tutti gli altri. In questa fase si acquisiscono le informazioni relative al progetto, si discute degli obiettivi principali, si conoscono ruoli e responsabilità. La fase di forming è essenziale per la crescita e lo sviluppo del team. Sbagliare in questa fase vuol dire portarsi dietro problemi che difficilmente potranno essere risolti in futuro.
Storming
In questa fase, i membri del team competono per affermare il proprio stato e per far accettare le loro idee. Emergono divergenze sia su cosa dovrebbe essere fatto che su come dovrebbe essere fatto. Questi differenti punti di vista rappresentano la principale causa di conflitti interni al team. Compito del project manager è cercare di intervenire tempestivamente per evitare il formarsi di fratture e fazioni che favorirebbero l’instaurarsi di un clima distruttivo e un inevitabile calo delle prestazioni.
Norming
Superate le iniziali divergenze, affinate le conoscenze reciproche le persone non sono più concentrate sui loro obiettivi individuali, piuttosto si concentrano sullo sviluppo di un modo per lavorare insieme (processi e procedure).
Lavorare insieme inizia ad essere naturale. In questa fase, sono state assimilate le regole fondamentali per lavorare in gruppo, ossia:
- come saranno condivise le informazioni;
- come saranno risolti i conflitti;
- quali i processi e gli strumenti da utilizzare per completare il lavoro previsto.
Il livello di fiducia aumenta, così come la tendenza a cercare il supporto da parte del project manager e di altri membri del team in caso di difficoltà.
Performing
In questa fase si registrano le migliori prestazioni della squadra. L’obiettivo è quello di raggiungere il risultato come gruppo. I membri del team ormai si conoscono, sono chiari i rapporti di forza e le rispettive competenze. Non è detto che un team arrivi a questa fase. Sono tanti i gruppi di lavoro che si fermano alla fase di norming.
In questa fase esiste la possibilità concreta che la squadra possa regredire ad una delle fasi precedenti. E’ possibile ritrovarsi alla fase di conflitto (storming) nel caso, ad esempio, uno dei membri inizi a lavorare in modo indipendente, violando le regole del gruppo.
E’ possibile anche regredire alla fase iniziale di conoscenza (forming) nel caso, ad esempio, la composizione della squadra vari in conseguenza a nuovi ingressi.
Considerazioni e quinta fase del modello di Tuckman
Come recita quel famoso detto? Squadra che vince non si cambia
“Ma se dovesse vincere troppo a lungo, magari i giocatori potrebbero annoiarsi” aggiunge Dimitri. Modello di Tuckman o no, l’approccio non evita alcuni problemi come abbiamo potuto constatare nella spiegazione delle sue fasi.
“Che succede quando il progetto finisce?”
Abbiamo terminato lo sviluppo del software, e lo abbiamo rilasciato in produzione. Inizierà ad essere utilizzato, e anche mantenuto. Ecco, manutenzione.
“Chi si dovrebbe occupare della maintenance del progetto?”
Tipicamente ci lavorano altre persone, che avranno bisogno di un passaggio di consegne da parte del vecchio team. La famosa fase di know-how transfer dove c’è un forte rischio di perdita di conoscenza. A pensarci bene, ad ogni fase anche del modello di Tuckman c’è perdita di conoscenza, e se vogliamo più un software evolve e più si ha perdita di conoscenza.
E’ bene che fin da subito il team abbia una visione chiara di ciò che dovrà fare perché una volta partito un progetto non lo si può più arrestare. E una volta terminato il progetto, è bene che sia lo stesso team a doversi occupare della manutenzione.
Tuckman nel suo modello parla di una quinta fase, adjourning o adjusting. Si entra in questa fase non appena il progetto si avvia verso il processo di chiusura. E’ una fase molto delicata, contrariamente a quanto si possa pensare. Potrebbero verificarsi cali di concentrazione e, allo stesso tempo, l’attenzione degli stakeholder potrebbe impennarsi in prossimità della data di consegna del prodotto/servizio/risultato finale.
Può avere senso forse pensare fin dalle prime fasi ad un team parallelo a quello di sviluppo. Un team che gestisce la vita del prodotto, che mantenga viva la documentazione e che in qualche modo non permetta perdita di conoscenza.
Dopotutto, un prodotto che non evolve probabilmente muore. E con esso la sua azienda!
Quindi perché non pensare a due team o comunque team che assolverebbero due compiti di gestione: manutenzione e vita del prodotto.
#noprojects – Quattro mosse per passare da progetto a prodotto
Prendendo spunto dall’Agile Manifesto (6) Dimitri è giunto a delle conclusioni che sintetizza nelle famose quattro mosse (immagine presa da una delle slide di un suo recente talk):
In ogni progetto si parte da degli obiettivi, o meglio requisiti. Dietro ad ogni requisito c’è un’assunzione. Se ci pensiamo, ogni requisito è un bisogno del nostro cliente. Un qualcosa che permette a qualcuno di raggiungere un obiettivo. Quando un software verrà consegnato, solo allora avremo le vere risposte, ovvero i feedback dei clienti. E allora perché non fare esperimenti fin da subito (Experiments over Projects)? Un esperimento che fornisce dei dati per confutare o meno un’ipotesi. Stiamo parlando dei criteri di accettazione. E qualora si dovesse fallire in uno degli esperimenti, niente paura. Vorrà dire che avremo scoperto nuove informazioni per poter migliorare il nostro software.
Come già scritto nelle considerazioni al modello di Tuckman, cerchiamo di mantenere un team il più stabile possibile (Stable teams over Temporary Endeavor), che si occupi non solo di sviluppo ma anche di manutenzione. Non vi è posto migliore, per fare manutenzione di un software, del luogo dove il software è stato creato. C’è conoscenza.
Quando sviluppiamo, abituiamoci all’idea che stiamo lavorando per un prodotto che servirà a soddisfare i bisogni di qualcuno. Partiamo da questo assunto (Products over Software) e diamo peso ai risultati piuttosto che all’esito di un’esecuzione. Stiamo lavorando per realizzare un prodotto che verrà utilizzato da persone, perciò i loro feedback dovranno avere un peso ben più importante (Outcomes over Execution).
Et voilà, eccovi le 4 mosse per abbracciare la cultura #noprojects.
Conclusioni
Il tempo a disposizione di Dimitri è passato velocemente. Come sempre è stato personalmente piacevole ascoltarlo parlare di #noprojects con il suo inimitabile mix di simpatia e professionalità.
Un ultimo sorso di birra prima di salutarvi. Cin!