Cos'è l'agile? Una filosofia che si sviluppa attraverso la pratica

Originariamente concepito per i team di sviluppo software, Agile è ora il principale approccio di gestione dei progetti per le industrie e le aziende di tutto il mondo. Il fascino sta nella sua semplicità e flessibilità: la mancanza di pratiche prescrittive di Agile lo rende altamente adottabile. Eppure, guidando le trasformazioni Agile in diverse aziende, ho scoperto che questa flessibilità si traduce anche in idee sbagliate su cosa significhi essere Agile. Molte aziende danno la priorità all'adesione a framework derivati ​​da Agile rispetto alla comprensione della filosofia stessa.

Invece, i project manager e gli allenatori che assemblano e guidano i team Agile dovrebbero iniziare addestrandoli ad adottare una mentalità Agile, essenzialmente interiorizzando i valori ei principi fondamentali della filosofia. Solo allora dovrebbero combinare, personalizzare o omettere le pratiche dai framework Agile in base a ciò che soddisfa al meglio i requisiti del progetto.

Tracciando lo sviluppo storico di Agile e legando i suoi principi fondanti alle esigenze specifiche di aziende e team, questo articolo può aiutare i project manager a creare un futuro ottimale per le trasformazioni Agile. Come dimostrano i seguenti casi, Agile non dovrebbe essere considerato strettamente come un approccio di gestione del progetto, ma piuttosto una filosofia di sviluppo del prodotto in continua evoluzione nella pratica.

Antecedenti agili

Compilato per la prima volta nel 2001, il "Manifesto for Agile Software Development", una succinta raccolta di quattro valori fondamentali e 12 principi, è stata una risposta radicale ad approcci lineari e pesanti, carichi di regole e risme di documentazione. Ma la storia di Agile è nata decenni prima con un metodo per razionalizzare la produzione industriale.

Un antecedente della filosofia per il suo focus sul miglioramento iterativo, il modello Plan-Do-Study-Act è stato sviluppato negli anni '30 dal fisico e statistico dei Bell Labs Walter Shewhart. Dopo la seconda guerra mondiale, il suo protetto, W. Edwards Deming, lo applicò alla formazione dei dirigenti della Toyota. Il metodo è stato parte integrante dello sviluppo del Toyota Production System, la principale fonte del pensiero snello con il suo efficiente ciclo di costruzione-misura-apprendimento.

Negli anni '70, il concetto è stato ulteriormente sviluppato quando Barry Boehm ha proposto la tecnica Wideband Delphi, utilizzando un processo iterativo per stimare in modo accurato e oggettivo il lavoro e il tempo necessari per sviluppare il software.

Con la proliferazione dei personal computer a metà degli anni '80, è diventato chiaro che il software come prodotto e servizio sarebbe diventato la pietra angolare del modo in cui le persone fanno affari. Quando i professionisti hanno iniziato a prestare seria attenzione agli approcci incrementali e iterativi all'ingegneria del software, Agile ha superato i processi Waterfall come approccio di sviluppo e gestione superiore.

I ricercatori hanno scoperto che i produttori che stavano innovando più rapidamente dei loro concorrenti stavano utilizzando un metodo multidisciplinare orientato al team per spostare un prodotto lungo il suo ciclo di vita. Questo è ampiamente considerato come l'ispirazione di Jeff Sutherland per l'invenzione del framework Scrum nel 1993, che gli ha permesso di completare progetti apparentemente impossibili nei tempi previsti e sotto budget, con bug minimi.

I valori agili in teoria, che emergono da questi antecedenti, sono stati confermati dal mio uso pratico di Agile, con un'enfasi sullo sviluppo iterativo, sul lavoro di squadra collaborativo e sulla stima accurata.

Che cos'è l'agile in teoria?

Man mano che le aziende continuano ad adottare modalità di lavoro Agile, rischiano di renderle più prescrittive di quanto mai previsto dagli artefici della filosofia. In base alla mia esperienza, i leader che desiderano adottare Agile si concentrano troppo sulle strutture o sugli insiemi di pratiche specifiche e sulla nomenclatura associata e non abbastanza sui valori e sui principi.

Come ben sanno i professionisti che sono avanzati nell'impartire i principi Agile, ogni organizzazione che cerca di subire una trasformazione Agile deve trovare e adattare gli approcci che gli si addicono. Facilito questo processo di apprendimento mostrando ai team come seguire i valori e i principi del manifesto e poi traendo ispirazione dai framework, come Scrum, Kanban ed Extreme Programming (XP), per implementarli nella pratica.

I principi del manifesto sono ormai una seconda natura per i project manager Agile:

1. Individui e interazioni su processi e strumenti
2. Prodotti di lavoro su documentazione completa
3. Collaborazione con il cliente nella negoziazione del contratto
4. Rispondere al cambiamento seguendo un piano

L'avvertenza che segue questi principi nel manifesto, tuttavia, viene spesso trascurata: "Cioè, mentre c'è valore negli elementi a destra, apprezziamo di più gli elementi a sinistra". Molti praticanti Agile finiscono per ignorare i valori di destra e concentrarsi solo su ciò che è a sinistra. Il risultato? L'opposto di seguire ciecamente strutture di processo pesanti: nessun processo, il che è ugualmente problematico.

Trovare il giusto equilibrio tra gli elementi a destra e a sinistra è diventata la chiave per guidare le trasformazioni Agile. È anche esemplificato dagli approcci di gestione di Apple, Google, Amazon, Facebook e Netflix, nessuno dei quali ha sottoscritto un unico framework Agile. Hanno incarnato innanzitutto i principi del manifesto, seguendo o modificando parti di strutture diverse in base a ciò che ha funzionato meglio per loro; di conseguenza, si sono adattati ai cambiamenti del mercato e sono in grado di fornire rapidamente nuovi prodotti.

Che cos'è l'agile in pratica?

Nella panoramica seguente, ho modificato la formulazione originale dei valori del manifesto. Le modifiche alla semantica aiutano a chiarire come applico i valori Agile nella pratica.

Nel primo valore sostituisco il termine “individui” con “persone” perché essere agili significa essere orientati al team. Per quanto riguarda il secondo, è ovvio che il software deve "funzionare", quindi l'attenzione ora è rivolta a una "consegna" tempestiva e di successo. Il terzo valore è semplicemente la "collaborazione", poiché si applica allo stesso modo ai colleghi che lavorano insieme e ai team che lavorano con i clienti. Infine, "quadri" sostituisce "seguire un piano", perché questo previene l'equivoco che la pianificazione dovrebbe essere abbandonata del tutto.

Persone oltre i processi

Le trasformazioni agili sono difficili, principalmente perché la maggior parte delle aziende è così abituata a seguire rigorosamente i processi. Completare un certo numero di passaggi con un determinato set di strumenti, invece di sviluppare un prodotto innovativo, diventa l'obiettivo finale.

Sono rimasto costernato nel vedere questa mentalità dare origine a un redditizio "settore agile". Come spiegano i fondatori di Agile Ward Cunningham e Jon Kern, molte aziende vendono software che secondo loro aiuteranno le aziende a "diventare Agile". Ma andare Agile significa adottare una filosofia, non usare software e seguire il programma che prescrive.

Raggiungere il giusto equilibrio non significa eliminare le procedure, ma piuttosto trovare quelle che meglio supportano gli obiettivi di sviluppo di ciascun team. Per uno dei miei clienti, una grande organizzazione tecnologica aziendale, ho implementato Disciplined Agile, un approccio sviluppato in IBM. Combina molte pratiche da più framework, inclusi Scrum e Kanban. Utilizza lo sviluppo iterativo ma è un po' più pesante di processi rispetto all'Agile tradizionale, specialmente nella fase iniziale, perché ha lo scopo di colmare le lacune lasciate da Scrum. Disciplined Agile ha lavorato per questo cliente perché l'organizzazione era molto orientata ai processi. Mi ha permesso di incontrare i team a metà strada, ottenere il loro consenso e convincerli ad adottare un flusso di lavoro Scrum.

Ho incorporato riunioni di perfezionamento del backlog, riunioni di revisione e scrum giornalieri per facilitare la collaborazione all'interno e tra i team. Il raffinamento del backlog fa parte della Scrum Guide, ma le riunioni di perfezionamento non lo sono. Li ho aggiunti per consentire una sana conversazione sul motivo per cui abbiamo pianificato di implementare funzionalità specifiche nei prossimi sprint, il che è utile per i principianti Agile. Ho anche scelto la nomenclatura "pietre miliari" - un termine usato nella gestione dei progetti Waterfall - perché era più familiare al cliente. Le recensioni e le interazioni giornaliere di Scrum sono elementi convenzionali della Guida Scrum, ma li ho resi più strutturati in termini di programma, durata e flusso.

Inoltre, mentre una stretta aderenza a Scrum farebbe sì che ogni persona si dedichi completamente a uno dei ruoli elencati nella Guida Scrum, c'erano persone nei team dei miei clienti le cui competenze non si adattavano perfettamente a un ruolo. L'utilizzo del metodo Disciplined Agile mi ha permesso di dividere le responsabilità di queste posizioni tra più membri del team e creare un processo che giocasse sui punti di forza delle persone coinvolte.

Consegna del software su documentazione

Un altro motivo per cui preferisco flussi di lavoro Scrum o Kanban personalizzati rispetto al rigoroso rispetto di qualsiasi framework è che mi danno l'opportunità di aggiungere il prodotto minimo praticabile (MVP) nel piano come obiettivo. Derivato da Lean, la pratica di creare un MVP è coerente con lo sviluppo iterativo ed è diventata una tecnica popolare tra i professionisti Agile. Consente a un team di fornire software di alta qualità e altri beni agli utenti in modo efficiente e quindi perfezionarli in base al feedback. Applicarlo come parte di un approccio ibrido in gran parte basato su Scrum o Kanban ha migliorato le capacità dei miei team di creare prodotti che soddisfano le esigenze dei clienti.

Attualmente sto lavorando con una startup con sede negli Stati Uniti e sto utilizzando questo metodo per creare un mercato di criptovalute per NFT. Ci stiamo concentrando sulla creazione dell'MVP, quindi per ora stiamo scrivendo solo la documentazione minima necessaria. Sebbene questo approccio sia efficace per un'ampia gamma di prodotti, è particolarmente utile per criptovalute e NFT, che sono in una nuova categoria sperimentale che sta cambiando rapidamente. Invece di redigere specifiche e funzionalità complete e doverle modificare ripetutamente prima del rilascio, possiamo dedicare quel tempo a incorporare il feedback degli utenti per migliorare lo sviluppo del nostro mercato.

Collaborazione sui contratti

La suddetta organizzazione tecnologica per grandi imprese faceva molto affidamento sui contratti per molti progetti a costo fisso. I contratti delineavano i metodi che avrebbero utilizzato per completare il lavoro, nonché le persone specifiche che sarebbero state responsabili di ogni compito. Una volta firmati, i contratti non potevano essere modificati senza un lungo processo di richiesta.

Parte della trasformazione ho guidato la collaborazione prioritaria rispetto a questi rigidi accordi. Il piano che abbiamo implementato ha sostituito i contratti con documenti di una pagina. Ciascuno ha affermato di aver accettato di utilizzare Agile per lavorare in collaborazione, con i nostri clienti, nonché con i nostri compagni di squadra e colleghi di team diversi, tra le date di inizio e di fine designate. Qualunque cosa venisse fuori dalla collaborazione sarebbe il risultato. Non ho incluso i dettagli su quali potrebbero essere i prodotti finiti. Poiché richiedevamo il feedback dei clienti e lo incorporavamo nello sviluppo del nostro prodotto, la rimozione delle specifiche dal documento del nostro piano ci ha reso più ricettivi alle loro risposte e li ha incentivati ​​a lavorare con noi in modo più attivo.

Per coinvolgere la direzione, ho chiesto loro di farmi condurre una prova di concetto con un piccolo team che lavorava con un piccolo cliente, che aveva espresso preoccupazione per i tempi di sviluppo troppo lunghi, anche prima che le modifiche richieste aggravassero il problema. Facendo collaborare questo cliente direttamente con il nostro Product Owner, siamo stati in grado di apportare modifiche a metà sviluppo e ridurre significativamente i tempi di consegna.

Questi risultati hanno convinto la direzione a farmi distribuire il piano a più team. Nel complesso, il contratto semplificato e il nostro flusso di lavoro Agile hanno ridotto il tempo necessario per sviluppare e immettere sul mercato le funzionalità del prodotto.

Adattabilità rispetto ai framework

Anche un altro mio cliente, un'azienda di tecnologia sanitaria, non è riuscito a trovare un equilibrio in termini di riconoscimento dell'importanza di entrambi i lati di un valore Agile, vale a dire rispondere al cambiamento seguendo un piano. In questo caso, tuttavia, aveva commesso l'opposto dell'errore commesso dal mio cliente di tecnologia aziendale: invece di seguire un processo troppo rigidamente, aveva sovraindicizzato sulla flessibilità, trascurando in gran parte il processo. Gli ingegneri raramente sapevano su cosa avrebbero dovuto lavorare perché non c'erano priorità o pianificazione. Hanno perso tempo e produttività cercando di capirlo ogni giorno e hanno completato compiti meno importanti prima di quelli più cruciali.

Ho proposto l'implementazione di Scrum al CEO e al CTO, spiegando che gli sprint costringerebbero gli ingegneri a essere disciplinati ea pianificare con incrementi di due settimane, invece di decidere su cosa lavorare ogni giorno. Inoltre, ho consigliato loro di assumere un product owner, il che avrebbe risolto la mancanza di responsabilità del prodotto da parte del team. Ho chiesto ai dirigenti di darmi tre o quattro mesi per lavorare con i loro team prima che potessero aspettarsi di vedere i risultati.

Dopo aver ottenuto la loro approvazione, ho prima introdotto i valori e i principi Agile, quindi ho formato il team sul product backlog e sulle diverse tecniche per organizzarlo, inclusa la creazione di epiche e storie degli utenti e la creazione di attività secondarie. Le tecniche e le riunioni che abbiamo incluso nel nostro flusso di lavoro sono deviazioni dallo Scrum tradizionale in quanto non compaiono nella Guida Scrum. Li ho integrati nel piano perché i poemi epici, le storie e le attività secondarie hanno risuonato con i team durante la formazione e gli incontri hanno promosso discussioni produttive.

Ho incluso anche il concetto di velocità, un'ultima aggiunta a XP che misura le stime del totale dello sforzo per tutte le storie degli utenti in ogni iterazione del prodotto. Tuttavia, ho usato il termine "capacità", che preferisco perché enfatizza la quantità di lavoro che i membri del team possono raccogliere piuttosto che la velocità con cui possono completare le attività.

Per stima, ho iniziato con la taglia delle magliette, una tecnica che misura progetti e compiti come piccoli, medi e grandi; man mano che il team progrediva, sono passato agli story point, una tecnica di stima più tradizionale. I punti della storia vengono spesso utilizzati in modo improprio da team non iniziati in Agile, che cercano di convertirli in ore o giorni di lavoro, concentrandosi eccessivamente sui tempi e giudicando le persone in base alla loro capacità di rispettare le scadenze.

La taglia della maglietta è più astratta, rendendo più facile per le squadre evitare questa trappola. Tuttavia, è anche meno preciso. Quindi, una volta che il team ha capito come stimare in termini relativi, sono passato alla tecnica più sofisticata.

Quando il team ha completato due sprint, il senior management è stato in grado di vedere i propri dipendenti lavorare in modo più produttivo e comunicare in modo più efficace. Gli sviluppatori si sono confrontati per la prima volta con le parti interessate e la direzione esecutiva. Avevano incontrato il team di assistenza clienti e avevano compreso come le funzionalità che avevano implementato migliorassero la vita degli utenti.

Questo approccio ha portato presto a un aumento della qualità del software dell'azienda ea una riduzione dei tempi di consegna delle nuove funzionalità da mesi a settimane.

Qual è il futuro di Agile?

La pandemia di COVID-19 ha creato una nuova realtà in cui i team non potevano più essere co-localizzati, che era il modo preferito di lavorare all'interno di Agile quando è stato concepito. Tuttavia, l'idea che debba rimanere così è un mito: poiché il lavoro a distanza è diventato un luogo comune, è diventato chiaro che una stretta comunicazione è del tutto possibile con i software di videoconferenza. I team con cui lavoro ora sono completamente distribuiti e sto offrendo formazione da remoto. Alcuni team stanno anche optando per lavorare in modo asincrono, utilizzando strumenti come Notion e Loom, oltre a plug-in Slack come Standuply.

Il modello distribuito di collaborazione è il nuovo mondo del lavoro, con l'agilità al centro. L'equilibrio tra lavoro e vita privata offerto ai team remoti ha un impatto positivo sul morale e sul benessere mentale, aumentando la produttività e la qualità; mette le persone al di sopra dei processi ed è flessibile e adattabile, il che lo rende essenzialmente agile.

Coach agili, Scrum master e project manager dovrebbero tornare alle radici della filosofia e presentarla come hanno fatto i creatori del manifesto: un insieme flessibile e dinamico di linee guida di sviluppo e consegna. Dovrebbero insegnare ai dirigenti e ai team leader che, sebbene possano trarre ispirazione dalla gestione dei progetti, in realtà non stanno gestendo nulla in Agile: stanno guidando i team e li liberano per svolgere al meglio il proprio lavoro.