Ringraziamo l’autore Todd Lankford che ci ha permesso di tradurre il suo articolo in Italiano. Potete leggere il suo post originale su medium.
Spesso mi viene chiesto di aiutare le organizzazioni che non ottengono i risultati desiderati da Scrum. Nove volte su dieci mi viene chiesto di sistemare i team, anche se questo è un errore. Le richieste che ricevo sono di questo tipo (potrebbero essere familiari anche a voi):
Sebbene molti vogliano che io sistemi i team, raramente il problema sono i team. I team sono bloccati all'interno di un sistema incapace di raggiungere il flusso di valore desiderato. Il problema quindi non sono i team, è il sistema.
Definisco un sistema come un insieme di strutture, comportamenti e credenze. Se non è allineato con i valori di Scrum e con la sua natura empirica, il sistema non consentirà a Scrum di attecchire e di radicarsi.
Un'organizzazione e i suoi comportamenti possono far funzionare Scrum o al contrario storpiarlo. Secondo la mia esperienza, la maggior parte dei modelli esistenti nelle organizzazioni lo storpiano. Lo storpiano in modo grave.
La Guida di Scrum proclama che Scrum è immutabile: tutto ciò che non rientra nelle regole della Guida non è Scrum. Un'affermazione audace. Ma questo non impedisce di cambiare Scrum, e la maggior parte delle organizzazioni lo cambiano liberamente.
E, sfortunatamente, la maggior parte prende la strada più facile quando adotta Scrum. Lo modificano per adattarlo alla loro situazione, invece di lavorare seriamente. Non cambiano il loro sistema e non supportano ciò di cui Scrum ha bisogno per prosperare.
Al contrario, molti scelgono un processo à la carte di selezione delle sole parti appetibili di Scrum. Così facendo, spesso scartano l'elemento più importante e fondamentale: l'empirismo attraverso team responsabilizzati.
E senza team responsabilizzati che tracciano la rotta migliore attraverso l'apprendimento, vince il sistema rigido dell'organizzazione. La mentalità fissa prevalente annulla qualsiasi possibilità di trasparenza, ispezione e adattamento. E con questa evidente omissione di abilitazione al cambiamento, l'anima di Scrum muore.
Personalmente ritengo che Scrum sia modificabile in determinati contesti. Spesso lo integro con altre pratiche di lean e XP. Ma eliminare i team responsabilizzati e l'empirismo significa andare troppo oltre.
Per esempio, una volta ho incontrato un team che era al 96° Sprint e non aveva mai fatto una Sprint Retrospective o una Sprint Review. Semplicemente, il team non poteva permettersi di dedicare del tempo a questa attività, aveva troppe scadenze da rispettare.
Alla fine, il team non aveva spazio o sicurezza necessari per ispezionare o cambiare rotta. Qualcosa muore dentro di me quando mi imbatto in situazioni come questa.
Alcuni dei compromessi di Scrum che vedo in giro avvengono perché la Guida è incompleta... di proposito. Il framework è intenzionalmente leggero per mantenerlo adattabile al vostro contesto. Ma a volte c'è bisogno di qualche suggerimento per aiutarvi a sfruttarlo al meglio.
Nel corso degli anni, ho visto molte organizzazioni sbagliare con Scrum e Agile, e solo poche azzeccarci. Se c’è qualcosa che posso fare avverare nella mia carriera è contribuire a invertire questa tendenza.
Continuando a leggere, vi svelerò alcuni dei miei sudati insegnamenti, i segreti che Scrum non vi svela. Ma prima, esaminiamo gli aspetti sfortunati e fin troppo comuni di un sistema difettoso. Questo sistema difettoso è contrario a Scrum, lo rompe e lo paralizza.
Il diagramma degli effetti del sistema nella Figura 1 illustra come il sistema difettoso che spesso incontro genera problemi. Un sistema di questo tipo vanifica qualsiasi possibilità di successo di un team Scrum. Blocca quello che per me è lo scopo principale di un team Scrum: ottenere un flusso di valore di alta qualità a un ritmo sostenibile.
Figura 1 — La lentezza del flusso di valore è un problema sistemico, non un problema di team
Come si può vedere dal diagramma, gli elementi chiave che contribuiscono alla lentezza del flusso di valore sono:
Questi difetti sistemici sono tossici e rendono difficile per i team adattarsi quando l'evidenza mostra un percorso migliore. Ognuno di questi anti-pattern rafforza gli altri, rendendoli resistenti. Di conseguenza ne risentono l'empowerment e l'empirismo dei team e il flusso di valore si riduce o si interrompe del tutto.
Facciamo un'immersione più profonda in questi tre difetti sistemici e vediamo come diffondono i problemi.
Ogni tanto i team hanno una deadline. A volte devono preparare qualcosa prima di un evento stabilito in una certa data, come una festività o una fiera. Ma la maggior parte delle volte non hanno questa necessità.
Se è così, perché la maggior parte delle organizzazioni con cui lavoro spinge i propri team a consegnare entro una deadline? Questo comportamento è comune. A volte mi sembra che tutti vengano segretamente addestrati e certificati nell'arte della scadenza.
A parte l'indottrinamento segreto, ho notato alcune cause fondamentali di questo comportamento orientato alla deadline. I principali colpevoli sono:
Nella maggior parte dei casi, la scadenza viene fissata fin dall'inizio, quando si tratta di trasformare un'idea in un progetto concreto. Queste prime fasi sono il momento di minore conoscenza e di maggiore incertezza. Ci troviamo all'ingresso del cono dell’incertezza.
Figura 2: Il Cono dell'Incertezza— Grafico by Todd Lankford 2022
E nella maggior parte delle situazioni, il team che consegna il lavoro non viene consultato in questo processo. Il risultato è un'ipotesi non informata e una scadenza non realistica. Le scadenze irrealistiche creano una pressione sulle tempistiche, causando diversi impatti disastrosi.
Ad esempio, quando il lavoro viene inevitabilmente ritardato, la prima cosa che viene tagliata è la qualità. E questa qualità ridotta produce difetti, che si traducono in ulteriori ritardi. L'aumento della pressione induce i responsabili a fissare nuove scadenze: un circolo vizioso.
Quando mi imbatto in organizzazioni che si basano sulle scadenze, sento sempre una cosa da parte dei dirigenti. Mi dicono che i loro team non si attengono alla "definizione di fatto".
Con una scadenza incombente, i team tagliano soprattutto gli aspetti della qualità. Tra questi, gli script di automazione, i test di regressione, le scansioni delle vulnerabilità di sicurezza e i test di scenario end-to-end. Il risultato è un prodotto fragile, difficile da modificare e con problemi in agguato.
Non sto sostenendo la mancanza di urgenze orientate all’obiettivo e di azioni mirate per portare le idee sul mercato. Ma inventarsi una scadenza rigida, spesso irrealistica, quando non ce n'è bisogno, non è di aiuto. Si traduce in tagli agli angoli, processi extra, team esauriti e diminuzione del flusso di valore. Non è un risultato che desideriamo o di cui abbiamo bisogno.
Secondo Merriam-Webster, la parola "deadlines" è stata usata nel 1860. Si riferiva a "una linea tracciata all'interno o intorno a una prigione che un prigioniero supera con il rischio di essere fucilato". Ora, è questo il tipo di frase che dovremmo usare per motivare i team a consegnare in tempo? No, decisamente non lo è.
Alti livelli di work-in-progress ostacolano la capacità di un team di ispezionare e adattarsi.
Quando ci si trova di fronte all'incertezza e alla complessità, ci si deve adattare alle condizioni che cambiano. Ma alti livelli di work-in-progress risucchiano tutta la flessibilità del sistema. I team che non hanno il margine di manovra per adattarsi alla verità dei fatti non hanno alcuna possibilità di fornire valore nel più breve tempo possibile.
Allora perché le organizzazioni spesso gravitano su livelli elevati di work-in-progress? In primo luogo, il management spesso desidera tenere occupate le persone. Lo fanno per ottenere il massimo dalle persone di cui pagano lo stipendio.
In apparenza, tenere occupate le persone sembra una buona idea. Ma quando gli individui sono impegnati in una comoda corsia di specializzazione, il lavoro di squadra ne risente. Il lavoro incompiuto si accumula, in attesa dell'attenzione di uno sviluppatore specializzato.
Vedo spesso team in cui ogni membro ha il proprio backlog. Questo comportamento spesso deriva dal desiderio della direzione di misurare la produttività individuale. La collaborazione in team può sembrare lenta e inefficiente. E i manager spesso desiderano vedere le "mani sulle tastiere" come segno di produttività degli sviluppatori.
Questo pregiudizio di tipo "busy" ignora un fatto fondamentale. Lo sviluppo del software richiede un notevole sforzo di riflessione e di decisione. La digitazione del codice è la parte più piccola. Anche se è controintuitivo, il lavoro di squadra migliora il processo decisionale e, di conseguenza, accelera lo sviluppo.
Quando il lavoro incompiuto si accumula, si presenta un problema quando le priorità devono cambiare. Il lavoro incompleto diventa un ostacolo. Ci opponiamo a lasciare indietro ciò che è incompiuto perché non vogliamo che il tempo e l'energia che abbiamo impiegato vadano sprecati. È un costo irrecuperabile che facciamo fatica ad abbandonare.
Così, molti finiscono per perdere tempo prezioso nel tentativo di completare il lavoro incompiuto. E così facendo, ostacolano il flusso delle opportunità emergenti e di maggior valore.
Se l'incapacità di fare pivot è un male, un aspetto peggiore si presenta con alti livelli di work in progress. Ha anche l'effetto indesiderato di ridurre le possibilità di innovare e migliorare.
Senza spazio per evolvere sia il prodotto che i metodi per realizzarlo, i team si bloccano. Si ritrovano su una ruota da criceto e non riescono a trovare il tempo per emergere verso uno stato migliore. Questo distrugge la capacità di un team di padroneggiare il proprio mestiere e, in ultima analisi, il suo livello di coinvolgimento.
Quando un team manca di autonomia, scopo e padronanza, il suo impegno ne risente.
Se siete alla ricerca di un indicatore di efficacia del team, non cercate oltre. Un basso impegno del team è un affidabile predittore futuro di scarse prestazioni del team.
Ecco un elenco di cose che un sistema tossico può fare per distruggere il coinvolgimento del team:
Non ho bisogno di un sondaggio per capire quando un team è disingaggiato. Lo riconosco quando lo vedo. E lo vedo troppo spesso.
Un segno evidente del disengagement di un team è quando aspetta che gli si dica cosa fare invece di agire da solo. I team disingaggiati entrano in uno stato in cui hanno rinunciato all'autonomia. Hanno paura di fare qualsiasi mossa senza ricevere istruzioni.
Questo vale anche per cose semplici, come aiutare un membro del team o risolvere un problema evidente che andrebbe a vantaggio di tutti.
Un team dsingaggiato produce un flusso di valore inferiore. E quando il flusso di valore si riduce, la soddisfazione dei clienti e la fiducia nel team crollano. Questa tempesta perfetta crea una forte pressione che porta a gestire maggiormente il team.
E le tattiche per aumentare la gestione del team sono proprio quelle che distruggono il coinvolgimento del team. Più scadenze. Più esperti. Più pianificazione e coordinamento. Più impegno individuale.
Questo diventa un ciclo malvagio e calante, che porta a un flusso di valore sempre peggiore.
La soluzione più semplice è spesso quella trascurata. Le cose semplici sono quelle che ho trovato più efficaci per abilitare l'agilità. E trovo che gli elementi della mia cassetta degli attrezzi per risolvere i difetti di un sistema tossico siano semplici ed efficaci.
Ma semplice non è sempre facile; la parte più difficile è fare un passo verso l'ignoto e provare le idee. Sono certo che ognuna di queste azioni da sola migliorerà la vostra situazione. Ma se prese nel loro insieme, i vostri team raggiungeranno un livello di soddisfazione ed efficacia nettamente superiore.
Ecco le mie ventuno tattiche da provare. Non pretendo di avere tutte le risposte ai vostri problemi. Ma le ho trovate utili più volte e in diversi contesti. Ho usato queste tattiche per aiutare molti a costruire un sistema fiorente per i team Scrum e a migliorare il flusso di valore.
1) Riunire stakeholder, clienti e team come partner, costruendo il prodotto come un unico team. Lasciatevi alle spalle le linee guida, la pianificazione predittiva e altri meccanismi contrattuali. Scegliete invece un volano di co-creazione, misurazione e apprendimento attraverso team potenziati.
2) Riunite i team e coloro che vogliono i piani per co-creare il piano. In questo modo si crea una collaborazione sana e un piano basato sulla realtà. E coloro che scrivono il piano non lo combattono.
3) Usare le evidenze durante la scoperta e la consegna del prodotto per modificare i piani e le previsioni future. I desideri, nonostante l'evidenza del contrario, non sono una strategia vincente. Il continuo perfezionamento del piano basato sulla realtà traccia metodicamente il percorso verso il successo un passo alla volta.
4) Fate piccoli passi di valore incrementale e iterativo. Potreste scoprire che il prodotto di cui avete bisogno non è il migliore che potete immaginare.
5) Preferite l'azione ai piani dettagliati e anticipati. Smettete di pianificare troppo in anticipo sulla base di congetture. Sperimentate e imparate.
6) Evitate le deleghe. Avvicinate gli utenti finali e le parti interessate al team prima, durante e dopo la consegna. L'impegno faccia a faccia crea relazioni ed empatia; i report di status e le deleghe fanno l'opposto.
7) Dimostrate o consegnate spesso il valore del prodotto agli stakeholder e agli utenti. Mostrate il lavoro almeno nella Sprint Review, ma idealmente anche quando il lavoro si evolve durante lo Sprint. Un feedback rapido è fondamentale per trovare prima il prodotto “giusto".
1) Ridurre il work-in-progress a un solo elemento del backlog di valore alla volta per ogni team. Smettete di tenere i membri del team impegnati su questioni separate. Invece, incanalate la forza di concentrazione del team per completare un incremento di valore per il cliente alla volta.
2) Riducete le voci del backlog, in modo da raggiungere lo stato "Fatto" in 1-3 giorni. Ogni volta che si finisce, si è in uno stato pronto e si può facilmente passare alla fase successiva migliore. Ed è una bella sensazione finire.
3) Non riempite lo Sprint con lavorazioni sulle caratteristiche del prodotto. Lasciate spazio all'innovazione, alle interruzioni, alla rimozione degli ostacoli, ai miglioramenti, all'apprendimento e alle misure di ritmo sostenibili.
4) Provate a creare dei momenti senza riunioni. Esempi: mercoledì senza riunioni, pomeriggi senza riunioni o riunioni tra le 10 e le 16.
5) Mettete a disposizione uno spazio per respirare, migliorare e innovare dopo la nascita di ogni incremento di prodotto. A volte, salvare un posto per la sostenibilità e il miglioramento è tutto ciò che serve per farli accadere.
6) Provate il mob programming per sperimentare la collaborazione, la qualità e il flusso di valore al suo meglio. Se questa è l'unica tattica che proverete di questo elenco, rimarrete stupiti dall'impatto.
7) Impegnatevi a raggiungere gli obiettivi, non gli scopi e i piani. Questo vi libera dal fissarvi sul piano e vi permette di navigare verso il vostro obiettivo in base all’apprendimento.
1) Lasciare che sia il team a decidere come gestire il flusso di valore. Il team è un insieme di professionisti. Permettete loro di dispiegare le ali.
2) Incentivare il lavoro di squadra e la collaborazione rispetto ai risultati individuali. La ricompensa degli eroismi e delle conoscenze specialistiche deve cessare per consentire la crescita delle capacità del team.
3) Create uno scopo coinvolgente per i vostri team. Uno scopo comune può trasformare un insieme di individui in una squadra.
4) Rimuovere gli ostacoli sistemici che i team non possono rimuovere da soli. I team possono gestire ciò che possono controllare. Lasciate loro questo compito. Aiutateli invece con ciò che non possono controllare.
5) Negli Sprint date spazio all'apprendimento, alle competenze trasversali e all'affinamento delle abilità. La padronanza non avverrà se i team non hanno il tempo di esercitarsi e affinare i propri strumenti.
6) Rompete i silos e le dipendenze. Provate tecniche come l'accoppiamento trasversale, la proprietà collettiva del codice e l'attenuazione dei confini del team. Noi e il nostro batte sempre l'io e il mio.
7) Fate della vostra salute come team una priorità. Utilizzate accordi di lavoro di squadra per migliorare e sostenere una maggiore autonomia, padronanza e scopo. Controllateli spesso per assicurarvi che il vostro team sia impegnato e operi a un ritmo sostenibile, indefinitamente.
Tutti noi lavoriamo in un sistema. Alcuni sistemi sono ben progettati per supportare l'agilità. Ma altri lavorano contro di essa; questi sistemi tossici sono dilaganti.
I sistemi difettosi presentano tre problemi chiave:
Ma non tutto è perduto. Potete migliorare il vostro sistema con una delle ventuno idee proposte in questo articolo. Queste idee forniscono azioni pratiche per migliorare il vostro sistema e il flusso di valore:
La seguente citazione di Paul Batalden è spesso attribuita a W. Edwards Deming. Sembra certamente qualcosa che Deming avrebbe detto. Indipendentemente dall'origine, essa centra il bersaglio di questo articolo.
"Ogni sistema è perfettamente progettato per ottenere i risultati che ottiene".
- Paul Batalden, medico
Quindi, cosa state aspettando? Datevi da fare oggi stesso per progettare un sistema che produca i risultati che desiderate.
Referenze: