5 domande sull'introduzione di Scrum

Le organizzazioni non diventano agili da un giorno all’altro per magia. Si tratta di un significativo processo di cambiamento in cui ogni persona deve rivedere e adattare il proprio ruolo. E tutto inizia con la leadership che deve rispondere ad alcune domande piuttosto complicate.

Date le sfide che le organizzazioni moderne devono affrontare, Agile è estremamente attraente. Chi non vorrebbe rilasci più frequenti? Chi non vorrebbe adattarsi meglio a un contesto aziendale in continuo cambiamento? Tuttavia, troppi dirigenti prendono in considerazione Scrum e iniziano una trasformazione agile senza comprendere l’impatto che Scrum può avere sulla loro organizzazione, la loro carriera e i loro obiettivi.

Scrum non è qualcosa che dovrebbe essere introdotto alla leggera in un’organizzazione, e i dirigenti dovrebbero porsi alcune domande complicate. Scrum non riguarda solo i team di sviluppo. Non può essere limitato a un singolo team. L’introduzione di Scrum rappresenta un cambiamento sistemico in un’organizzazione e viene regolarmente descritta come difficile e dirompente. Ma cosa significa davvero? Quali sono i possibili impatti di Scrum?

Ecco cinque domande a cui bisognerebbe rispondere per prepararsi a un’introduzione di Scrum di successo e produttiva.

1) Come reagisco ai cambiamenti che influenzano il mio ruolo?

Questa domanda deve essere affrontata da tutte le persone in un’organizzazione e non solo dai team che lavoreranno con Scrum. Scrum ha l’impatto più diretto sui team, ma non si ferma lì. Che dire dei superiori? E come reagirete se il vostro ruolo di leadership viene influenzato?

Esempio: Scrum e il middle management

Stavo facendo colazione con il mio amico John (nome modificato). John era un development manager presso un grande istituto di servizi finanziari, dove Scrum era stato introdotto negli ultimi anni.

Era preoccupato per come il suo ruolo veniva ora percepito nell’azienda. Gli chiesi perché fosse preoccupato e rispose: “all’inizio andava tutto bene. I team facevano rapidi progressi e un ambiente di lavoro basato sui team è più adatto alle persone rispetto a un modello di Shared Services. Ora però abbiamo team che risolvono i problemi per lo più da soli e monitorano autonomamente le proprie prestazioni.”

Voleva sapere quale fosse il suo ruolo in questo nuovo ambiente auto-organizzato.

La funzione del middle management nelle aziende basate sul modello dello “Scientific Management” (Taylorismo) ruota principalmente intorno alle prestazioni e all’efficienza dei dipendenti. Al Taylorismo viene attribuita gran parte dell’aumento di produttività del XX secolo. Tuttavia, è meno adatto alla creazione di prodotti moderni basati sulla conoscenza.

Come cambia quindi il ruolo del middle management con l’introduzione di Scrum?

Dopo una breve discussione, John decise che poteva contribuire fungendo da mentore e comunicatore per i suoi team, mostrando loro ciò di cui l’azienda ha bisogno e dimostrando all’azienda che i suoi team sono in grado di soddisfare tali esigenze.

2) Come gestite i vostri migliori collaboratori se non vogliono partecipare a questo percorso?

Non tutti vogliono lavorare con Scrum. A molte persone piace Scrum perché permette loro di creare un prodotto su cui hanno un impatto diretto, e questo può dare grande soddisfazione. Ma non tutti la penseranno così.

Esempio: la star arrabbiata

Jack era la star del suo team e lo faceva sapere a tutti. Quando il team si avvicinava a una scadenza, Jack lavorava spesso 80 ore a settimana per far sì che il team raggiungesse il suo obiettivo. Spesso era ancora in ufficio alle 22:00 e inviava email alla direzione anche nel fine settimana. Il management lo adorava!

La qualità del suo lavoro era però discutibile. Produceva molto codice che non funzionava e richiedeva una revisione significativa. Dopo un’altra nottata in ufficio, gli altri membri del team impiegavano giorni per correggere i bug e integrare il suo codice.

Cercarono di spiegare a Jack che il suo comportamento influiva negativamente sull’intero team – ma non volle ascoltare e disse: “parlate con il management”.

La situazione cambiò quando Scrum fu introdotto nel team. I progressi e la trasparenza nel team venivano discussi ogni giorno durante il Daily Scrum – i progressi quotidiani venivano quindi costantemente misurati dal team. Grazie al fatto che il team poteva decidere autonomamente quanto lavoro avrebbe completato in un’iterazione, potevano lavorare a un ritmo più sostenibile durante l’intero progetto.

Durante una Retrospettiva, il team mise in discussione la creazione di codice non completamente testato che rubava tempo all’intero team.

Jack non prese bene l’introduzione di Scrum. La buona trasparenza nel Daily Scrum evidenziò chiaramente che Jack non consegnava codice regolarmente, ma rimandava il lavoro all’ultimo giorno dello Sprint. Quando il team propose soluzioni ai problemi, Jack si lamentò del micromanagement.

Non riusciva a lavorare a un ritmo costante e sostenibile e, invece di concentrarsi sul massimo valore per il cliente, si lamentava che il suo lavoro fosse “noioso” o “senza sfide”.

Quando il team si impegnò durante una Retrospettiva a migliorare la qualità del codice attraverso test regolari, Jack minacciò di lasciare il team e persino l’azienda. Cinque Sprint dopo l’introduzione di Scrum, Jack lasciò volontariamente l’azienda. Le prestazioni del team migliorarono costantemente e tre anni dopo producevano ancora un prodotto di alta qualità.

Nell’introduzione di Agile, le aziende devono chiedersi cosa fare se i loro migliori collaboratori non vogliono lavorare in uno Scrum Team. Li lascereste andare? Oppure dovrebbero restare in azienda e potenzialmente disturbare altri Scrum Team? Se siete pronti a lasciarli andare, come giustificate questa decisione?

3) Quali meccanismi utilizzerete per indurre cambiamenti comportamentali?

Scrum richiede cambiamenti comportamentali: tra questi l’auto-organizzazione, una maggiore collaborazione e trasparenza. Cambiare comportamenti è estremamente difficile, soprattutto per i dipendenti di lunga data che sono stati formati a comportarsi in un certo modo. Ora che è necessario un cambiamento, come vi assicurate che avvenga davvero?

La formazione continua gioca qui un ruolo fondamentale.

Come leader nel management, potete supportare i collaboratori con training, coaching e conferenze e aiutarli a comprendere e applicare i metodi moderni di sviluppo software. E dimostrando impegno verso i collaboratori, il morale e la soddisfazione dei dipendenti e dell’azienda possono migliorare.

Una parte essenziale di questo cambiamento comportamentale ha a che fare con la fiducia nel team. Se lavoro con qualcuno e quella persona capisce il mio lavoro, è un rischio per la mia valutazione delle prestazioni? È un rischio per il mio posto di lavoro? Come si costruisce la fiducia se una delle due domande ha come risposta “sì”?

Un approccio comune è cambiare le responsabilità e le metriche in base alle quali i collaboratori vengono valutati. Per promuovere un comportamento cooperativo, si dà più peso al lavoro di squadra rispetto alle prestazioni individuali. Questo può avvenire con il feedback basato sul team o il feedback a 360°.

Dare meno importanza alle prestazioni individuali mette in discussione le responsabilità individuali. Nessuno vuole essere responsabile di un’area specifica se viene valutato in base alle prestazioni dell’intero team. Pertanto, ai membri dello Scrum Team dovrebbero naturalmente essere assegnate responsabilità per diverse aree. Ciò significa che dovrebbero consegnare una parte di un prodotto potenzialmente rilasciabile in ogni Sprint.

Questo può sembrare insignificante, ma ha un grande impatto sul modo in cui un’azienda opera. Come influisce sulla vostra struttura organizzativa se i team sono responsabili del lavoro in più aree tematiche diverse?

4) Cosa penserà il reparto di supporto dei cambiamenti causati da Scrum?

Nella maggior parte dei casi, Scrum viene introdotto in un’organizzazione attraverso i team di sviluppo software. Ai team di supporto e architettura raramente si pensa in anticipo. Questo perché molte organizzazioni assumono che “Scrum è una cosa che fanno gli sviluppatori”.

In realtà, Scrum influenza definitivamente anche altri team. Come reagiranno ad esempio i team di supporto quando ci saranno punti di attrito con gli Scrum Team? Come verranno risolti questi problemi?

Esempio: disaccordi tra diversi reparti

Sarah era un’architetto senior Java Messaging Service (JMS) e responsabile della visione aziendale di un Enterprise Service Bus (ESB). Era sempre più frustrata perché gli Scrum Team “ignoravano le linee guida aziendali, aggirando l’ESB o aggiungendo nuove funzionalità non allineate alla strategia aziendale”.

Quando le fu chiesto perché i team si comportassero così, disse che i team avevano bisogno di più disciplina e una migliore formazione sulla strategia ESB. Poi aggiunse: “forse non stiamo soddisfacendo le loro esigenze”.

Dopo ulteriori discussioni, Sarah decise che la cosa migliore sarebbe stata unirsi a uno Scrum Team per capire le loro sfide e aiutarli a comprendere meglio gli obiettivi aziendali.

5) Quanto è disposta l’azienda a investire in questa trasformazione? E quale valore viene generato per questo investimento?

Poche aziende hanno in anticipo un’idea chiara di quanto guadagneranno con Agile. Ci sono poche informazioni su quanti ricavi ci si possa aspettare. Tuttavia, ci sono sempre più prove che con Scrum si possono ottenere rilasci più frequenti, migliore qualità del prodotto e un contatto più diretto con i clienti.

Una buona soluzione è un budget annuale fisso per la formazione e il coaching continuo dei collaboratori. Questo diventa però problematico quando l’introduzione di Scrum procede più velocemente di quanto il budget consenta. È anche difficile da giustificare quando non si può dire chiaramente quanti ricavi ne derivino.

Una soluzione migliore sarebbe misurare alcune metriche chiave, come ad esempio:

• Ricavi per dipendente
• Soddisfazione del cliente
• Soddisfazione dei dipendenti
  Se i dirigenti osservano se queste metriche migliorano con Scrum, possono vedere quanto è efficace l’introduzione di Scrum e se è necessario cambiare qualcosa.

Ci sono però alcune cose interessanti in questo approccio risolutivo che vale la pena evidenziare:

In primo luogo, questo metodo è indipendente dal framework utilizzato e potrebbe misurare anche le prestazioni di un’azienda che non lavora con Agile. In secondo luogo, potreste scoprire che Scrum non è l’approccio migliore per la vostra azienda o che esistono framework più efficaci di Scrum. Questo accade raramente, ma è naturalmente possibile.

Proprio questo approccio di misurazione è stato recentemente ripreso da Ken Schwaber nel suo “Evidence-Based Management” (gestione basata sulle evidenze). È ancora troppo presto per dire quale impatto avrà questo approccio sullo sviluppo software, ma è una soluzione molto interessante e ha il potenziale per fornire alle aziende prove concrete del loro miglioramento.

La conclusione

Introdurre Scrum non è qualcosa che dovrebbe essere fatto alla leggera. C’è un rischio sia per l’organizzazione che per le singole persone. Se si comprendono le domande che le persone pongono, si potranno capire meglio le loro motivazioni, paure e dubbi. E con questa conoscenza si potrà formare un approccio molto più completo che risponda alle esigenze dell’azienda e dei collaboratori.

“La capacità di pensare in modo logico è una delle cose che ci rendono umani. In un mondo di informazioni onnipresenti e strumenti di analisi sofisticati, la logica da sola non basta però. Ciò che distinguerà le persone di successo sarà la loro capacità di immedesimarsi negli altri, di costruire relazioni e di prendersi cura delle persone.”
– Daniel H. Pink, autore bestseller di Drive

(Nota: questo è un contributo ospite dello Scrum Trainer e Coach Kane Mar, fondatore di Scrumology.com e Scrum101.com.) Questo testo proviene dal blog di Openview ed è stato tradotto in italiano.