"Scusa, ma Agile non migliora i tuoi prodotti"
Abbiamo già pubblicato il post del blog di Jeff Sutherland, in cui risponde a un post di Adam Pisoni che sostiene che Agile in realtà non migliori i tuoi prodotti. Ecco ora proprio quel post di Adam Pisoni, cofondatore ed ex direttore tecnico di Yammer e fondatore di Responsive.org.
Se non leggi regolarmente i lavori di Steve Denning, ti consiglio di farlo. È uno dei migliori autori quando si parla del futuro del lavoro. In un articolo scritto per Forbes, dice che lo sviluppo agile dei prodotti è diventato mainstream, ma si chiede anche se nel frattempo sia diventato una moda passeggera come tante altre teorie di management. La sua conclusione è che Agile non è realmente una moda, perché
“Agile e Scrum affrontano direttamente le attuali questioni aziendali, che le iniziative del XX secolo hanno evitato. In Agile e Scrum, i clienti ottengono una voce attraverso il Product Owner e le competenze vengono poste al di sopra dell'autorità.”
Sebbene io sia fondamentalmente d'accordo con molte cose nel suo articolo, devo dissentire dalla sua conclusione. Agile ha effettivamente fatto un buon passo nella giusta direzione, ma per me non è sufficiente. Prima di Agile, capitava troppo spesso che i team impiegassero enormi quantità di tempo e risorse per costruire qualcosa, solo per scoprire al momento del completamento che il cliente non lo voleva affatto.
Agile doveva soprattutto rendere possibile costruire prodotti di successo in un mondo che cambia troppo velocemente per poter prevedere cosa vogliono le persone e come costruirlo al meglio per loro.
Sebbene Agile abbia insegnato a un'intera generazione di sviluppatori software l'importanza della sperimentazione e del feedback dei clienti, Agile non è riuscito a cambiare il vecchio sistema centralizzato di Command and Control nel management, che rappresenta gran parte del problema. Anche con Agile, gli sviluppatori che hanno troppo poco potere e troppo poco contesto impiegano troppo tempo per sviluppare prodotti che i clienti in realtà non vogliono. Il risultato sono clienti insoddisfatti, sviluppatori demotivati e manager frustrati.
Solo per informazione, dal 1995 al 2014 sono stato sempre – con una breve interruzione dopo lo scoppio della prima bolla delle dot-com – o uno sviluppatore software a tempo pieno o un team leader di team di sviluppo. Nel 1997 dirigevo un team che usava il metodo Waterfall (predecessore di Agile). Con Waterfall si faceva tutto il lavoro di design e pianificazione in anticipo, dando per scontato che poi si potesse suddividere e completare il lavoro.
Nel 2004 lavoravo per un'azienda che faceva molto affidamento sull'analisi e sugli A/B test e aveva persino release settimanali – con tutto ciò era avanti rispetto ai tempi. Ricordo quando la gente parlò per la prima volta di Scrum, e ricordo che avevo un'idea chiara del problema che stavo cercando di risolvere: cattivo management.
Per onestà devo dire che ho riletto il Manifesto Agile e i suoi principi e concordo con ogni singolo punto. Sono ancora altrettanto validi e pertinenti oggi come lo erano nel 2001, quando furono scritti. In Agile si dovrebbe costruire qualcosa iterativamente e imparare continuamente durante il processo, invece di seguire un grande piano. Inoltre, il cliente dovrebbe essere un confidente stretto durante l'intero processo, in modo da poter imparare da lui durante l'intera fase di sviluppo. Dato che l'obiettivo dovrebbe essere assorbire costantemente nuove informazioni, bisognerebbe anche dare per scontato di cambiare regolarmente direzione.
Prima di Agile, il management creava un piano che documentava esattamente (prevedeva) cosa doveva essere costruito, come doveva essere costruito e quanto tempo avrebbe richiesto – quest'ultimo essendo la parte forse più importante. Come sappiamo, questi piani erano difficilmente prevedibili e raramente potevano essere rispettati. Il risultato erano aspettative e scadenze irrealistiche.
A peggiorare le cose, a causa del ritardo temporale tra il completamento del piano e la consegna del prodotto, era molto probabile che il management cambiasse idea sul prodotto senza alcuna comprensione dei costi. Questo naturalmente irritava molti sviluppatori, il cui lavoro era eseguire il "piano". Ciò significava che la situazione con scadenze irrealistiche peggiorava ulteriormente e costringeva molti team a fare ancora più pianificazione per ridurre al minimo i cambiamenti successivi. Ironicamente, la mancanza di trasparenza nel processo di sviluppo dava ai team di sviluppo più autonomia nel decidere in quale ordine svolgere i lavori, come costruirli, chi dovesse farlo ecc. Naturalmente, la conseguenza di questo tipo di autonomia e della mancanza di trasparenza è spesso sfiducia tra management e team di sviluppo. Alla fine, nessuno era felice.
E poi arrivò SCRUM. Doveva aumentare la trasparenza nel processo e migliorare l'efficienza nello sviluppo. Settimanalmente, i manager potevano decidere quali Story (o feature) volevano successivamente e gli sviluppatori potevano stimare quanto tempo e risorse avrebbero necessitato. Il team poteva quindi determinare i costi totali di tutte le Story prioritizzate e scoprire quanto di quel lavoro potevano pianificare per il prossimo Sprint.
Scrum ha aumentato drasticamente la trasparenza e ha reso più difficile per i manager pretendere più di quanto si potesse effettivamente realizzare. È stata anche considerata la necessità di aggiornare i piani in modo iterativo. Tuttavia, con la maggiore trasparenza di Scrum, gli sviluppatori hanno ancora meno autonomia di prima. I poteri degli sviluppatori sono stati ridotti a stabilire quanto tempo serva per qualcosa e a scegliere la prossima Story da un elenco in gran parte definito dal management.
Uno sviluppatore che lavora su una Story potrebbe non avere alcuna idea dei contesti e del perché quella Story sia così importante o quale sia l'iniziativa dietro di essa.
Anche se Scrum è riuscito a frenare i manager impulsivi, alla fine si è trattato comunque di esercitare più controllo sugli sviluppatori e sul loro lavoro.
Ancora il management prende le decisioni, prioritizza le feature e stabilisce chi lavora a cosa in quale team. Con il suo focus sulla stima dell'effort per lavori predefiniti e poco contesto, Scrum guarda indietro all'inizio del secolo, quando Frederick Taylor dava istruzioni dettagliate agli operai.
Nel Taylorismo si presume che i manager siano quelli che hanno la competenza e il contesto per poter dire su cosa si dovrebbe lavorare. Quindi era loro compito dare ai dipendenti piani dettagliati, affinché questi dovessero prendere il minor numero possibile di decisioni proprie.
Abbastanza in fondo ai Principi Agili compare un principio piuttosto fuori posto, che viene ignorato da Scrum:
Le migliori architetture, requisiti e design emergono da team auto-organizzati.
Teoricamente è possibile usare Scrum per il tracciamento del lavoro in team auto-organizzati, tuttavia questo non è previsto e accade molto raramente. La maggior parte dei libri su Scrum affronta l'argomento dalla prospettiva del management top-down e non attraverso l'auto-organizzazione.
Agile è stato un passo importante per riconoscere quanto siano importanti il testing e il lavoro iterativo basato sul feedback dei clienti. In gran parte, però, è orientato a una maggiore efficienza e controllo vs. empowerment piuttosto che a team auto-organizzati. Uno degli autori del Manifesto Agile, Andy Hunt, la vede allo stesso modo.
Naturalmente si può sostenere che Agile non sia il problema, ma metodi come Scrum. Questa sottile distinzione si perde però, dato che Scrum e Agile sono diventati quasi sinonimi. Quando Agile è diventato più conosciuto, è stato purtroppo strumentalizzato dai tradizionali modelli Command and Control, da cui sono nati metodi come Scrum.
Qual è l'alternativa? Dai un'occhiata ai metodi di sviluppo di Spotify o alle strutture di Yammer. Invece di sovraccaricare singole persone di lavoro, dai ai team più autonomia per decidere cosa vogliono costruire e come. Questi team sono inoltre composti da persone delle discipline più diverse, per assicurare che possano fare tutto il necessario senza dover aspettare il permesso o il supporto di altri.
Che tu stia attualmente lavorando con Scrum nella tua organizzazione o meno – se hai la sensazione di procedere troppo lentamente e di non costruire ciò che i tuoi clienti vogliono, ci sono diverse possibilità per sperimentare con nuovi modelli senza dover cambiare tutto in una volta.
Scegli un progetto e metti insieme un piccolo team dedicato con persone che hanno tutte le competenze necessarie, anche se queste persone hanno manager diversi. Presenta loro il problema e dai loro la possibilità di risolverlo come ritengono opportuno.
Idealmente, questo progetto è abbastanza breve da poter verificare rapidamente se l'esperimento funziona. Se sei riluttante a concedere questa responsabilità al team, hai scelto le persone sbagliate oppure il problema potrebbe essere in te stesso. Chiamarlo "esperimento" può aiutarti a vendere la tua idea. Molto probabilmente scoprirai che piccoli team dedicati e multifunzionali di esperti possono realizzare enormemente tanto in pochissimo tempo.
La prossima sfida è capire come scalarlo, nel caso dovesse funzionare. Per questo servono normalmente nuove soluzioni, che portano a nuovi problemi, per cui servono di nuovo nuove soluzioni. Non è facile, ma ne vale la pena.
Ti accorgerai che funziona quando il tuo team riesce a presentare ai clienti più idee nuove e più velocemente di prima. Questo è l'obiettivo.
L'autonomia richiede fiducia e questa a sua volta richiede un contesto condiviso. È per questo che questi modelli più recenti dipendono dalla completa trasparenza, quando tutti devono essere tenuti aggiornati. In Yammer avevamo team di progetto di breve durata, così che le persone avessero più opportunità di lavorare davvero e di imparare dalle persone più diverse – ma questo è solo un modo di affrontare la questione.
Non basta che il management sia solo il portavoce dei clienti. Gli sviluppatori e i designer devono comprendere e interiorizzare personalmente i bisogni e gli obiettivi delle persone per cui stanno costruendo qualcosa.
Agile è stato un passo importante lontano dalle organizzazioni e dai metodi dell'era industriale. Se però vuoi creare un'organizzazione per il XXI secolo, dovrai guardare oltre Agile verso modelli più recenti che distribuiscono l'autorità, sono auto-organizzati e invitano davvero i tuoi clienti, partner e collaboratori a diventare "Owner" del processo.
Questo testo proviene dal Blog di First Round ed è stato tradotto in italiano.
Per gli Scrum Master offriamo i seguenti corsi di formazione e opportunità di aggiornamento gratuito:
