Quando le aziende passano con soluzioni software dall’on-premise al cloud, spesso si pongono l’obiettivo di diventare più “agili”. Questo spesso dovrebbe applicarsi idealmente a tutto a livello interaziendale. E, naturalmente, ovunque allo stesso tempo.
La trasformazione dei processi potrebbe essere facilmente possibile, almeno in teoria. Puoi definire cerimonie di mischia e riassegnare le persone a nuovi ruoli (come Scrum Master, Product Owner, Delivery Manager e Scrum Team).
Puoi portare strumenti come le schede Jira, Azure ADO e Miro e renderne obbligatorio l’uso. Ma che dire dei processi che collegano insieme gli strumenti? Che ne dici di trasformare la mente, i comportamenti e il modo di lavorare delle persone? Diventa chiaro che questi non si trasformeranno in modo fluido, né finiranno rapidamente. Ora, osserviamo il perché.
Sommario:
Che cos’è un’iniziativa di trasformazione della consegna e perché le aziende la stanno adottando?
Gran parte delle aziende oggi lavora ancora secondo il modello di consegna a cascata. Ciò significa che:
L’intero processo potrebbe richiedere da alcuni mesi ad alcuni anni e, come puoi vedere, gli utenti vedranno i risultati solo alla fine di tale processo. Quindi, dopo una lunga attesa arriva il momento della verità (o del fallimento).
Se qualcosa cambia durante questo lungo periodo e il prodotto finale dovrebbe apparire leggermente diverso, si tratta di una situazione chiamata richiesta di modifica. Il progetto deve essere riaperto, rielaborato e riapprovato. Prolunga l’intero calendario di un’altra parte.
Chiaramente, questo non è affatto agile. Ogni modifica richiede prima il riavvio dell’intero processo.
Passaggio all’Agile
Quindi, come uscire da questa situazione e cambiarla per diventare agili? Le persone lavorano nella struttura a cascata per molti anni o addirittura secoli. Hanno ruoli e responsabilità con cui si sentono a proprio agio e non vogliono cambiare lo status quo. La ragione principale di ciò è che attuare questo cambiamento significa in definitiva perdere parte del potere che avevano fino ad ora.
Questo è il motivo principale per cui tale cambiamento estrae dalle persone il più forte livello di resistenza che potresti creare.
#1. Ristrutturazione della squadra
Il primo e relativamente più semplice da fare è ristrutturare le persone in team di mischia. Dividili in base alle aree funzionali o a qualsiasi altra suddivisione logica che abbia senso.
La suddivisione di solito avviene senza intoppi; il problema inizia quando ci si rende conto che le persone sono ancora legate alle strutture originarie. Anche se fanno già parte dei nuovi team di mischia, praticamente non lo sono. Lavorano ancora su quella vecchia impostazione perché hanno ancora responsabilità che non sono state concluse insieme al processo di ristrutturazione del team (perché sarebbe così: alla leadership non interessa molto ciò che deve essere finito, ma soprattutto ciò che deve essere avviato).
Quindi, in pratica, ti ritroverai con un team di mischia che non è un team di mischia completamente dedicato. È un gruppo di persone che ora ha semplicemente più lavoro da fare. Non c’è tanto tempo per il lavoro all’interno del team di mischia quanto si aspetta il management.
Allo stesso tempo, l’aspettativa è che le persone finiscano le loro attività originali così come questa nuova aspettativa all’interno degli scrum team. È un setup destinato a fallire fin dall’inizio.
#2. Pianificazione delle cerimonie Scrum
Ordinare ai team di programmare diverse chiamate regolari (cerimonie sprint) è facile da definire e avviare. Almeno, presupponendo che i tuoi team di mischia non siano composti da persone provenienti da più di 3 fusi orari (come spesso accade).
Il problema inizia quando le persone non partecipano regolarmente alle cerimonie. A seconda di chi manca e con quale frequenza, ciò può evolvere in vari tipi di problemi. Per esempio:
- Se i proprietari del prodotto non partecipano alle cerimonie di pianificazione e perfezionamento, il team non avrà nuove storie su cui lavorare. Oppure la descrizione delle storie è così mediocre che il resto del team non può iniziare a lavorarci sopra.
- Se mancano gli Scrum Master alle chiamate, al team manca l’orchestrazione di base della mischia e alla fine potrebbe perdersi.
- Se i membri del team di sviluppo mancano spesso, non riescono a sincronizzarsi tra loro e la comunicazione all’interno del team è molto più difficile. Inoltre, sono necessarie più riunioni per recuperare il ritardo, il che toglie ancora un altro tempo al team.
In definitiva, non è necessariamente colpa delle persone se perdono le cerimonie. È solo che la configurazione non consentirà loro di partecipare alle chiamate (vedi sopra per le assegnazioni precedenti parallele).
#3. Stabilità della squadra
Potresti avere un team di mischia con struttura e cerimonie, ma se quel team non è stabile per un periodo di tempo più lungo – diciamo almeno sei mesi idealmente, un anno di stabilità sarebbe il mio requisito minimo personale – allora un team del genere può non si evolve e migliora davvero.
Successivamente, probabilmente non raggiungerai mai un team di mischia completamente indipendente che gestisca gli sprint come al solito. Infine, dovrai educare e apprendere costantemente le persone all’interno del team per comprendere la mentalità e i processi di Scrum. È un problema estenuante da avere.
Questo è un problema molto sottovalutato, in particolare dalla leadership o dal management dell’azienda. Chiamare i team di persone semplicemente “risorse” e pianificare il loro “utilizzo” di trimestre in trimestre è una strada immediata verso l’inferno.
#4. Nuovi ruoli per le stesse persone
Un altro ostacolo da superare è riassegnare le persone esistenti a nuovi ruoli diversi. Coloro che in precedenza gestivano team con il massimo potere potrebbero ora diventare Product Owner, ad esempio. Questa è una posizione forte in un team di mischia, ma può essere vista come un ruolo più debole in relazione alla configurazione esistente.
All’improvviso, i proprietari del prodotto devono sincronizzarsi con lo Scrum Master o i program manager. Sono ancora responsabili del contenuto ma non tanto dei processi di consegna. Questa situazione richiede la rinuncia ad alcune responsabilità che le persone avevano in precedenza e, quindi, è difficile da digerire.
#5. Modi di lavorare
Questo è interessante, e lo sento di tanto in tanto abbastanza spesso: dobbiamo imparare nuovi modi di lavorare per diventare rilevanti nel mercato in evoluzione in cui l’agilità è l’aspettativa di base. Ma cosa significano esattamente queste modalità di lavoro?
Se me lo chiedi, è chiaro cosa intende il management con questo: ottenere (molto) di più in un tempo più breve. Dopo aver creato i team di mischia, l’aspettativa è che ogni membro del team ottenga improvvisamente alcuni risultati incrementali documentati di giorno in giorno. Se così non fosse, la leadership inizierà a chiedersi perché il processo agile non funziona bene.
Dal nulla, la leadership si aspetta che ogni ora conti e che i team di mischia non abbiano praticamente tempi di inattività, solo perché probabilmente non c’è spazio per tutti i processi di mischia in atto. E questa è in poche parole la definizione di “nuovi modi di lavorare” dal punto di vista della leadership.
Naturalmente, questa aspettativa non si basa sulla realtà. È illusorio aspettarsi che le persone in azienda inizino a lavorare di più nello stesso periodo, solo perché alcuni processi quotidiani cambieranno. Voglio dire, alcuni di loro potrebbero, anche se solo una minoranza. Tuttavia anche questo gruppo si riduce ulteriormente ingombrandoli con più compiti contemporaneamente.
Differenza tra obiettivo e realtà
Non c’è dubbio che la descrizione dell’obiettivo finale sia spesso buona e abbia molto senso. Si aggira sui seguenti principi:
- Team di mischia stabilizzati che lavorano su arretrati indipendenti con KPI e OKR chiari.
- I proprietari dei prodotti devono creare solide roadmap e pianificare contenuti prioritari da fornire rispetto a scadenze concrete.
- Contenuto del backlog definito con caratteristiche rilevanti già dettagliate prima dell’inizio del lavoro.
- Processi di test affidabili eseguiti insieme al normale lavoro di sviluppo dello sprint.
- Rilasci regolari in produzione – almeno una volta al mese, ma idealmente dopo ogni completamento dello sprint.
- Monitoraggio dei rischi e dei problemi e comunicazione tra i diversi team Scrum in caso di dipendenze.
Poi, quando si passa alla realtà, posso dire che nessuno dei punti sopra indicati è facile da raggiungere.
- Formi le squadre di mischia, ma cambiano costantemente (di trimestre in trimestre). Investi tempo per insegnare al team i processi di Scrum e, una volta che finalmente iniziano ad accettarli e a cambiare il loro modo di lavorare, riorganizzi i team per il periodo successivo. Le tabelle di marcia vengono modificate, spostate o cancellate.
- I proprietari dei prodotti non hanno la minima idea dei dettagli della roadmap e (solo perché avevano tali abitudini in precedenza) assegneranno i loro compiti di creazione del contenuto del backlog direttamente al team. Di conseguenza, il team non ha tempo per sviluppare il contenuto poiché deve prima capire cosa sviluppare.
- I processi di test sono solo manuali e richiedono molti passaggi secondari, approvazioni e processi complicati da seguire. Ciò significa che non è possibile che i test possano terminare nello stesso sprint dello sviluppo.
- Di conseguenza, il rilascio in produzione è in ritardo di diversi sprint.
- La comunicazione tra i diversi team di mischia è caotica e inefficace, poiché ogni squadra ha molte attività da svolgere in ogni sprint. Infatti, i productowner tendono ad assegnare al team una quantità eccessiva di contenuti in ogni sprint. Non c’è alcuna possibilità che il team riesca a completare tutto, quindi sono costantemente sotto stress per le scadenze.
Correggere gli errori
Avendo esperienza in alcuni progetti di trasformazione agile, vorrei riassumere alcuni dei più grandi errori che ho riscontrato e fornire alcune opinioni soggettive su come eventualmente superarli.
#1. Giuste responsabilità per giusti ruoli
Se provi a modificare la definizione e a distribuire le responsabilità in un modo diverso da come dovrebbero essere per la mischia/agile, stai portando l’intera iniziativa al fallimento.
- I proprietari del prodotto saranno proprietari del contenuto e manterranno il backlog. Sono responsabili delle storie di arretrato e, se le storie di arretrato non sono ben definite, spetta a loro agire e risolverlo. D’altro canto, non dovrebbero avere alcuna influenza sulle assegnazioni del personale dello Scrum Team o sulle decisioni relative al budget del progetto.
- Gli Scrum Master non avranno alcuna responsabilità riguardo al contenuto del backlog. Fanno parte del team per orchestrare le cerimonie ed educare il team a un modo agile di lavorare. Non dovrebbero essere segretari dei Product Owner. Al contrario, devono proteggere il team di sviluppo dal proprietario del prodotto e dalle parti interessate esterne.
- Ad ogni team di mischia verrà assegnato un responsabile della consegna. Questa persona collegherà il PO, il SM e il team di sviluppo in una configurazione praticabile, definirà i processi di consegna e risolverà eventuali rischi, problemi o conflitti che il team potrebbe avere. Il responsabile della consegna è la persona giusta per decidere le questioni relative al personale e al budget del progetto. Questa persona dovrà impegnarsi a costruire un ambiente per la squadra in cui tutti possano dare il meglio di sé.
- La responsabilità del team di sviluppo è sviluppare le storie dal backlog. Possono aiutare PO a creare contenuti per alcune storie (soprattutto quelle troppo tecniche), ma non sono responsabili o addirittura non sono responsabili delle storie che costruiscono la creazione dei contenuti della roadmap.
#2. Squadra stabile
Investire nella formazione agile del team è importante e deve essere un processo rapido. Lasciare che questa conoscenza scompaia ogni pochi mesi è solo una perdita di tempo per tutti.
I primi cinque sprint possono essere utilizzati come curva di apprendimento affinché il team possa conoscere e mettere in pratica le attività di base della mischia. Una volta che questi sono chiari per l’intero team, può iniziare il processo di miglioramento continuo del team Scrum. Ma se le persone all’interno del team cambiano regolarmente, ti ritroverai in un ciclo costante di trasferimenti di conoscenze e formazione.
Un team di questo tipo probabilmente non raggiungerà mai il pieno potenziale di performance, e il gruppo dirigente continuerà a chiedersi perché in precedenza (prima della trasformazione agile) fosse più efficiente di quanto sembri ora.
Quindi, costruisci il team, investi le conoscenze e, una volta che il team ha preso confidenza con i nuovi processi, mantienilo così com’è e sviluppalo ulteriormente. Da qui inizierà il cammino costante verso la perfezione.
#3. Matrice RACI
È una buona pratica costruire e concordare la matrice RACI (Responsabile, Accountable, Consultato, Informato) tra tutti i team appena prima che inizi il lavoro vero e proprio. Questo può potenzialmente eliminare molta confusione all’inizio.
È piuttosto importante, soprattutto nelle prime fasi delle iniziative di trasformazione. Altrimenti, le persone inizieranno a sollevare domande su chi dovrebbe fare cosa in quale situazione, soprattutto in quelle a cui non è stato esplicitamente risposto tramite le comunicazioni del team.
Ecco un esempio di tale matrice RACI per alcune delle responsabilità. Il tuo progetto può avere un set diverso. È importante catturare quelli rilevanti.
TaskRequestorDelivery LeadProduct OwnerScrum MasterDev TeamSessioni di pianificazione SprintC/ICA/IRC/IDreliver Release IncrementoN/AIA/IC/IRSprint ReviewC/IIRICSprint RetrospectiveIIA/IRC/IRefinire il backlogIA/IRAC/I
Conclusione
Potrebbe esserci ancora molto di cui scrivere, poiché ci sono molti modi e molti luoghi in cui la trasformazione agile può portare fuori strada. Lo scopo era quello di evidenziare alcuni dei problemi che ritengo si ripetano spesso.
L’iniziativa in sé è una buona idea. Tuttavia, se si rispettano alcune regole di base, può diventare rapidamente un incubo per tutti i partecipanti. Ne ho evidenziati alcuni, ma usa il buon senso e tutto andrà bene. 🙂
Successivamente, controlla le buone risorse di apprendimento per la certificazione Agile.