5 fatti sulla trasformazione agile

Non sono mai stato un fan dei film horror. Ma Halloween mi è sempre piaciuto. Da bambino adoravo mettermi costumi spaventosi e spaventare i miei amici e altre persone. E ammetto che mi piace il brivido di entrare in una casa stregata ben allestita ad Halloween.

Tuttavia, anche in ogni trasformazione agile ci sono aspetti che possono far venire i brividi – e questi momenti non sono altrettanto emozionanti.

Affrontiamo quindi insieme queste cinque cose, togliamoli il loro alone spaventoso e parliamo di cosa sono esattamente e perché non sono poi così terribili una volta compresi correttamente.

1) Ahhh! In Agile non c’è una fase di design!

Spesso gli architetti e i collaboratori del reparto sviluppo sono preoccupati perché in Agile non esiste una fase di design esplicita. Anche se è vero che i team agili evitano le fasi di design all’inizio di un progetto, ciò non significa che il design venga trascurato.

Il design in un progetto agile è caratterizzato da due aspetti: è emergente e intenzionale.

Il design emergente si sviluppa nel tempo. Invece di una fase di design iniziale, il design è un processo continuo. Il design nasce durante la creazione del software.

Il design è però anche intenzionale. Ciò significa che il design non nasce per caso. Il design viene guidato dai responsabili tecnici senior di un progetto o anche da un architetto dedicato.

Se queste persone sono preoccupate per una parte specifica del sistema, il Product Owner dovrebbe prioritizzare uno o due Product Backlog Item da quell’area. In questo modo il team ha l’opportunità di conoscere meglio quella parte del sistema sviluppandone una piccola porzione. Questo aiuterà a trovare il design giusto.

Se il design emerge in questo modo dalle decisioni del team, il fatto che in Agile non esista una fase di design esplicita non è più così spaventoso.

2) Aiuto! Diventerò un generalista!

Uno dei miti più diffusi in Agile è che i team agili non vogliano specialisti e preferiscano che tutti nel team siano generalisti.

Questo spaventa molte persone per due motivi: primo, non tutti amano fare ogni tipo di lavoro. Secondo, c’è spesso la preoccupazione che in futuro possa avere ripercussioni sull’occupabilità se qualcuno sa fare quattro cose discretamente bene invece di una in modo eccellente.

L’idea che tutti in un team agile debbano essere generalisti è falsa. Quando faccio coaching a un team che ha il miglior esperto JavaScript del mondo, voglio che questa superstar faccia cose fantastiche con JavaScript e non che impari a diventare un amministratore di database.

Sì, nei team agili si vogliono membri del team con competenze diverse: ad es. il tester che sa anche scrivere un po’ di codice. La soluzione più semplice è avere qualcuno che sa fare entrambi i tipi di lavoro ugualmente bene. Se il tuo team ha ad esempio uno squilibrio tra lavori di programmazione e di testing, è utile avere qualcuno nel team che sappia sia programmare che testare.

Un obiettivo in Agile è la formazione di team cross-funzionali. Ciò significa che un team possiede tutte le competenze per creare un incremento di prodotto finito e funzionante in un’iterazione. Ciò non significa però che ogni membro del team debba possedere ogni competenza necessaria nel team cross-funzionale.

Se il pensiero di diventare un generalista ti fa rizzare i capelli, sarai sollevato nel sapere che gli specialisti sono benvenuti anche nei team cross-funzionali.

3) Oh no! Non abbiamo né piani né previsioni!

Spesso i manager rabbrividiscono al pensiero che un team agile non possa fare piani o previsioni oltre l’iterazione o lo Sprint attuale.

Fortunamente, questo non è del tutto vero.

Sì, i team agili rinunciano al falso comfort di progetti sovra-pianificati con diagrammi di Gantt illeggibili e calendari precisi fino a un lontano futuro. Ciò non significa però che i team agili non siano in grado di pianificare e fare previsioni sul futuro.

Un grande vantaggio dei metodi agili è che il team verifica e adatta l’intero processo di sviluppo in ogni iterazione. Prende un’idea sotto forma di una semplice User Story e implementa questa funzionalità. Ciò significa che i team possono misurare i propri progressi ogni poche settimane. Così scoprono quanti lavori riescono a completare.

Confrontiamolo con un progetto di sviluppo tradizionale che magari ha una fase di analisi, una fase di design, una fase di coding e infine una fase di test. Quando questi team vogliono misurare i propri progressi, possono sempre solo constatare quanto velocemente svolgono uno (o forse due) di questi lavori. La velocità di un team nel design non dice nulla sulla velocità nel coding o nel testing.

La cosa più importante nella trasformazione agile è accogliere l’incertezza – ammettere che è impossibile conoscere tutte le funzionalità prima dell’inizio del progetto – e poi scegliere una delle tante possibilità per adattarsi. Quando i team hanno compreso questo e misurano la quantità di lavoro in ogni iterazione, ciò dovrebbe rassicurare il management e portare a una pianificazione affidabile.

4) Aiuto! Perderò il mio lavoro!

L’idea di una transizione agile di un team o di un’intera azienda può spaventare parecchio qualche manager, perché molti temono che il loro posto di lavoro diventi superfluo dopo la transizione.

Questo è comprensibile. Naturalmente sarebbe terribile iniziare una transizione sapendo che questo renderà superfluo il proprio ruolo.

Tuttavia, non ho mai aiutato un’azienda nella trasformazione agile e sentito dire: “Ok, le persone con questo e quel ruolo non ci servono più. Saranno tutti licenziati.” Non succederà. Naturalmente può essere che una determinata qualifica non sia più necessaria o adeguata, ma queste persone hanno comunque un lavoro. Credo persino che nella maggior parte dei casi si ritrovino poi con lavori migliori e più adatti di prima. Certo, può accadere che alcune persone abbiano meno controllo diretto su collaboratori e decisioni e siano per questo frustrate – a volte così frustrate da lasciare l’azienda.

Poiché non ho mai visto persone con determinati ruoli o competenze essere semplicemente licenziate durante una trasformazione agile, penso che la paura sia tanto ingiustificata quanto quella di un’apocalisse zombie.

5) Uhhh! In Scrum ci sono troppi meeting!

Come la maggior parte delle persone, odio i meeting. In generale, mi concentro sul perché faccio quello che faccio. Nella maggior parte delle giornate non ho nessun meeting. Che fortuna.

Tuttavia, anche io posso ammettere che alcuni meeting sono importanti e utili. Tra questi i quattro meeting standard di Scrum: lo Sprint Planning Meeting, il Daily Scrum, la Review e la Retrospettiva.

Il solo pensiero di tutti questi meeting fa sudare freddo alcune persone.

E il problema con i meeting di Scrum: hanno un nome. Quando qualcosa ha un nome, lo si può attaccare meglio. Nella mia esperienza, la maggior parte dei team prima di Scrum aveva più meeting. Questi meeting però non avevano nomi e venivano per lo più organizzati spontaneamente per chiarire determinate cose.

Con un esperimento puoi verificarlo rapidamente. Cerca nel tuo calendario un mese qualsiasi in cui non lavoravi ancora con Agile. Somma il tempo che hai passato in meeting in quel mese. Poi somma il tempo che trascorri ora nei meeting Scrum e confronta le due cifre.

Credo che rimarrai sorpreso dal risultato. Poiché i meeting dei tempi precedenti alla trasformazione agile non venivano tenuti regolarmente e ripetutamente, non avevano nomi e quindi non rimanevano impressi nella memoria come ad esempio uno “Sprint Planning Meeting”.

Il consiglio più importante per non avere più paura di passare troppo tempo nei meeting è di tenerli brevi. Di tanto in tanto lavoro con team che devo invitare a prendersi un po’ più di tempo per i loro meeting.

La maggior parte dei team però passa troppo tempo nei meeting Scrum. Una volta che si riesce a tenerli brevi e concisi, non dovrebbero più spaventare nessuno.

Conclusione: rilassati... questi fantasmi non sono reali!

Camminare in una casa stregata e travestirsi è divertente perché tutti sappiamo che è solo apparenza. I fantasmi, mostri, vampiri, lupi mannari e pazzi con la motosega non sono reali.

E anche i cinque miti agili qui descritti non lo sono. Non c’è nulla di sbagliato nell’avere un po’ di paura all’inizio. L’informazione e l’esperienza smaschereranno rapidamente questi miti e ti daranno un senso di sicurezza.

Se però vuoi farti un’idea personale della realtà agile e dei miti su Scrum & Co., dai un’occhiata alla nostra Agile Journey, dove ti presentiamo i ruoli in dettaglio, oppure diventa subito Scrum Master certificato o partecipa al nostro Training Agile Leadership.

Questo testo proviene dal blog di Mike Cohn ed è stato tradotto in italiano.

Innovazione in azienda

=> Cosa contraddistingue le aziende innovative?

Strategia vissuta

=> Scopri come portare la tua strategia aziendale a un nuovo livello.

Aziende invincibili

=> Come si presenta la gestione moderna dell’innovazione in azienda?