Miglioramenti nelle autostrade messicane

Diversi anni or sono un amico mi raccontò una storia divertente:

[blockquote2]“Le autorità messicane approvarono il potenziamento di una autostrada, facendola passare da due a tre corsie. La propaganda inviò comunicati di effetto: “Abbiamo aumentato del 50% la capacità della strada“. Con il passare del tempo il governo si rese conto che le spese di manutenzione erano insostenibili, per cui fu deciso di abbandonare la gestione della terza corsia, che in breve fu chiusa: la propaganda annunciò la notizia della chiusura con l’affermazione: [highlight]Abbiamo ridotto la strada del 33%, con un guadagno netto del 17%![/highlight]”[/blockquote2]

Si stava meglio quando si stava peggio

Questo aneddoto mi viene sempre in mente quando sento dire: “Nella nostra organizzazione siamo passati all’ e ci siamo trovati male; ora siamo tornati ai metodi di prima e siamo tutti felici“.

Qualcosa non quadra: il passaggio all’ di solito viene intrapreso da aziende o gruppi di lavoro che hanno seri problemi, tra cui di solito compaiono:

• incapacità di soddisfare le esigenze dei clienti e del mercato in generale;
• bassa velocità di delivery;
• bassa qualità del software.

Come è possibile tornare ai metodi di prima e non riavere gli stessi problemi che hanno motivato la necessità del cambiamento? Infatti il cambiamento è sempre un processo costoso, talvolta traumatico, per il singolo individuo; in una organizzazione diventa esponenzialmente complicato, quindi quando si decide di intraprendere questo avventuroso e coraggioso viaggio evidentemente ci sono seri motivi per farlo.

ha fallito, ora la frusta!

In tante organizzazioni ho avuto modo di constatare che l’abbandono di una delle tante metodologie perché “non funziona” non è spesso corredata da una valutazione analitica di cosa non ha funzionato.

Si sente dire un generico “ora torniamo alla frusta“, affermazione che in qualche modo deve soddisfare l’ego di chi la dice, ma la domanda che vi propongo è: “E’ efficace la frusta?”. E la risposta, come spesso accade, è: dipende!

Ci sono aziende e team che adottano con successo un modello e command and control e il fatto che il modello sia da preferirsi va certamente contestualizzato.

L’efficacia di una transizione all’ dipende infatti da molti fattori, tra cui:

• settore di business;
• tipologia di prodotto o servizio;
• cultura (o culturE) della propria organizzazione: è basata sulla collaborazione, sul controllo, sulle competenze individuali;
• cultura dei propri clienti.

Il movimento enfatizza il fatto che il mondo dello sviluppo software non è di produzione, ma di creazione e ancora ampiamente artigianale; gli sviluppatori non sono operai, ma creativi e knowledge workers e la mancanza di motivazione è uno dei fattori più determinanti di fallimento nei progetti software.

Chi ha ragione?

A ognuno il suo

Probabilmente il tutto si riduce alla considerazione che ogni team o azienda può utilizzare la metodologia o lo stile di management che preferisce, provando una o più metodologie per vedere se dà migliori risultati, senza pregiudizi in un senso o nell’altro. Quello che posso fare io è condividere alcuni consigli che nascono dalla mia esperienza di adozione della metodologia Scrum, in modo che possiate sperimentare una transizione all’ in modo più consapevole e corretto, anche se non necessariamente con successo.

7 consigli per adottare l’ in modo consapevole

1 – Sappi che l’ è semplice, ma non facile

Si trova moltissimo materiale sull’ e sulle diverse metodologie quali Scrum, XP, Kanban e così via. Libri come “Scrum in 5 minuti” sono ottimi condensati sulla metodologia, ma possono fare nascere l’impressione che sia sufficiente imparare Scrum da un testo di riferimento, applicarlo e tutto funzionerà come per magia. Purtroppo la verità non potrebbe essere più diversa: Scrum ad esempio è semplice da conoscere, ma non facile da attuare con successo. Questo perchè l’ non è una semplice metodologia che si può inserire all’interno di una organizzazione da soli o con l’aiuto di un trainer esterno, ma è una cultura che per dare il meglio deve essere capita e abbracciata dall’intera organizzazione.

Stiamo quindi parlando di effettuare un cambiamento organizzativo che richiede gli skill di un Agile o business coach. E’ importante essere coscienti di questi aspetti perché il cammino sarà lungo e costoso e solo voi potrete decidere se ne è valsa la pena.

2 – Chiediti a che scopo è necessario il cambiamento

E’ importante capire all’inizio quali problemi ti proponi di risolvere introducendo una metodologia o innescando qualsiasi altro cambiamento organizzativo.

In particolare è importante rispondere a domande di questo tipo:

• cosa ci proponiamo di ottenere da questo cambiamento?
• abbiamo verificato tutte le opzioni prima di scegliere la transizione all’?
• come sapremo che il cambiamento ha avuto successo?
• come misureremo il vantaggio competitivo del cambiamento?

Fermarsi a riflettere su questi aspetti e intraprendere un cambiamento consapevole è cruciale per la riuscita della transizione.

3 – Sperimenta, ma circoscrivi e misura i risultati

Ok, hai deciso di sperimentare l’. L’obiettivo di ogni esperimento è quello di essere in grado alla fine di ricavare dei risultati e per fare questo è importante avere quanti più dati possibile da analizzare. Il mio suggerimento è quindi quello di individuare un team che per svariati motivi:

• caratteristiche personali e dinamiche di gruppo;
• tipologia di progetto/prodotto/servizio al quale lavorano;
• cultura dei clienti aperta;
• modalità di interazione con il resto dell’organizzazione.

ritieni sia disposto a provare l’esperimento senza pregiudizi. L’, per il fatto di richiedere uno shift culturale, non può essere imposto, quindi se nella situazione attuale non è possibile trovare un gruppo che è ben disposto a provarlo è inutile insistere.

Una volta individuata un’area favorevole alla sperimentazione è importante valutare periodicamente (ad ogni sprint se stai usando Scrum) cosa sta succedendo, mettendosi in condizione di produrre i giusti dati e di analizzarli in modo analitico e onesto. Il mio consiglio in questa fase è di fare molta attenzione a distinguere i problemi che l’ ti crea da quelli che invece erano già presenti ma l’utilizzo di Scrum ti ha reso evidenti. Trovare problemi di cui prima si ignorava l’esistenza è già un risultato.

4 – Non essere un fanatico della metodologia …

Mi sono trovato in situazioni dove era abbastanza evidente che la metodologia Scrum era applicata alla lettera, inclusi i cerimoniali, ma i risultati erano scarsi. Il problema è che Scrum non è un fine ma un mezzo: è inutile seguire la metodologia alla lettera se non si è creato un gruppo motivato e volto al continuo miglioramento, se i clienti non sono soddisfatti, se il software prodotto è poco e di bassa qualità. Quindi il mio consiglio è: prova Scrum alla lettera fino a che non lo conosci bene, ma focalizzati sui tuoi veri obiettivi e sui valori dell’: se sei in dubbio il Manifesto ti darà sempre una risposta. Poi insieme con il tuo gruppo create il vostro set di valori e i vostri obiettivi e alle retrospettive decidete insieme cosa cambiare del vostro modo di lavorare perché funzioni al meglio per voi e per il raggiungimento degli obiettivi del team.

5 – …ma ci sono errori da evitare

Il fatto che l’ sia un cultura che richiede un cambio di approccio radicale e non una metodologia da applicare al posto di un’altra fa sì che ogni team possa trovare le proprie regole per rendere al meglio. Tuttavia ci sono alcune modalità che posso dirti che per me non hanno funzionato o che in generale sono sconsigliabili:

• non aver valutato correttamente la cultura di un team prima di proporre l’. Questo è un errore che di solito porta a una inevitabile e forte resistenza, l’ viene “risputato” o peggio viene seguita la metodologia, ma di fatto nulla cambia nell’approccio del gruppo, i risultati in termini di produttività sono peggiori di quelli precedenti;
• lo Scrum Master prima della transizione era il Project Manager del team; quello che spesso succede è che nella mente delle persone del team lo Scrum Master continua a essere il “boss” a cui riportare e questo impedisce la responsabilizzazione e la crescita del team;
• non avere uno Scrum Master nel team; in un team grande o inesperto sulla metodologia Scrum tale ruolo è indispensabile;
• il Product Owner e lo Scrum Master sono la stessa persona; Scrum prevede due figure separate proprio per creare un bilanciamento di potere che favorisca la crescita del terzo ruolo: il team. Da tutte le esperienze mie e di altri team so che questa modalità non funziona;

6 – Comunica, spiega e coinvolgi

Finora abbiamo parlato dell’adozione dell’ come di un esperimento su uno specifico team. In ogni caso, sia che l’adozione sia avvenuta top down (il management ha deciso una transizione all’ su uno più dipartimenti dell’azienda) sia che sia stata bottom up (uno o più team hanno deciso di provare l’ con l’approvazione o quantomeno con il benestare del management) è importante che chi assume il ruolo di Agile Coach all’interno dell’organizzazione abbia forti skill di comunicazione; è infatti importante sapere parlare il linguaggio dei tecnici, ma anche del business e del management per poter spiegare cosa si sta tentanto di ottenere con il cambiamento introdotto.

Questa consapevolezza è vitale per lavorare affinché un caso di successo di un cambiamento non rimanga fine a stesso, ma abbia modo di contaminare anche altre aree dell’azienda, effettuando una trasformazione radicale (anche se lenta graduale) che potrà portare tutta l’organizzazione verso un modo di lavorare più competitivo sul mercato.

7 – Lavora per il miglioramento continuo

Ricorda che la transizione all’ è l’inizio di un viaggio che non termina mai: c’è sempre modo di migliorare e c’è sempre la necessità di adeguarsi ai veloci cambiamenti del mondo del software, in modo incrementale e iterativo.

Ma non preoccuparti: non è poi così faticoso a regime e il gioco vale la candela.

Conclusioni

La gestione del cambiamento e la transizione all’ sono argomenti complessi e con questo articolo mi limito a sperare di avere acceso qualche consapevolezza in più e di evitare al lettore quegli errori che a me sono costati fatica e frustrazione. Mi piacerebbe interagire con tutti i lettori che stanno sperimentando una transizione agile nella loro organizzazione: lasciate commenti, contattatemi, sarà per me un piacere rispondere alle vostre domande, alle vostre perplessità, ricevere un feedback e condividere le nostre esperienze a riguardo.

Alla prossima!

Riferimenti

• ;
• ;
• “Agile Transition”, free eBook by Andrea Tomasini;
• “Scrum and XP from the Trenches”.