La prima volta che mi parlarono di Agile Software Development era il 2010. Ebbi subito la sensazione che fosse quello che avevo sempre atteso, quello che mi risolveva un sacco di problemi che avevo nella gestione di progetti.
Fu un po’ come cambiarsi gli occhiali: vedevo tutto quello che si stava facendo da una prospettiva completamente diversa. Chiaramente molti ci guardavano come più o meno immagino si guardassero gli “eretici” nel medioevo o come si guarderebbe un cane che dice di aver visto un arcobaleno (i cani sono parecchio daltonici).
Che problemi volevamo risolvere?
L’approdo su Agile (e in particolare su Scrum) fu la fine di un lungo percorso di ricerca, stimolato da alcuni problemi esistenziali che stavamo vivendo in azienda:
- eravamo sistematicamente in ritardo sui progetti
- quando il progetto era finito, in realtà non lo era perché venivano fuori decine di bug bloccanti
- non si sapeva mai a che punto fosse lo sviluppo
- i reparti non si parlavano
- i reparti avevano priorità completamente disallineate
- nessuno era owner del progetto e nessuno si sentiva responsabile della sua evoluzione nei mesi successivi al rilascio
Perché Agile?
La storia che ci raccontarono era che l’approccio Agile allo sviluppo software avrebbe favorito la Business Agility, ovvero:
- rispondere facilmente ai cambiamenti di mercato anche sui progetti in corsa
- massima trasparenza verso il committente del progetto, che ha bisogno di vedere cosa si sta sviluppando per decidere come continuare
- rilasci continui di software funzionante in produzione ogni iterazione
I 4 principi fondamentali di Agile
La sperimentazione con un progetto pilota della storia che ci avevano raccontato cambiò radicalmente la prospettiva di cos’era veramente importante: la sensazione iniziale fu più o meno quella che immagino si provi quando ci cambiano una regola fondamentale come la gravità.
Toccammo con mano l’importanza di quello che il Manifesto Agile definisce principi fondamentali:
- Gli individui e le interazioni più che i processi e gli strumenti
- Il software funzionante più che la documentazione esaustiva
- La collaborazione col cliente più che la negoziazione dei contratti
- Rispondere al cambiamento più che seguire un piano
Attenzione: la prima parte di ogni frase (es. gli individui e le interazioni) non esclude la seconda (i processi e gli strumenti), ma semplicemente ne evidenzia un peso diverso in termini di importanza.
Gli individui e le interazioni più che i processi e gli strumenti
“Cioè mi state dicendo che tutto il tempo che abbiamo passato a regolamentare la comunicazione fra i reparti, gli strumenti che abbiamo aggiunto e implementato per comunicare meglio, i vari protocolli, gli ingaggi, ecc…. mi state dicendo quindi che è più importante interagire?”
All’inizio sembrava folle, ma ci obbligammo a “rubare” una persona da ogni reparto e a formare un team crossfunzionale, ovvero un team con tutti gli skill e i mestieri necessari a completare il progetto. Nel nostro caso si parlava di sviluppatori, UX designer, sistemisti, tester e poi i ruoli “nuovi” ovvero Product Owner e Scrum Master.
Non c’erano più problemi di comunicazione: nessuno aveva altro da fare, nessun progetto parallelo per i quali “non eri la priorità”. Si guardava tutti nella stessa direzione, si discuteva e si lavorava tutti allo stesso progetto per tutto il tempo. Non c’erano dubbi su quali fossero le priorità di oggi, perché il backlog era chiaro e non c’erano accavallamenti.
Tutti i problemi di comunicazione, tutto quello che cercavamo di gestire solo con strumenti e processi, era stato risolto ribaltando l’organizzazione.
Il software funzionante più che la documentazione esaustiva
L’impossibilità di poter toccare con mano del “software funzionante” durante lo sviluppo era la cosa che come Project Manager avevo sofferto di più.
Sono sempre stato un tecnico ed ho lavorato sempre dalla parte di chi costruiva le piattaforme, avendo ben chiaro quanto tempo ci volesse a costruire una piattaforma. Una volta passato dalla parte di chi gestisce il progetto, non riuscire a capire veramente (e sottolineo veramente) a che punto fosse un progetto era estremamente frustrante. Racconto sempre un aneddoto di un progetto che, secondo uno sviluppatore, è stato per un paio di mesi al 99%…
Agile introduce il principio della trasparenza. Sia il cliente (interno o esterno), sia il Product Owner devono essere in grado di toccare con mano lo stato di sviluppo del progetto, la bontà di quello che si sta sviluppando. Si può davvero dopo un mese o due vedere del software funzionante di un nuovo progetto in produzione? Si può ed è una grande soddisfazione.
A cosa serve vedere software funzionante per esempio durante le Product Review di Scrum? Per esempio per accorgersi il prima possibile:
- se lo sviluppo ha preso una piega non desiderata dal cliente
- se una funzionalità è stata mal interpretata e può essere corretta
- se per qualche motivo alcune funzionalità richiedono un approccio diverso per cambiamenti di mercato
- se il cliente vuol anticipare alcune funzionalità non previste nelle prossime iterazioni
- se il cliente semplicemente vuol cambiare alcune cose
- se ci si era capiti male in fase di definizione del progetto
- altri mille motivi che si sperimentano durante le Product Review quando si dice “menomale che ce ne siamo accorti adesso“
E la documentazione? Mentre per le metodologie classiche la documentazione è fondamentale ed è estremamente dettagliata e regolamentata, in Agile la documentazione è quella “sufficiente” per descrivere il progetto e il codice, ed è costruita in maniera incrementale via via che si rilasciano le funzionalità. Non ci sarà il librone da stampare a fine progetto, ma ogni cosa sarà documentata a dovere durante le varie iterazioni.
La collaborazione col cliente più che la negoziazione dei contratti
Sono il solo ad aver avuto l’esperienza di decine di progetti che sono stati pubblicati molto diversi, nella sostanza, da quello che il cliente o committente voleva? Non credo. Tuttavia è normale che succeda, soprattutto su progetti che richiedono mesi o anni di sviluppo. E poi diventa impossibile modificare il progetto perché chi dovrebbe modificare le funzionalità sta già lavorando su altro.
E’ un approccio che mi è sempre sembrato estremamente egoistico e per niente customer-oriented: si stende una documentazione, la si fa firmare al cliente quasi a dirgli “io sviluppo questo, se cambi idea arrangiati”, si tiene il progetto sotto terra (letteralmente) per mesi e poi si esce statisticamente con qualcosa di diverso da quello che si era pianificato.
Ve la fareste costruire una casa da zero soltanto sul capitolato e sul progetto? Non vi verrebbe voglia di andarla a vedere ogni tanto mentre la costruiscono e proporre degli aggiustamenti? Non so voi, ma io l’ho fatto ed è stato un bene per la mia casa. NB: ammetto che l’esempio della casa non è buono dal lato dello sviluppo incrementale, ma lo è come scambio continuo di feedback fra committente e costruttore.
Al cliente (interno o esterno) non interessa bloccare le funzionalità in una documentazione esaustiva ed estremamente dettagliata, se non lo si obbliga a farlo. Il cliente desidera avere un prodotto che risponda alle sue esigenze e che lo aiuti nel progetto di business del quale il software è solo una parte.
Rispondere al cambiamento più che seguire un piano
Qui c’è l’essenza di Agile.
Da dove arriva il cambiamento? a quale cambiamento c’è bisogno di rispondere?
Prima di tutto il cambiamento arriva dal mercato. Una progettazione fatta 1 o 2 anni prima del rilascio vero e proprio può incontrare un mercato completamente diverso o comunque evoluto che mette in discussione tutti gli assunti fatti nel business case che si trova a corredo dei progetti.
E poi ci sono cambiamenti richiesti dal cliente per svariati motivi: è normale ad esempio che un rilascio di una prima versione faccia emergere feedback dal mercato che stimolano il Product Owner o il cliente a cambiare la pianificazione dei rilasci, per approfondire una feature in particolare, per tagliarne alcune ritenute dai primi user come meno rilevanti e rilasciare prima del tempo previsto, per fare pivot e dirigere il prodotto in una direzione nuova.
Nello sviluppo tradizionale purtroppo cambiare non è facile, se non con costi molto alti e con ritardi nel rilascio difficilmente quantificabili.
L’approccio iterativo-incrementale
E’ la chiave che abilita tutte le cose belle che ho detto fino ad ora. Chi ha concepito lo sviluppo Agile si è accorto che l’unico modo per ottenere la Business Agility era quello di riuscire a rilasciare funzionalità in maniera continuativa: non mockup, non schemi, non pezzi di codice, ma software funzionante in produzione.
E quindi come si fa a rilasciare un pezzo di software completo e funzionante in 15-30 giorni? Si condensa il ciclo di sviluppo tradizionale analisi-progettazione-sviluppo-test-rilascio, che normalmente dura N mesi per ogni fase, in piccole iterazioni il cui oggetto è un subset di funzionalità.
Detta così sembra semplice, ma nella pratica non lo è.
Prima di tutto è necessario avere un forte desiderio di cambiare, di liberarsi di quei “si è sempre fatto così”, di ammettere che c’è bisogno di chiedere aiuto anche all’esterno. Il desiderio porta a cercare soluzioni per evolvere. L’approdo ad Agile è facile e si trovano moltissime informazioni al riguardo. L’adozione invece richiede un cambiamento di mindset e di cultura e deve essere necessariamente sponsorizzato da coloro che beneficeranno della Business Agility, ovvero dalla direzione. Qualsiasi implementazione di Agile che non porta benefici ai vertici dell’azienda è puro esercizio di stile.