Che cosa significa essere “agile”? Persone, software e collaborazione. Dopo quasi venticinque anni di lavoro, il metodo “agile” si è ormai consolidato. Ma il cambiamento resta l’unica regola
Prima del noto Agile Manifesto, abbiamo lavorato tutti in questo ambito. Nel mio caso, si trattava del Dynamic Systems Development Method (il DSDM, ora conosciuto come “Agile Project Management Framework”): alla fine degli anni Novanta, era abbastanza popolare ed era molto utilizzato da banche, enti pubblici e fornitori IT di Benelux, Regno Unito, Svezia e Danimarca, oltre a essere sperimentato in Australia, Francia, India e altri paesi.
In un certo senso, il Manifesto ha creato un centro attorno al quale abbiamo potuto condividere e imparare. Ogni metodo ha la propria comunità (o più di una), e a mio parere è molto saggio mettere insieme gli insegnamenti migliori che provengono da tutte le persone che ne fanno parte.
Quando parlo ai miei clienti di approccio “agile” al project management, tendo a concentrarmi su cinque punti chiave fondamentali: la qualità del codice, le dinamiche di gruppo, la visualizzazione, la gestione dei carichi di lavoro e i team di collegamento per i progetti più ampi. Vediamo in dettaglio di che cosa si tratta.
La qualità del codice
Questo punto per me è essenziale. Spesso le persone scambiano la parola “agile” con una scusa per non operare correttamente. L’auto-organizzazione è spesso usata come una frase per tenere fuori le persone e non condividere le informazioni. Soluzioni instabili, un sacco di problemi e clienti insoddisfatti sono le conseguenze. La trasparenza è un fattore decisivo di successo per essere “agile”. Mi piace mettere in atto le pratiche di Extreme Programming come lo sviluppo test driven, la programmazione a coppia e il refactoring. Queste pratiche evitano uno dei maggiori rischi in un team: l’isolamento delle conoscenze. E se applicate con la giusta disciplina e qualità, queste pratiche portano a prodotti buoni e stabili. Nel nostro stabilimento, facciamo molto affidamento su questi metodi, con il risultato concreto di avere efficienza e continuità nella produzione senza incidenti o interruzioni.
Le dinamiche di gruppo
Per raggiungere questo risultato e fare in modo che ogni cosa sia al posto giusto e funzioni correttamente è necessario facilitare le dinamiche che nascono e si sviluppano all’interno di gruppi di lavoro in grado di autoregolarsi. Naturalmente, bisogna essere capaci di comprendere i diversi stili di apprendimento individuali. Una volta che si ha familiarità con questi concetti, Scrum è davvero utile con i giornalieri, le schede di programma, le sessioni di discussione e valutazione (planning poker), gli incontri di riflessione e altro ancora: in questo modo si può aiutare il team di lavoro a fare il punto della situazione e a comprendere dove ci si trova come squadra e come bisogna procedere per continuare a progredire nel processo di apprendimento e di miglioramento.
La visualizzazione
A essere onesti non so dove o quando tutto questo ha avuto inizio. In effetti, ho fatto questo per tutta la mia vita “agile” (dal 1994, grazie a Willem Thielsch). Ho iniziato un po’ improvvisando nelle mie prime sessioni del 1994 e ho scoperto rapidamente i vantaggi della visualizzazione. Tutti conosciamo la scheda di programma dal framework di KanBan, come implementata in Scrum, ma c’è molto di più da visualizzare. Il valore di immagazzinare le informazioni si deve confrontare con la necessità di accedere ai dati in modo sicuro ed efficiente, evitando di lavorare in silos rispetto all’end-to-end, di mischiare le diverse versioni dei documenti oppure di congelare le informazioni invece di accettare il cambiamento dei requisiti come un dato di fatto. E oltre il cambiamento, bisogna assumersi anche le proprie responsabilità rispetto al team. Fare uso di modelli per la visualizzazione grafica dei dati si può rivelare davvero utile.
La gestione dei carichi di lavoro
Soprattutto per i team coinvolti in qualcosa di più oltre allo sviluppo (lavoro supplementare come le operazioni, il supporto, etc.), è necessario supportare la squadra per gestire l’imprevedibile. In questo modo, essi dovranno occuparsi non solo del lavoro che si sono impegnati a seguire come squadra, ma anche del lavoro in più che non può essere previsto, come i ticket, gli incidenti e quant’altro. Le pratiche KanBan con corsie preferenziali e la massimizzazione del WIP si sono dimostrate efficaci per risolvere questo tipo di esigenze, e io le consiglio spesso.
Team di collegamento
E poi abbiamo la vastità del prodotto da realizzare, che è qualcosa che ha un impatto sul modo in cui ci si avvicina allo sviluppo. Che ci piaccia o no, spesso abbiamo scadenze che dobbiamo rispettare per realizzare soluzioni complete di ampie dimensioni. Non sto parlando solo dello sviluppo e della fornitura di software, ma anche di fornire singoli moduli di soluzioni complete tra cui il cambiamento organizzativo, i percorsi di audit, il training di utenti finali, le migrazioni di dati, le infrastrutture e infine la comunicazione e il marketing.
Come si fa a fare tutto questo e riuscire a mantenere ugualmente la trasparenza? Ci sono due componenti importanti per creare non solo un efficiente e condiviso punto di partenza per lo sviluppo, ma anche per tenere sincronizzate tutte le persone coinvolte durante lo sviluppo.
A questo scopo, trovo ancora un buon aiuto nelle pratiche di base di DSDM/AgilePM. In un paio di settimane (o in 1 o 2 sprint, se vi piace) di “lavoro agile” in piena regola, si crea un punto di partenza sincronizzato per gruppi fino a 70 persone o più, diviso in squadre parallele.
Quello che mi piace in particolare nelle pratiche di Agile Project Management (AgilePM) è il modo semplice per la selezione o la de-selezione dei requisiti, compresi quelli non funzionali.
Oltre il metodo
L’AgilePM ha un focus preciso sui bisogni di business e riguarda non solo il modo di lavorare, ma anche di coinvolgere tutti gli stakeholder, che è qualcosa di più del solo sviluppo e delle operations. Una delle cose che riutilizzo dallo Scaling Agile Framework (SAFe), sono le grandi sessioni di pianificazione: per me si tratta di una messa a punto perfetta delle pratiche di base per trasformare le organizzazioni e per sincronizzare tutte le persone coinvolte in modo da rispondere al cambiamento. Dopo aver dedicato tanto tempo alla spiegazione dei diversi metodi, vorrei dire – però – che le regole stesse non hanno più grandissima importanza. Non solo perché sono destinate a cambiare nel tempo, ma soprattutto perché l’innovazione si svilupperà all’interno delle comunità. L’applicazione pratica sarà un assemblaggio degli aspetti dei metodi più utili a soddisfare al meglio le esigenze delle organizzazioni. In pochi mesi, le cose cambiano, dettando nuove esigenze e bisogna essere in grado di adattarsi. Dopo tutto, è proprio questo che significa essere “agile”.
Arie Van Bennekum
Tra gli autori dell’Agile Manifesto, presiede l’Agile Consortium International. Pragmatico e con i piedi ben piantati per terra, incorpora i suoi principi di management nella struttura, nella disciplina e nel senso comune. Tra i massimi esperti di facilitazione dei team e di engagement degli utenti, è ancora molto attivo nell’area dello sviluppo di soluzioni “agile”, in cui opera da circa 20 anni. Credere nel team, aiutandolo a ottenere il massimo con il coinvolgimento dell’utente finale, è il suo focus quando parla, presenta, dimostra e insegna “agile”.
Arie van Bennekum ha presentato a Roma per Technology Transfer il seminario “Agile Project Management con Certificazione” il 16-17 novembre 2015.
