Come forse avrai già avuto modo di leggere o di imparare, lo Scrum fa parte della grande famiglia dell’Agile. È infatti una delle principali metodologie (come indicato anche dal 13° State of Agile Report) utilizzate per la gestione iterativa e misurabile delle task di lavoro, volta alla generazione di valore per il cliente.
Portare lo Scrum all’interno di un’azienda o di un team di lavoro richiede, in primis, che ci sia una buona predisposizione da parte degli attori coinvolti verso il cambiamento di quello che è stato, fino a quell’istante, il modus operandi. Questo perché modificare il proprio approccio al lavoro significa in parte mettere in discussione le prassi organizzative e/o di pianificazione consolidate nel tempo, magari in anni ed anni di esperienza.
D’altra parte però bisogna anche essere in grado di capire che il cambiamento può essere sinonimo di miglioramento. In questo articolo vogliamo quindi parlarti di uno specifico aspetto di quella che è stata la nostra esperienza di introduzione del metodo Scrum.
Uno dei mostri che abbiamo scardinato con lo Scrum
Analizziamo ora quello che è stato per noi uno dei primi e principali elementi su cui abbiamo dovuto lavorare per adattare il nostro mindset “tradizionale” a quello nuovo, Agile.
Partiamo con il dire che lo Scrum ragiona per “sprint” di lavoro, che in genere possono variare da una a quattro settimane.
Questo ha già una grossa iniziale implicazione, che ha per noi rappresentato proprio lo scalino iniziale da superare: ragionando per sprint, al cliente non si possono più dare delle deadline precise rispetto alle giornate (o addirittura all’orario) di consegna dell’output di lavoro o di parte di esso. Sarà invece imprescindibile parlare di “settimana” e soprattutto sarà necessario istruire il cliente stesso a questo nuovo metodo, che fino ad ora è stato a lui estraneo.
Lavorare per sprint non significa però farlo senza cognizione di causa e senza rigore – come potrebbe sembrare a prima vista.
Lavorare per sprint significa strutturare le task secondo cicli di lavoro brevi che permettono un aggiornamento costante, sia internamente che con il cliente, il quale di settimana in settimana può essere allineato, coinvolto, ascoltato.
Un esempio di vista vissuta
Facciamo un esempio concreto a cui ormai il nostro marketing team è abituato: prendiamo il caso in cui si stia lavorando allo sviluppo una campagna omnicanale per il lancio di un nuovo prodotto (potrebbe essere anche l’implementazione di nuove features di un software da parte del team di sviluppo, non ci sarebbe alcuna differenza) e che il relativo sprint definito duri due settimane.
Questo sprint inizia con una riunione del team di lavoro, durante la quale vengono definite le attività che si ritiene siano verosimilmente realizzabili entro le settimane concordate, tenuto ovviamente conto di un certo margine, dovuto ad eventuali lavorazioni prioritarie aggiuntive o problemi imprevisti.
[se vuoi sapere come migliorare la tua capacità di reagire alle situazioni impreviste e di rendere il tuo lavoro Agile, scrivici una mail! Saremo felici di condividere esperienze e best practice]
Come ci comportiamo quindi con il cliente? Come prima cosa lo informiamo dello start del progetto e gli illustriamo che nella settimana XY (corrispondente alla fine del primo sprint) ci sarà un aggiornamento assieme a lui per verificare che il team stia portando avanti il lavoro nelle modalità richieste e che si stia intraprendendo la strada migliore rispetto agli obiettivi prefissati.
Alla fatidica domanda del cliente: “Per quando è pronto?” (per esempio la campagna di marketing che abbiamo citato prima o lo sviluppo del nuovo sito web oppure ancora la creazione della grafica dell’intera stationary di base) risponderemo con la settimana durante la quale prevediamo di portare a termine le task.
La bravura del team sta dunque nell’essere capace di pianificare al meglio la realizzazione e conseguente conclusione del lavoro: se il cliente ha bisogno di essere online con il nuovo website entro il 19 di aprile, noi dovremmo avere concluso il tutto nella settimana 15.
Quali sono i plus del lavoro per sprint
Perché ragionare secondo le logiche dello Scrum? E, soprattutto, perché introdurre il concetto di settimana invece che continuare a dare deadline che siano il più precise possibile?
Sulla base della nostra esperienza, possiamo dire che le Business Unit ed i team di lavoro, che operano con lo Scrum, otterranno di certo questi benefici:
- Migliore gestione delle risorse – i componenti dei team, non essendo legati al lavoro ad “ore”, potranno organizzarsi in modo più efficiente ed efficace.
- Ottimizzazione della propria operatività – data dal fatto che le micro deadline intermedie (corrispondenti ad ognuno degli sprint) permettono di fermarsi, ragionare su quanto creato fino a quel momento e, se necessario, modificare il piano di attività e priorità senza dover arrivare a progetto concluso per capire quali sono le criticità esistenti.
- Aumento del valore percepito dal cliente – visto che viene coinvolto in ognuno degli step del progetto ed è reso partecipe, di volta in volta, di quanto è stato realizzato.
- Incremento della capacità di adattamento – lavorando per sprint, la predisposizione al cambiamento rapido delle attività (volto ad una maggiore efficienza e adesione agli obiettivi del cliente) diventa poi un’abitudine.
Lato cliente, il plus sarà invece una maggiore partecipazione nei processi (in questo modo egli viene davvero “messo al centro”), con la relativa possibilità di intervenire nelle fasi di sviluppo del lavoro, di dare il proprio feedback e di essere ascoltato – così da ottenere un output che realmente corrisponde a ciò di cui ha bisogno.
