Perché fare Agile è così difficile?

"Leggere i libri di XP mi folgorò. Era evidente che quello fosse il modo migliore di fare software! Mettere in pratica XP, però, non è mai stato facile. Anni dopo ho imparato Scrum, che sembra molto più semplice. Eppure anche fare bene Scrum non è facile. Poi è arrivato Kanban, che sembra ancora più semplice. E ancora una volta, applicarlo bene non è facile. Che ci sia sotto qualcosa?"

Comincia così l’abstract del keynote  che Matteo Vaccari terrà domani,  15 novembre, alla conferenza Italian Agile Day di quest’anno, keynote dal quale abbiamo preso spunto per intavolare una discussione all’interno del team di AgilReloaed, provando a fornire, ognuno di noi, un proprio punto di vista.

E’ Matteo che ci lancia lo spunto per la discussione con queste considerazioni: “Se è vero come è vero che XP/Scrum/Kanban sono una maniera chiaramente migliore di fare le cose, dimostrata in molte occasioni, come mai sono così poche le organizzazioni che ottengono risultati spettacolari con XP/Scrum/Kanban?

La discussione non si è fatta attendere. Fabio interviene con la seguente osservazione: “Scrum, come tutte le metodologie agili sono difficili da applicare perché richiede disciplina e essere disciplinati è faticoso: agile richiede infatti coesione aziendale in verticale e in orizzontale.  Ambedue faticosi. Spesso delegare responsabilità a persone non abituate all’auto organizzazione è visto estremamente rischioso e per questo spesso di preferisce non cominciare nemmeno. Poi ci si chiede, magari tramite una retrospettiva in stile 5 Whys come mai non è possibile educare e fare decollare agile in azienda

Qualcuno propone di andare sul sicuro: “Lo chiediamo a lui?” Citando un famoso libro d Jeff Sutherland (“The art of doing twice in half time”)

Stefano è sicuro che “i motivi principali del perché è difficile fare Agile sono descritti nell’agile manifesto”, e aggiunge: “oltre a trovarmi perfettamente in linea con quanto dice Fabio, aggiungo che molte persone cercano dei metodi di lavoro che forniscano delle ricette che se applicate pedissequamente portano al successo. Qui siamo invece di fronte a un set di principi e valori che se non sposi non ti portano da nessuna parte. Per di più Scrum è pure semplice da spiegare e in 20 pagine di primer ti porti a casa il metodo….ma non certo principi e valori. 

Pierluigi allarga la discussione coinvolgendo temi più ampi: “La risposta più semplice che posso proporre è che un’azienda grande è in generale più disfunzionale rispetto a un’azienda piccola; spesso deve la sua posizione sul mercato più per averla ottenuta con acquisizioni, prezzi insostenibili per la concorrenza (a volte non sostenibili nemmeno per se stessa), monopoli, appoggi politici, piuttosto che per vera capacità di competere.

Questo è valido sia che l’azienda usi agile sia che non lo usi: più grande l’azienda più è difficile che funzioni anche con agile.”

Poi Pierluigi prosegue con una valutazione più puntuale sulle metodologie agili:

La seconda risposta che proporrei è che il funzionamento dei vari metodi agili è estremamente dipendente dalla capacità delle persone che lo usano di capirne la cultura, e su questo o non siamo ancora in grado di trasmettere una tale cultura o è troppo complicata da trasmettere. Ci arriveremo mai? O dobbiamo aspettare che cambi la testa delle persone?

Giovanni prova a fornire il suo parere: “nelle aziende grandi spesso la gerarchia blocca o comunque rallenta la snellezza di certe decisioni. Quando parliamo di gerarchia non è sempre detto che sia un problema di command and control, ma semplicemente di una macchina che per mettersi in moto o per fare una attività semplice ci mette un sacco tempo ed energie. Ovviamente non possiamo fare esempi o citare nomi, ma tutti noi come consulenti esterni abbiamo assistito a progetti rallentati per lungaggini burocratiche che bloccavano attività di per se molto semplici (attivare un account di posta, sbloccare una porta di un firewall o altro). In casi come questi spesso la gerarchia è più una scusa che altro, dove il vero problema è una assenza totale dell’attenzione alla qualità. Spesso i problemi che si incontrano non si risolvono in tempi rapidi per la credenza che sia colpa della grande macchina, mentre spesso manca più semplicemente il commitment, la mancanza di capacità di prendere in carico in prima persona i problemi, la voglia di risolvere, il non voler realmente valutare gli impatti di atteggiamenti poco efficaci. Spesso meglio far finta che vada bene così, piuttosto che porci troppe domande o obiettivi difficili.”

Marco invece prova ad aggiungere un punto di vista differente: “le pratiche di sviluppo (e strategia) lean e agile siano ottimi strumenti di razionalizzazione/coordinamento del lavoro. Funzionano in modo eccellente quando sono rivolte a minimizzare i rischi tipici del lavoro sul software. Le implicazioni infatti sono complesse e tutto quello che noi conosciamo, usiamo, e insegniamo in qualità di consulenti va nella direzione di ridurre la complessità o (meglio) di visualizzarla e permettere alle persone di comportarsi in modo adeguato per preservare la produzione di valore. Secondo me questi “strumenti” funzionano pure, ho visto prodotti con migliore qualità, rilasciati prima, clienti più soddisfatti, team più sereni. 

Detto questo, sono strumenti inseriti in un ambito che dipende quasi esclusivamente dalle persone e dai loro comportamenti. Qualsiasi pratica o procedura ha effetti differenti in base a chi, come, dove viene applicata, che si tratti di adozione o trasformazione. Le rogne su agile e compagnia bella arrivano (iniziano a manifestarsi) quando il confine del “sistema” si allarga e, oltre alla tecnologia, si devono gestire personalità, carriere, soldi, organizzazione aziendale. È una costante del mio lavoro: non è sufficiente sposare valori e appassionarsi delle metodologie perché un prodotto funzioni. Neppure studi di mercato, lean startup, top notch developer e via dicendo. Gli stessi ingredienti che possono favorire la creazione di un prodotto di qualità possono trasformarsi in perdita di tempo e di soldi in contesti culturali e psicologici differenti. Ma quando parlo di cultura, detto tra noi, non parlo di cultura del software o delle organizzazioni, ma anche di cultura generale e di umanesimo. Senza parlare della presenza mentale. La maggior parte della perdita di tempo nelle organizzazioni non è nella mancanza di requisiti chiari per il software secondo me… è data dalle singole disfunzioni delle persone e nell’incapacità di coordinare se stessi e gli altri. C’è una forte difficoltà nel garantire attenzione e concentrazione sul proprio lavoro.

A condurre una riunione senza perdere il tempo di tutti o senza che si sia definito un piano d’azione. A parlarsi con sufficiente trasparenza perché il messaggio non si trasformi da un ufficio all’altro o da una postazione all’altra. A chiudere Skype quando si fa un lavoro importante. Spesso non riusciamo a prenderci il tempo per pensare, o non possiamo o non crediamo di poterlo fare.

Lean e Agile vengono dal buon senso e sono la riduzione di concetti presenti già in ambito psicologico, religioso, organizzativo e militare.

E’ plausibile che siano stati adottati e fatti propri da una comunità di persone che si è sempre voluta distinguere quanto più possibile dal “lato umano” della complessità; probabilmente spesso illudendosi che retrospettive, condivisioni e working agreement potessero compensare un’attenzione insufficiente a queste dinamiche. 

Io dico che in realtà si tratta di facilitazioni, non di soluzioni. Il resto del casino è ancora davanti a noi e non dipende da Waterfall o da Scrumbut, dipende dalla testa delle persone, a tutti i livelli. 

Uno dei (pochi?) indiscutibili vantaggi che lean e agile portano in tutte le organizzazioni credo sia l’opportunità di scoprire prima possibile che qualcosa non sta andando nel verso giusto. Quale sia il verso (e cosa significhi “giusto”) dipende purtroppo da molte cose che non hanno a che fare con il software.”

La discussione si è fatta molto interessante…. Non resta che andare ad Ancona il 15 e 16 Novembre per assistere al keynote di Matteo all’Italian Agile Day, oltre  che ad altri interessanti contributi.