Parte dello stato di salute dei team di progettazione dipende dalla loro capacità di autogestirsi! All'interno dei team di questo tipo ci sono ruoli e responsabilità chiari e tutti i membri si impegnano a realizzare i progetti in base a un piano ben ragionato.
L'anno scorso abbiamo creato un nuovo team chiamato Micros Scale dedicato alla creazione della Platform as a Service (PaaS) interna di Atlassian, ovvero la nostra piattaforma dell'esperienza di sviluppo. Poiché il nostro lavoro ha un ambito fisso e timeline chiare, ci siamo impegnati di più per portare a termine un lavoro incrementale, più mirato, orientato agli obiettivi e proattivo.
Tuttavia, in precedenza il nostro team riceveva una grande mole di lavoro operativo ad hoc che ci impediva di pianificare correttamente gli sprint. Almeno il 55 percento della capacità del team era assegnato alle rotazioni per il mantenimento della continuità operativa (KTLP, Keep The Light On). In questo contesto, Kanban si presentava come la metodologia più adatta alle nostre esigenze.
Vale la pena osservare che, secondo il modello Tuckman, il team Micros Scale era nella fase di formazione e che c'erano alcune aree di miglioramento che riguardavano, tra le altre, la pianificazione della capacità, la pianificazione degli sprint, la definizione degli obiettivi, la riflessione del team, la preparazione e l'elaborazione delle story, le attività di stima, la suddivisione dei progetti e così via.
Quale metodologia Agile era adatta a noi?
Micros Scale gestisce due progetti importanti molto complessi e con una scadenza annunciata pubblicamente ai clienti. Ciò significa che è fondamentale completare i rilasci con più velocità. Avevamo bisogno di acquisire fiducia nel nostro approccio di consegna e volevamo lavorare sulla pianificazione come dei veri professionisti Agile. Volevamo che il nostro team fosse autogestito, che raggiungesse gli obiettivi comuni e adottasse un approccio empirico.
Abbiamo rivalutato il nostro approccio Agile ponendoci le seguenti domande:
- È possibile fissare un obiettivo per ogni iterazione per raggiungere un obiettivo generale con un tema unico?
- Possiamo impegnarci a rispettare l'ambito dei risultati finali per una o due settimane?
- Possiamo sviluppare e fissare i requisiti su cui occorre lavorare?
- La frequenza delle richieste ad hoc per la modifica della priorità dei task è bassa e ci sono meno probabilità che si verifichino cambiamenti drastici?
- Il nostro team è nuovo e non particolarmente esperto dei processi Agile?
Poiché le risposte a queste domande erano affermative, ci siamo resi conto che Scrum era la metodologia Agile più adatta per il nostro team. Ecco altri dettagli che abbiamo utilizzato per prendere la nostra decisione:
| | | | |
|---|---|---|---|
| Metodologia Agile | Di cosa si tratta? | Ci sta aiutando? | Perché? |
| Scrum | In Scrum è possibile usufruire di roadmap chiare e blocchi di lavoro con priorità, mentre con Kanban è possibile visualizzare il lavoro che viene confrontato con il team su base ad hoc. | Sì | Abbiamo un backlog predefinito chiaro che necessita di perfezionamento e definizione delle priorità. Il nostro lavoro è prevedibile, a differenza di quello del team precedente, pieno di sorprese e richieste con priorità elevata. |
| Le story non dovrebbero essere modificate nel bel mezzo di uno sprint. | Sì | Possiamo adottare un approccio più flessibile; in questo caso, Scrumban (un ibrido tra Scrum e Kanban). | |
| Scrum è più facile da adottare per i team Agile che stanno ancora imparando a usare le funzionalità all'avanguardia. È un framework più prescrittivo, con rituali e timebox da seguire come linee guida. | Sì | Abbiamo un nuovo team con nuovi membri, ancora nelle fasi di formazione e conflitto, quindi poter utilizzare Scrum ci aiuta a diventare più maturi. Leggi informazioni sul modello Tuckman. | |
| Kanban | Consente di limitare il lavoro in corso e di concentrarsi sulla riduzione della durata del ciclo del progetto. Il caso d'uso di questa metodologia è quando il team non deve rispettare un limite di tempo e una timeline per completare il lavoro. La richiesta arriva al team, che la gestisce il più rapidamente possibile (come lo SLA dei team di service desk). | No | Gli altri team dipendono da noi, quindi abbiamo bisogno di timeline stimate per aiutare gli altri a pianificare il loro lavoro di conseguenza. Alcuni dei nostri impegni vengono annunciati pubblicamente ai clienti di Atlassian, quindi dobbiamo pianificare attentamente per loro conto. Non riceviamo molte richieste a breve termine come il team di service desk. |
| È eccellente per i team che ricevono molte richieste operative diverse in termini di priorità e dimensioni. | Sì | Non abbiamo un carico elevato di KTLO e il flusso di lavoro è gestito da un membro del team a turno. Possiamo svolgere tale ruolo su Kanban, se vogliamo. |
Abbiamo adottato Scrum
Sono pienamente consapevole che il ruolo di coordinatore rappresenta una delle caratteristiche principali dei responsabili tecnici, oltre ai ruoli di facilitatore, bussola e coach. Per questo motivo, dovevo allenare le mie competenze di coordinatrice. Ecco come ho raggiunto questo obiettivo:
Imparare di più su Agile
Le risorse didattiche interne di Atlassian mi hanno aiutato ad accrescere le mie competenze nelle pratiche Agile. Ho seguito corsi di approfondimento su Agile e mi sono consultata con un coach Agile. Ho parlato con alcuni responsabili tecnici per conoscere la loro esperienza presso altre organizzazioni e altri team.
Usare il DACI
Per prendere decisioni efficaci ed efficienti a livello di gruppo veniva utilizzato il quadro decisionale DACI (acronimo di "Driver, Approvatore, Collaboratore e Informato"). Ho illustrato ai membri del team una proposta di modifica del DACI per accertarmi di avere il loro feedback, la loro approvazione e il loro supporto.
Usare un modello dello sprint
Ho elaborato un processo di gestione degli sprint e ho creato un modello per ciascuno sprint per agevolare una pianificazione più ragionevole. Il modello di pianificazione dello sprint includeva:
- Come rivedere lo sprint precedente per assicurarci di comprendere con chiarezza gli obiettivi raggiunti e festeggiare i successi.
- Come riflettere retrospettivamente sullo sprint precedente e applicare gli insegnamenti appresi allo sprint successivo.
- Cosa sono la cadenza, il nome e gli obiettivi dello sprint?
- Quante story ci impegniamo a completare? Cos'è l'ambito dello sprint?
- Come pianificare la capacità in base alla disponibilità delle persone.
- Di quali attività di metà sprint abbiamo bisogno per essere completamente preparati per lo sprint successivo?
- Come scrivere story, sviluppare i requisiti e trovare una soluzione per gestirli.
- Come monitorare lo stato delle story per cui ci siamo impegnati e cosa fare con le story incompiute.
Abbiamo anche un ottimo tutorial su come eseguire gli sprint in Jira Software.
Passare a Scrum è stato utile
I seguenti sono i miglioramenti che abbiamo apportato con il passaggio a Scrum:
Miglioramento della velocity
In ambito Agile, uno dei fattori per misurare la produttività di un team è la velocity, ovvero la mole media di lavoro che un team Scrum completa durante uno sprint. Usiamo un grafico della velocity per capire in cosa si è impegnato il team e cosa è stato rilasciato. Nel grafico della velocity qui sotto, la colonna grigia mostra il numero di Story Point preso in carico dal team in base alla sua capacità. La confrontiamo con la colonna blu, che indica quanti Story Point il team ha effettivamente completato. Il team può quindi utilizzare queste informazioni per modificare le previsioni per gli sprint futuri.
Identificazione tempestiva dei rischi
Essere in grado di identificare tempestivamente i rischi e trovare e proporre una soluzione è la chiave del successo dei progetti.
Definendo gli obiettivi e i temi dello sprint, abbiamo scelto story coerenti per raggiungere gli obiettivi. Nelle sessioni di metà sprint, il nostro team ha preparato, perfezionato e approfondito le story. Durante la fase di approfondimento, ci siamo chiesti:
- Che cosa occorre fare?
- Perché stiamo facendo questo lavoro?
- Quale valore aziendale aggiunge?
In questo modo, i nostri ingegneri hanno potuto identificare le dipendenze e dare priorità ai ticket con un impatto maggiore per rimuovere gli ostacoli. Questo processo ci ha anche portato a cambiare la nostra metodologia di lavoro e a migliorare la concentrazione dell'intero team su ogni progetto.
È il momento di festeggiare! Siamo arrivati al rilascio
La pianificazione della capacità e la definizione degli obiettivi ci hanno motivato in modo significativo e ci hanno sfidato a mantenere la trasparenza sui nostri impegni. Abbiamo rilasciato correttamente una fase critica del partizionamento dell'account Atlassian PaaS. Stiamo anche per rilasciare la prima fase del progetto di residenza dei dati per raggiungere più regioni AWS a scopi di affidabilità, resilienza e conformità.
Transizione dalla fase di formazione a quella di coesione
Come ho accennato sopra, il team Micros Scale è relativamente nuovo e tendenzialmente si trova nella fase di formazione del modello Tuckman.
La definizione di un obiettivo unificato a livello di team ha spinto tutti ad allinearsi e sostenersi a vicenda per raggiungere gli obiettivi e aumentare la motivazione generale. Abbiamo fallito, ma abbiamo anche riflettuto e imparato e siamo diventati migliori. Dopo tre mesi e mezzo, abbiamo assunto il 50 percento di persone in più per il team Micros Scale e ritengo con orgoglio che il team sia un team coeso.
Miglioramento della comunicazione
Avere un piano e seguirlo durante ogni sprint ha aumentato la visibilità del lavoro pianificato per l'intero team e ci ha permesso di parlare la stessa lingua. È molto più facile per i responsabili tecnici e gli stakeholder tenere traccia degli ostacoli e dell'avanzamento del progetto.
Come scegliere la metodologia Agile giusta
- Non esitare a rivedere i processi quando riscontri un problema. Pensa in modo Agile: persone, processi e strumenti.
- Valuta il progetto e le responsabilità del team per trovare le metodologie Agile più adatte alle sue esigenze. Dai un'occhiata alla nostra pagina dedicata al confronto tra Kanban e Scrum per saperne di più su queste metodologie.
- Se decidi di passare a Scrum, ti suggerisco di usare una board Scrum di Jira o di creare un modello su Confluence o sul tuo strumento preferito.
Per ogni sprint, crea una pagina di pianificazione dello sprint per esaminare e riflettere sull'ultimo sprint e pianificare quello successivo in base alla capacità del team e all'obiettivo dello sprint. Ecco il mio modello di Confluence personale:
Ecco il modello di pianificazione della capacità che ho seguito e che ho incluso nel modello generale di Scrum:
Ecco anche gli obiettivi dello sprint e il modello dell'ambito che ho stabilito:
Per la metà dello sprint, è utile avere un'altra pagina per tenere traccia delle prestazioni del team durante la settimana precedente, per individuare le story da trasferire allo sprint successivo in base all'avanzamento attuale dello sprint (ovvero la preparazione) e per approfondire le story preparate (perfezionamento della story). Ecco il modello di backlog grooming e perfezionamento di metà sprint che ho utilizzato:
Ogni team è diverso e ciò che ha funzionato per noi potrebbe non funzionare per gli altri team. Scrum, Kanban o una combinazione di entrambi, come Scrumban e Kanplan, potrebbero presentarsi come metodologie migliori. È fondamentale valutare le esigenze specifiche del team e capire qual è la metodologia più adatta.
