Per Iniziare
Comincia dalle basi e scopri come utilizzare Mia-Platform a piccoli passi.
Comincia dalle basi e scopri come utilizzare Mia-Platform a piccoli passi.
Inizia ora
Diventa Partner certificato e scopri tutti i benefici del Partner Program.
Scopri il nostro programma
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 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.
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
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.
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:
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:
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:
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).
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.
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ò:
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.
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.
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.
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 è 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:
Per un approfondimento sulla retrospettiva e su come possa essere gestita e guidata anche da remoto, puoi leggere l’articolo a questo link.
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:
E infine la legge dei due piedi: se non stai imparando, né contribuendo, allora è bene spostarsi altrove.
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:
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:
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.
Questo è il momento della cultura e dei valori: il manifesto, la corporate social responsibility, la formazione e gli eventi, i percorsi di carriera.
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.
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.