Diventare agili

Raggiungere risultati in tempi brevi tramite processi trasparenti, condivisi tra team e cliente.

Nell’attuale mercato fluido ed in continuo mutamento, il flusso produttivo tradizionale, verticale, poco flessibile e soprattutto non condiviso con il cliente, non può più essere un modo per lavorare in team in maniera efficiente, rapida, realizzando prodotti di qualità.

Dall’inizio del 2014 abbiamo deciso di sperimentare alcune pratiche e metodologie di gestione e organizzazione dei team.

Gli obiettivi erano:

• liberarsi da situazioni in cui una o due persone erano le uniche e imprescindibili depositarie del progetto o delle tecnologie usate;
• velocizzare il tempo di rilascio dei prodotti a partire dalla loro ideazione;
• lavorare su più progetti contemporaneamente senza perdere efficienza;
• gestire meglio i cambiamenti progettuali in corso d’opera;
• migliorare la comunicazione dei compiti e degli avanzamenti d’opera tra team e cliente.

La metodologia Agile, nella fattispecie Scrum, è stata scelta per sperimentare quello che per noi era un nuovo approccio alla gestione del team e del lavoro.
Scrum è un metodo empirico e tale è stato anche il nostro atteggiamento: non ci siamo preoccupati troppo di “fare Scrum” come da manuale, piuttosto di provare direttamente eventuali benefici o svantaggi.
Rispetto ad altri metodi Agile, come ad esempio Kanban, Scrum prevede dei cicli di sviluppo con un limite di tempo, gli Sprint; ovvero un buon modo per mantenere alta la produttività e la concentrazione, limitando le deviazioni di progetto.

Abbiamo deciso di provare questa nuova strada su un progetto software, condividendo con il cliente vision e obiettivi. 

L’inizio: il team

Il primo passo è stato individuare le due nuove figure che avrebbero affiancato il team di sviluppo: lo scrum master, un membro del team che si sarebbe occupato della gestione e facilitazione del team, e il product owner, nominato dal cliente, che avrebbe stabilito priorità e vision del progetto.
Il team di sviluppo è stato formato da membri di Chialab e dai nostri partner di Channelweb.
Siamo partiti subito con la definizione delle regole e degli incontri Scrum con il team: sprint planning, daily scrum, sprint review, sprint retrospective.
Abbiamo aggiunto un meeting chiamato “weekly scrum”: ovvero un daily scrum che, una volta alla settimana, viene esteso al cliente, per condividere lo stato del lavoro in maniera trasparente.

Durante questa prima “fase empirica” la sensazione era più o meno quella di perdere davvero molto tempo in discussioni e incontri invece di lavorare.
Ben presto il team ha capito che il tempo apparentemente perso in discussioni era tempo guadagnato sul lavoro, in quanto si era sempre tutti allineati con gli obiettivi dettati dal cliente e dal mercato.
Il fatto di avere delle deadline in tempi stretti (le 2-4 settimane di ogni sprint) dapprima veniva visto come motivo di pressione, per poi diventare sempre più un momento di routine vissuto con tranquillità.

La responsabilità non era più centralizzata su alcuni membri del team o sul “tradizionale” project manager. Essendo distribuita tra i vari ruoli, ha aiutato a lavorare in modo focalizzato ed efficiente, lasciando spazio a tutti i membri nel prendere decisioni sui compiti da svolgere: ognuno è diventato manager del proprio dominio di competenza.

Il team di sviluppo decide in maniera autonoma come portare a termine il proprio lavoro sotto gli aspetti tecnici e progettuali, aumentando le proprie responsabilità e soddisfazioni.
Lo scrum master, seguendo tutto il flusso di lavoro, è in grado di gestire le problematiche del team, motivandolo, coinvolgendolo nei momenti di condivisione del lavoro e aiutandone la crescita.
Il product owner, occupandosi della parte business e restando a contatto con il team, riesce ad avere sempre il polso dello stato di progetto e a prevederne impatto e sviluppo nel mercato.
Ogni ruolo è così focalizzato sul proprio lavoro e allo stesso tempo è sempre sincronizzato con l’intero ecosistema di sviluppo del progetto.

Avendo iniziato a utilizzare Scrum tutti assieme, sia sviluppatori che manager, ci sono voluti un paio d’anni per prendere consapevolezza dell’efficacia del metodo rispetto a un sistema tradizionale a cascata; ma nessuno tornerebbe indietro a una gestione tradizionale.

I risultati

Una volta stabilizzato il metodo base di Scrum (che si riassume in una breve guida di poche pagine), i membri del team in maniera autonoma hanno deciso di adottare altre pratiche derivate da Agile nella gestione del proprio flusso di lavoro in un costante processo di crescita.

Agile e Scrum non sono delle soluzioni definitive, ma sono un insieme di metodi e strumenti che aiutano a migliorare il proprio lavoro.

Il team è così riuscito in maniera indipendente a raggiungere gli obiettivi prefissati:

• grazie a momenti di condivisione come pair programming, code review e i meeting scrum, tecnologie e decisioni progettuali erano maggiormente condivise e non “proprietà” di qualche membro del team;
• coinvolgendo tutte le figure necessarie alla realizzazione dei prodotti, i cicli di rilascio sono diventati frequenti, completi e condivisi;
• il team è stato coinvolto su più progetti che utilizzano scrum, rendendo più facile la condivisione di risorse e competenze tra i progetti stessi;
• scrum ci ha aiutato a condividere con il cliente scelte di progetto e di mercato, modificando il prodotto stesso durante la fase di sviluppo per adattarsi alle rispettive esigenze;
• conseguentemente è aumentata la fiducia tra cliente e team, condividendo orizzonti e scelte per fare crescere i prodotti assieme.

Sperimentare il metodo oltre lo sviluppo software

Acquisita consapevolezza ed efficienza sullo sviluppo software, abbiamo pensato di esportare queste metodologie anche ad altri settori dello studio, come l’impaginazione dei libri di scolastica, nonostante l’assenza di una letteratura soddisfacente sulle metodologie Agile in ambiti simili.

Questa fase di sperimentazione su progetti non software è stata condotta per un periodo limitato e su un progetto specifico, non esponendo direttamente la nuova organizzazione al cliente (non sempre questo è un vantaggio, sicuramente non in una fase di test).

Lo scrum master del team di sviluppo software ha fatto da coach per il team che si occupa dell’impaginazione dei libri, spiegando i principi Agile e Scrum e preparando il team a questo periodo di test di metodo.
La prima azione è stata una retrospettiva del flusso di lavoro attuale e cercare di capire i punti di forza e di debolezza del team.

Successivamente abbiamo provato a suddividere il lavoro in sprint, parcellizzando e stimando in maniera semplice il lavoro su cicli di 2 settimane.
È stata poi realizzata una board fisica, dove visualizzare il progresso del lavoro tramite dei post-it su cui venivano segnati i compiti da completare; è stato anche istituito un “daily scrum” di allineamento quotidiano.

Abbiamo nominato un product owner e uno scrum master tra i membri del team interno.

Alla fine di ogni sprint veniva fatta una retrospettiva per valutare miglioramenti o cambiamenti nel flusso di lavoro.

La sperimentazione è durata 3 sprint, ovvero 6 settimane.

Che cosa abbiamo capito

Applicare il metodo scrum “da manuale” in questo caso non ha funzionato molto bene.

La suddivisione in cicli mal si adattava alla tipologia di lavorazioni che hanno questi libri, difficilmente frammentabili in porzioni di tempo piccole e con sincronizzazioni tra le lavorazioni non sempre lineari e prevedibili.

Per questo motivo anche il daily scrum aveva poco senso: spesso si ripetevano le stesse informazioni.

Che cosa ha funzionato

La suddivisione dei ruoli, secondo lo schema product owner - scrum master - team di sviluppo, è stata fondamentale. Molti blocchi nel flusso erano dovuti a una distribuzione di responsabilità e di competenze poco chiara. Rendere chiare le figure ha portato un immediato vantaggio nei processi decisionali e nella condivisione delle responsabilità.

Le retrospettiva è stata mantenuta ma a fine ciclo di lavorazione, non legata a delle scadenze temporali fisse (sprint).

Conclusioni

La definizione dei ruoli secondo scrum è stato un vantaggio tangibile per progetti software e non: per questo motivo abbiamo deciso di estendere questa strategia a tutti i lavori Chialab.

Ogni progetto prevede quindi, oltre alle figure operative, due figure che sostituiscono di fatto il tradizionale ruolo del project manager.

Per evitare di fare confusione con scrum, il ruolo del product owner è stato rinominato come “responsabile” e lo scrum master come “gestore”. Assieme al team di sviluppo, decidono in maniera autonoma come gestire e condividere le responsabilità e i compiti del lavoro, e se adottare metodologie agili o meno.

Una volta al mese, gestori e responsabili si incontrano in un breve meeting per allinearsi riguardo allo stato di lavori e risorse.

Possiamo dire che Agile e Scrum hanno portato un miglioramento diretto nella gestione dello sviluppo software, dove si sono adattati meglio alla tipologia di lavoro, mentre l’adozione di alcuni principi di Agile su lavori non software ha permesso una migliore distribuzione dei ruoli nella gestione del lavoro.

L’importante è stato sperimentare e capire velocemente quali metodi mantenere e quali abbandonare, anche e soprattutto sbagliando.

Manuel Zanettin

Is this still Scrum? I’m not sure, but does it really matter? Anything that works for you is right, anything that doesn’t is wrong.
Henrik Kniberg
Crisp/Spotify/Lego