C'è solo una cosa che è ancora più impegnativa di questa: lavorare per altri su più progetti.
Questo significa che bisogna lavorare molto a livello di portfolio per applicare la giusta allocazione delle risorse ai progetti utilizzando come criterio principale la durata stimata (basata sulle ore per persona).
Quindi, per spiegare un po' meglio il nostro lavoro: lavorare per altri in data fissa, progetti multipli con assegnazioni basate su stime approssimative. No, non è un processo casuale. Ma ci va molto vicino.
Come farlo funzionare?
All'inizio usavamo Basecamp per gestire i progetti (sì, liste di attività ovunque). Quando ci siamo avvicinati ad agile abbiamo studiato a fondo il framework Scrum e abbiamo cercato di applicarlo al nostro team. Dopo alcuni mesi di sperimentazione, abbiamo scoperto che Scrum non era adatto a noi.
Le ragioni principali erano:
- L'elevata frammentazione dei progetti durante lo sprint causava problemi di concentrazione nel raggiungimento dell'obiettivo dello sprint.
- I rituali richiedevano molto tempo, soprattutto durante la pianificazione dello sprint, a causa dell'elevato costo del passaggio delle storie utente tra i progetti.
- Il morale del team si stava abbassando a causa dell'impossibilità di completare le funzionalità entro lo sprint, anche a causa delle richieste di urgenza provenienti dai siti di produzione (richieste di accelerazione) che non riuscivano a focalizzare il team sull'obiettivo dello sprint.
tl;dr
Scrum non era la soluzione giusta per un team con una concomitanza di progetti e richieste di accelerazione che a volte dovevano essere completate in tempi brevi.
Chi ha detto Kanban?
Il team è passato a un sistema di gestione dei progetti di tipo pull, Kanban (il libro di David Anderson è un'ottima risorsa per iniziare). Kanban non pretende di spingere il team verso un risultato “a scadenza”, perché avvolge il processo attorno a ciò che già si ha (nel nostro caso progettazione/codifica/QA/deploy) e lavora su lanes per far fluire il lavoro all'interno del team di sviluppo (Trello sta facendo un ottimo lavoro nel diffondere il funzionamento di Kanban in quasi tutte le situazioni). Il principio di base di Kanban è molto diverso da quello di Scrum: si può lavorare su qualcosa quando c'è posto per farlo. Ciò significa che si inizia a lavorare su una scheda quando si è completata quella attuale o quando il WIP lo consente.
Non è stato facile far capire alle persone l'importanza di spostare le schede da una corsia all'altra su una lavagna virtuale e di mantenere tutto pulito e aggiornato, ma alla fine abbiamo strutturato e organizzato il nostro flusso di sviluppo dalla progettazione al codice, alla QA fino alla distribuzione utilizzando i limiti del WIP. Niente più riunioni di sprint e una grande serie di metriche gratuite: tempo di ciclo e CFD (LeanKit offre tutto questo in un'applicazione web molto potente, non molto bella dal punto di vista dell'interfaccia utente ma, ehi, non si può avere tutto giusto?)
L'effetto “c'è-una-scadenza-per-questo?”.
A un certo punto, mentre utilizzavamo Kanban, si è verificato un effetto inaspettato: il team si è semplicemente adagiato. In un sistema pull, teoricamente, non c'è una vera e propria urgenza né ci si concentra sul mantenere il team impegnato in una precisa tabella di marcia per le milestone. È un flusso. Con Scrum, invece, si hanno sprint di 10 giorni, team altamente focalizzati e fortemente impegnati nel ciclo di sprint.
Per questo abbiamo sentito il bisogno di aggiungere un ulteriore livello motivazionale: inseguire un certo tempo medio di ciclo è una buona idea, ma trovo che le milestones di rilascio siano più vicine, più comprensibili per gli sviluppatori e i designer come indicatore lineare verso la scadenza finale del rilascio. Far conoscere ai membri del team la roadmap del progetto all'interno di obiettivi a breve-medio termine - meglio se avvolti all'interno del concetto di cicli (settimanali, di 10 giorni...), questo può sembrare banale ma in un sistema pull può aiutare il team a concentrarsi su obiettivi comuni.
Quello che ho imparato è che avere un piano è meglio che non averlo affatto; l'importante è essere pronti ad adattarsi rapidamente durante l'avanzamento del progetto spostando le milestone di rilascio con nuove stime periodiche. Le milestone sono un buon indicatore lineare verso la data di rilascio finale desiderata e devono essere tenute presenti anche in un sistema pull come Kanban.
Questa è stata la nostra esperienza diretta e il nostro tentativo di adattarci durante il nostro processo di sviluppo. Credo che cercare di gestire progetti concomitanti ispirati alle metodologie agili sia un problema che molte organizzazioni devono affrontare, sarei molto curioso di conoscere altri modelli che mirano a mantenere il team concentrato sulle milestone con una pressione “positiva” verso obiettivi comuni.
Questo si è evoluto
Queste sono alcune delle nostre lezioni apprese. Siamo impegnati a migliorare continuamente il nostro modo di lavorare.
Leggi di più su come si è evoluta la situazione.
