Agile: la chiave per la digital transformation e la crescita aziendale

Sentiamo sempre più spesso parlare di Agile, un approccio nato nel mondo del software che si sta via via affermando anche in altri contesti. Grazie a questo approccio, aziende e persone acquisiscono le regole e gli strumenti più adatti ad affrontare i cambiamenti.
Vediamo in questo articolo quali sono le origini di questo approccio e alcuni esempi pratici di applicazione.

Il Manifesto Agile

Il Manifesto Agile nasce nel 2001 dalla collaborazione di 17 professionisti del software.
Il loro obiettivo era quello di definire i valori e i principi alla base dello sviluppo software in un contesto in continua evoluzione. Il manifesto si pone in contrapposizione ai metodi classici che non sempre si erano rivelati efficaci, e vuole proporre una nuova visione di organizzazione dei processi di lavoro.
La metodologia agile si applica principalmente ai contesti di sviluppo software e, più precisamente, ai processi dei team di sviluppo, ma si è rivelata efficace anche in altri ambiti dove si è potuto trarre ispirazione dai valori espressi nel Manifesto Agile.

Cosa dicono i 4 valori del Manifesto Agile

1. Gli individui e le interazioni più che i processi e gli strumenti
   I processi emergono dalle interazioni tra le persone durante il lavoro quotidiano. Gli strumenti semplificano e agevolano queste interazioni. Non si parte quindi dai processi o dagli strumenti per introdurre l‘agilità, ma dalla costante analisi e continuo miglioramento di come le persone lavorano tra di loro. L’agilità è una questione di continuo miglioramento culturale.
2. Il software funzionante più che la documentazione esaustiva
   La vera misura dello stato di avanzamento di un progetto è il valore generato e lo si può misurare solo con il software funzionante. I feedback si raccolgono meglio e sono più veritieri se si vede il software che funziona rispetto ad un power point o un gantt. La documentazione supporta lo sviluppo del software funzionante e deve essere il più sintetico possibile per poter essere sempre aggiornata con il minimo sforzo. La prima documentazione è il codice e deve ispirarsi ai Principi di Clean Code.
3. La collaborazione col cliente più che la negoziazione dei contratti
   Cliente e fornitore hanno successo se generano valore per entrambi. Per questo è importante lavorare a stretto contatto in un contesto chiaro e ben regolato. Il contratto non deve essere un vincolo ma una trascrizione delle regole di lavoro che ci si è dati.
4. Rispondere al cambiamento più che seguire un piano
   Rispondere al cambiamento non significa dire sempre sì al cambiamento ma dire sì al cambiamento che porta valore agli utenti finali. Si tratta di una continua pianificazione. Più la pianificazione è lontana, più sappiamo che sarà imprecisa. Più la pianificazione viene fatta sul breve termine, più dovrebbe essere stabile. Ad ogni incremento rilasciato si impara qualcosa di nuovo e si aggiusta la pianificazione.

I principi del Manifesto Agile

Oltre ai quattro valori menzionati sopra, esistono anche i 12 principi del Manifesto Agile, di cui lasciamo la lettura a questo link.
Di questi dodici vogliamo però sottolineare quelli che consideriamo più rilevanti per il nostro modo di lavorare, di cui parleremo nei paragrafi seguenti:

• Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team.
• La semplicità – l’arte di massimizzare la quantità di lavoro non svolto – è essenziale.
• Le architetture, i requisiti e la progettazione migliori emergono da team che si auto-organizzano.

Benefici della metodologia Agile

L’Agile, come precedentemente accennato, è un approccio allo sviluppo software nato in contrapposizione ai metodi tradizionali. Uno dei più conosciuti è quello a Cascata (o Waterfall). Secondo il metodo Waterfall, lo sviluppo software può avvenire in maniera sequenziale per arrivare alla realizzazione dei requisiti che sono stati definiti all’inizio del processo.

Il metodo a cascata, quindi, prevede che il team di sviluppo riceva tutte le specifiche a inizio progetto e che consegni il prodotto finito nel passaggio successivo, senza una revisione durante gli step e senza tenere conto di possibili cambiamenti o variabili che possono introdursi durante il percorso.

Questo metodo presenta diversi limiti. Il principale è che risulta molto difficile fornire al team di sviluppo tutte le specifiche necessarie prima dell’inizio del progetto ed essere poi sicuri che verranno rispettate fino alla fine. Quello che capita solitamente è che tanti aspetti che concorrono alla buona riuscita del progetto e al rilascio ottimale di un prodotto, emergono solamente nelle fasi successive e a seguito di test e confronti sia all’interno del team che tra il team e il cliente. Ma non è solo questo il limite dell’approccio a cascata. Sono diverse le problematiche che emergono durante la gestione di un progetto che questo tipo di approccio difficilmente prende in considerazione. Possiamo citarne alcune:

• Mancanza della gestione del cambiamento dei requisiti;
• Comunicazione poco efficace;
• Inadeguatezza delle competenze all’interno del Team;
• Requisiti non ben definiti;
• Stime non accurate;
• Mancanza di un piano di gestione dei Rischi;
• Basso allineamento sulla definizione di cosa significa “Finito”;
• Tempo dedicato alla gestione del progetto non sufficiente;
• Bassa conoscenza di come si gestisce un progetto.

Come si può comprendere attraverso i valori e i principi del Manifesto, la metodologia Agile si pone quindi l’obiettivo di risolvere, o comunque di gestire, questo tipo di problematiche che possono emergere potenzialmente in qualsiasi progetto. La metodologia Agile fonda le sue radici nel concetto di miglioramento continuo: la possibilità di rivedere in diversi momenti sia le specifiche iniziali sia le variazioni che sono emerse durante lo sviluppo.
Si basa infatti sul ciclo di deming: una serie di passaggi che permettono di rimodulare, correggere, testare ciò su cui stiamo lavorando. Il ciclo di deming è formato da quattro momenti: plan, do, check, act, che permettono di arrivare allo sviluppo di un prodotto incrementale che tiene conto di continui test anche con il cliente finale.

Questa immagine è di AgileReloaded.

Alla luce di queste riflessioni e della forte diffusione ed efficacia che ormai può vantare la metodologia Agile, possiamo definire alcuni benefici derivanti dall’adozione di questo approccio:

• Riduzione dei costi: poter verificare continuamente l’evoluzione del progetto permette di attuare le modifiche necessarie quando si è ancora in corsa ed evitare di dover apportare grossi, e costosi, cambiamenti solo una volta concluso il progetto;
• Maggiore collaborazione: questa metodologia incentiva il confronto continuo sia all’interno del team che tra team e cliente;
• Maggiore fiducia: la possibilità di fare continui test e di poter partecipare attivamente e consapevolmente a tutti gli step del progetto, permette a tutte le persone coinvolte di avere maggiore fiducia nel lavoro dei propri colleghi o, nel caso del cliente, nel lavoro del proprio fornitore;
• Maggiore flessibilità: l’obiettivo della metodologia agile non è tanto quello di dare una risposta definitiva sulla gestione di un progetto, ma di dare delle regole precise su come agire in contesti di cambiamento continuo, per trarre valore da questi.

Scrum: il framework Agile più diffuso

Scrum, secondo la guida ufficiale, è un framework per sviluppare e sostenere prodotti complessi. Si tratta, appunto, di un framework, il che lo rende più flessibile rispetto ad altre metodologie, e quindi applicabile con più facilità a molti contesti. È per questo, infatti, che Scrum risulta la più diffusa tra le metodologie Agile.

Scrum, letteralmente, è la mischia del Rugby. È quindi dal mondo sportivo che è stato preso in prestito questo termine che identifica quella situazione di gioco in cui i giocatori si compattano per spingere tutti nella stessa direzione. Ci sono diversi aspetti che caratterizzano lo Scrum, possiamo elencarne alcuni:

• Ruoli: il Product Owner, il responsabile dell’implementazione ed evoluzione del prodotto in un determinato progetto, che si interfaccia con il cliente; Il development team, la squadra di sviluppo; lo Scrum Master, il responsabile dei processi, che a volte fa comunque parte anche del team di sviluppo, sa come applicare al meglio la metodologia Scrum.
• Artefatti: Il Product Backlog, la lista delle attività del team necessarie alla realizzazione del prodotto; questa lista di attività viene poi richiamata di volta in volta nello Sprint Backlog, che raccoglie le attività da svolgere in un determinato periodo.
• Eventi: sono i momenti dello scrum come lo Sprint Planning, quando il team pianifica le attività del successivo periodo – lo sprint – che può durare una o diverse settimane; lo Stand-up, l’incontro di 15 minuti a inizio giornata per allinearsi sulla giornata precedente, su quella che sta per iniziare e per far emergere problematiche che ci stanno ostacolando; la retrospettiva, un momento di confronto approfondito su com’è andato un determinato progetto o su come sta andando generalmente il team.

La cultura Agile come motore della trasformazione digitale interna ed esterna

Abbiamo visto fino ad ora i valori e i principi dell’Agile e come questi si siano posti in contrapposizione ai metodi più tradizionali come quello a cascata.

In Mia‑Platform abbiamo adottato i valori e i principi dell’Agile, e utilizzato il framework Scrum, fin dai primi passi della compagnia. Siamo partiti a fare retrospettive in un’azienda di sole 5 o 6 persone, fino ad arrivare ad avere più di 100 persone organizzate in diversi team. Vi raccontiamo quindi qualche esempio di come applichiamo questo approccio al nostro interno e di come questo ci abbia supportato in una crescita molto rapida (contesto di grande cambiamento) e ricca di complessità (fattori di rischio).

Il continuo miglioramento

Abbiamo già parlato di come l’approccio Agile si basi proprio su un adattamento continuo e su un continuo miglioramento sia individuale che del team. Quello di continuo miglioramento è un concetto che affonda le sue radici in un passato lontano. Deriva dal Kaizen giapponese: l’impegno ad apportare piccoli e continui cambiamenti a tutti gli aspetti di un’organizzazione aziendale. Questi piccoli cambiamenti permettono di portare a una profonda innovazione di tutte le aree dell’impresa.

Ci sono vari modi per portare avanti momenti di formazione e di confronto all’interno del team e cross team. Vediamone alcuni.

Mob Programming

Si tratta di un momento, qualche ora tipicamente, in cui un gruppo di persone lavora contemporaneamente utilizzando un solo computer. La mob programming può essere svolta all’interno del team oppure cross‑team.
Non ci sono regole fisse per una mob programming ma, solitamente, si può:

• Fare una review di qualcosa già sviluppato in precedenza
• Migliorare un pezzo di codice che è stato già scritto
• Studiare qualcosa di nuovo
• Risolvere insieme un problema che si è presentato

Kata

Anche questa è un’attività destinata agli sviluppatori. Si tratta di un momento in cui si svolgono esercizi di programmazione utili ad affinare capacità e competenze. I Kata possono essere svolti anche in sessioni di pair programming.

Continuo miglioramento per gli Scrum Master

Le attività di miglioramento continuo possono essere svolte anche cross-team, e un esempio sono le attività rivolte agli Scrum Master. In questo caso vengono organizzati degli incontri, ciascuno su un tema specifico legato ad un momento dello Scrum. Un esempio può essere la retrospettiva: in questo caso gli Scrum Master si ritrovano e condividono le esperienze sulle retrospettive condotte nei vari team e possono trovare, in questa occasione, buone pratiche e linee guida da condividere con tutti.

Continuo miglioramento per i Product Owner

Questa attività è simile alla precedente. Anche in questo caso gli incontri tra PO sono strutturati in modo da seguire ogni volta un tema specifico con il fine di trovare delle linee guida comuni tra team. L’obiettivo è che queste linee guida possano poi essere declinate in ciascun gruppo di lavoro, che terrà conto delle differenti necessità interne, e che può variare per numero, per tipologia di progetto e molto altro. Alcuni degli argomenti da trattare possono essere: migliorare nella scrittura delle user stories, come rendere le riunioni più efficaci, nuovi modelli e framework di gestione e molto altro.

Il continuo miglioramento del prodotto

Incontrarsi tra ruoli diversi è molto efficace soprattutto quando dobbiamo far evolvere non solo pratiche e processi, ma anche prodotti. Un momento utile per portare avanti il miglioramento del prodotto è l’incontro tra i tech leader dei vari team sui progetti dei clienti, e il tram R&D. Grazie a questo incontro, il team R&D può raccogliere richieste ed esigenze dei team, e aggiornare loro in dettaglio dei piani di sviluppo.

La retrospettiva

La retrospettiva è un momento chiave della metodologia Agile. È un’occasione di incontro nella quale il team può riflettere e analizzare i propri processi generali o l’andamento di un progetto specifico. Le retrospettive abilitano il cambiamento: mettono in luce comportamenti virtuosi così come le pratiche che sarebbe meglio interrompere.
Il Manifesto Agile dedica alla retrospettiva un intero principio, il dodicesimo: A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.
Per condurre una retrospettiva si possono seguire diverse modalità. Qui vi proponiamo 5 fasi per gestire la retrospettiva del team:

• Set the stage: è la fase di partenza ed è molto delicata, perché è in questi primi minuti che è fondamentale che tutti si sentano coinvolti affinché portino valore per tutta la durata della retrospettiva. Una delle tecniche che viene utilizzata in questa fase è quella di descrivere il progetto con una parola;
• Gather data: in questa fase si entra nel vivo del progetto, e si vanno a raccogliere le opinioni di ciascuno. Ci sono vari modi per farlo, uno è lo “start, continue, stop”: i partecipanti possono esprimere la propria idea che andrà a collocarsi in una delle tre opzioni a disposizione.
• Generate insight: questo è il momento in cui si possono approfondire le informazioni raccolte nella fase precedente. Una tecnica per farlo è quella dei cinque perché.
• Decide what to do: una volta conclusa la fase di confronto e approfondimento, arriva il momento di decidere cosa fare di tutte le osservazioni emerse. In questa fase si crea quindi un piano di azioni, e relativi owner, da far partire fin da subito.
• Close the retrospective: si chiudono i lavori e si fa un passaggio breve, simile a quello con cui abbiamo iniziato, e ci chiediamo se la retrospettiva è stata utile oppure no. Questo ci permetterà di organizzarci ancora meglio per la successiva.

Per un approfondimento sulla retrospettiva e su come possa essere gestita e guidata anche da remoto, puoi leggere l’articolo a questo link.

Unconference

L’unconference è uno dei momenti dell’Agile che viene svolto con meno frequenza di altri ma non per questo è meno importante. Si tratta di un particolare tipo di conferenza, basata sull’Open Space Technology. In questa conferenza non convenzionale l’agenda viene costruita dai partecipanti stessi a inizio giornata. Ciascuno può quindi proporre contenuti, non c’è una call for paper, e l’ambiente che ospita l’evento viene scelto proprio per agevolare dinamiche di scambio libero.

I contenuti possono essere presentati in diverse forme: talk o incontri frontali, tavole rotonde o workshop, richieste di approfondimento. Il marketplace è forse il momento più importante della giornata: è il momento in cui si crea l’agenda, in cui ciascuno può proporre il proprio contenuto, a che ora verrà presentato e in quale aula.
Una volta che tutti hanno presentato i propri contenuti, possono avvenire scambi tra slot per rendere l’agenda più fruibile, con poche sovrapposizioni e cercando di agevolare tutti nella partecipazione agli interventi che interessano maggiormente.

L’unconference, apparentemente senza regole, è però guidata da 4 principi – e una legge – molto importanti per la gestione delle sessioni:

1. Chiunque partecipi è la persona adatta;
2. Quando inizia è il momento giusto;
3. Qualsiasi cosa accada è ciò che doveva accadere;
4. Quando è finita è finita.

E infine la legge dei due piedi: se non stai imparando, né contribuendo, allora è bene spostarsi altrove.

Lavorare da remoto: la guida definitiva

Sappiamo che il manifesto Agile dice che Una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team e all’interno del team e crediamo fermamente in questo principio. Nonostante ciò, a volte il lavoro da remoto è necessario, o comunque previsto saltuariamente, all’interno della nostra routine lavorativa. Saperlo gestire al meglio, attraverso strumenti e regole definite, può aiutare a compensare le mancanze che derivano da tutte le situazioni in cui il team, o una parte di esso, non lavora in presenza.

Per strutturare il lavoro da remoto dobbiamo tenere conto di alcuni aspetti:

• Gestione del tempo e logistica: anche da remoto, è molto importante darsi delle regole nella gestione del tempo. Questo per non rischiare né di disperdere le forze, né di lavorare oltre il necessario. Avviare una routine mattutina come se si dovesse uscire di casa per recarsi in ufficio, fare pause in cui alzarsi e fare esercizi, ridurre le distrazioni dovute alle notifiche e bere molto sono alcuni dei consigli essenziali.
• Comunicazione: questo è uno dei punti più complessi del lavoro da remoto. A volte si rischia di trovarsi in interminabili chat o giri di e-mail quando sarebbe più semplice avviare una video call e condividere lo schermo per risolvere in breve tempo dubbi o trovare soluzioni comuni. Inoltre è molto importante, in riunioni da remoto così come in presenza, rimanere concentrati ed evitare di fare altro: in questo modo riduciamo il tempo delle riunioni ed evitiamo di stare ore al telefono senza concludere nulla.
• Strumenti: per supportarci in questa modalità, vengono in nostro aiuto moltissimi strumenti. È quindi importante capire quale usare e in quale occasione per sfruttare al meglio le potenzialità. Noi ad esempio usiamo Google Chat per conversazioni sia 1:1 che di team; è uno strumento molto semplice per avviare anche video call direttamente su Meet quando vediamo che la conversazione sta durando più del dovuto. Usiamo poi tutti gli altri strumenti della Suite di Google per lavorare in condivisione (Drive) e fissare appuntamenti (Calendar). Jira e Confluence ci aiutano invece per tutta la parte di organizzazione del lavoro e documentazione.
• Regole di Team: è importante che le regole siano condivise nel team e che la pianificazione venga fatta per tempo. Ad esempio, se lavoriamo in una modalità mista remoto e presenza, conoscere le giornate di presenza in ufficio degli altri componenti del team con il giusto anticipo permette di organizzarsi al meglio per tutte quelle attività che sarebbe meglio svolgere in co-presenza.
• Quando è obbligatorio lavorare in co-presenza: per alcune attività, il lavoro da remoto risulta poco efficace. Alcuni esempi sono gli eventi scrum più complessi: Sprint Planning, Retrospettive, Sprint Review, ecc; oppure le attività di co-design o co-creazione di contenuti; la fase di onboarding di un nuovo ingresso nel team; la fase di kick-off di un progetto.

Onboarding

L’onboarding è la fase molto delicata di ingresso in azienda. Inizia molto prima della data definita dal calendario e coinvolge molti ruoli all’interno dell’azienda. Per noi è anche un momento importante per raccontare la nostra cultura e come lavoriamo: lo raccontiamo nella guida che puoi leggere a questo link.

Sono principalmente 3 le aree coinvolte, e a ciascuna è dedicata una fase dell’onboarding:

Amministrazione

In questa prima fase viene fatta una panoramica di tutti gli strumenti utili che vengono utilizzati in azienda, da quelli più informali a quelli legati agli eventi scrum, alla documentazione e alla wiki.

People & Culture

Questo è il momento della cultura e dei valori: il manifesto, la corporate social responsibility, la formazione e gli eventi, i percorsi di carriera.

Il team che accoglierà la nuova persona

Qui si entra nel vivo del lavoro, si conoscono i colleghi con cui si lavorerà subito a stretto contatto, il progetto sul quale andremo a mettere le mani e tutte le figure del team: il Product Owner, lo Scrum Master e tutto il team di sviluppo. Soprattutto una volta entrati nel team, si inizierà a familiarizzare con i momenti dello scrum: ciascun team ha un proprio calendario di apertura e chiusura Sprint, un proprio orario di stand-up e un proprio calendario di retrospettive.

Conclusioni

Come abbiamo visto fin dall’inizio, l’approccio Agile si pone l’obiettivo di fornire regole e strumenti che possano aiutare a gestire situazioni complesse e di cambiamento continuo. Abbiamo visto quindi come viene applicato questo approccio nel nostro contesto, con alcuni esempi concreti di attività e momenti Scrum.

Ciascuna realtà, inserita nel proprio contesto, può trovare il proprio modo di applicare l’approccio Agile e il framework Scrum nel modo più appropriato. Solo sperimentando e testando, e continuando a cambiare e migliorarsi, si può trovare il modo ottimale di gestire il team e la sua crescita.