Ottobre 3, 2019 - di Marco Imperato
In questo post scoprirai cosa è Agile, cosa è, ma soprattutto ti dirò cosa non è assolutamente. Vedremo anche i valori di base, i 12 principi e perchè ha cambiato in meglio lo sviluppo di software, e quindi di prodotto.
Questo è il primo post di una serie un po’ più tecnica sull’organizzazione del lavoro di team di prodotto. Ho visto infatti che anche se spesso si comprendono le logiche di base sul “perchè fare una certa cosa”, spesso i team si incartano su come poi metterla in pratica e fare progressi.
Parto dal tema Agile perchè tutti ne parlano, tanti (purtroppo) lo usano senza comprenderne le logiche di base facendo più danni che altro. Visto che ci sono passato anch’io, vorrei aiutarti evitandoti errori inutili che ti fanno perdere tempo e soldi.
Ecco cosa troverai:
Circa un anno fa ricevetti una chiamata da un’amica, responsabile Design in un’agenzia specializzata in applicazioni, wordpress, Ecommerce, etc.
“Marco il mio capo mi ha detto che vorrebbe utilizzare la metodologia Agile con i suoi clienti, non l’hanno mai fatto e vorrebbero capire da dove iniziare. Ci aiuti?”
Ci siamo sentiti qualche giorno dopo.
Dopo i primi convenevoli la chiamata è andata più o meno così.
Io: “Perchè volete utilizzare Agile?”
Agenzia: “Perchè ai clienti piace”
Io: “Cosa piace?”
Agenzia: “Piace Agile, un paio di clienti ce lo hanno chiesto…”.
Io: “ Ok, ma perchè?”
Agenzia: “Perchè lo usano tutti”
Io: “Ok, Quanto durano mediamente i progetti che seguite per i clienti?”
Agenzia: “4-6 mesi”
Io: “Di solito i clienti hanno chiari gli obiettivi che vogliono raggiungere e gli utenti per cui vogliono sviluppare i propri prodotti?”
Agenzia: “Difficilmente”
Io: “Quali sono i criteri che il cliente utilizza per valutare il vostro lavoro?”
Agenzia: “Se noi facciamo tutto quello che ci chiedono, velocemente, bello e funzionante,”
Io: “bello?”
Agenzia: “Sì, secondo il cliente”.
Io: “Secondo te il cliente sarebbe felice di avere dei rilasci più frequenti invece di un unico rilascio finale?”
Agenzia: “Certo sarebbe felicissimo”
Io: “Ma dopo questi rilasci sarebbero disposti a dare in mano agli utenti (ancora non identificati) il proprio prodotto anche se non è proprio come se lo sono immaginati?”
Agenzia: “Impossibile, il prodotto deve essere perfetto”.
Ti lascio immaginare come la conversazione è andata avanti…
Purtroppo quando inizia a girare una nuova buzzword tutti ne vogliono un pezzo, tutti lo vogliono fare. Accade per ogni cosa praticamente: OKR, MVP, etc. Il rischio è quello però di svilire e sminuire il radicale cambiamento in meglio che quella metodologia ha portato.
Ancora peggio, applicare un qualcosa di cui si è sentito parlare senza averne sposato i valori e i principi sottostanti può causare danni importanti. Basti pensare a team che parlano di MVP, impiegano mesi a sviluppare qualcosa, senza aver chiaro perché ha senso creare un MVP e si ritrovano dopo mesi con una versione parziale di prodotto con cui non sanno bene cosa fare.
La prima cosa che ti dirò è la più difficile da accettare.
L’Agile NON è:
– una metodologia!
– un framework
– un processo
– una tecnica.
L’Agile è un insieme di principi e valori. Sulla cui base successivamente sono stati costruiti dei Framework come Scrum o Kanban.
Se cerchi la ricetta magica, il solito framework da copiare, purtroppo l’Agile non ti può aiutare.
Se non condividi il pensiero di fondo e non pensi sia il modo giusto di lavorare allora, i framework (Scrum, Kanban) costruiti sull’Agile non ti serviranno a nulla.
“Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso. Grazie a questa attività siamo arrivati a considerare importanti:
Ovvero, fermo restando il valore delle voci a destra, consideriamo più importanti le voci a sinistra.”
Estratto da Agilemanifesto.org. Da dove è cominciato tutto nel 2001.
Questi concetti che oggi sembrano assolutamente normali e scontati per chi fa sviluppo di prodotto, 18 anni fa quando l’unico approccio conosciuto era il Waterfall sono stati davvero rivoluzionari.
Basti pensare che nello sviluppo Waterfall esistono di solito 5 fasi (Requisiti, Progettazione, Implementazione, Verifica, Mantenimento) che non possono mai essere mischiate. Ogni fase va sempre documentata e si può passare alla fase successiva solo dopo che si è completata quelle precedente.
Tutto deve essere pianificato e nessuna modifica può essere accettata.
La credenza comune, nel Waterfall, è che risolvere le discrepanze o definire i requisiti accuratamente all’inizio del progetto faccia risparmiare tempo dopo. Cosa che nello sviluppo software in media non è quasi mai vera. L’accuratezza di previsione ce l’hai solo quando stai sviluppando.
La base di tutto il movimento Agile può essere riassunta nella fiducia verso che chi sviluppa il software e quindi nell’ownership del team.
Al Manifesto principale sono stati aggiunti 12 principi, che rendono tutto ancora più comprensibile.
Da https://agilemanifesto.org/iso/it/principles.html
Come avrai visto nei 12 principi sono contenute tante teorie e pratiche utilizzate e diffuse oggi, come l’approccio Lean, il continuous deployment, i team cross-funzionali,, etc.
L’Agile non prende decisioni per te, ma ti dà le fondamenta grazie alle quali ti sarà più semplice prendere decisioni.
La svolta di Agile è stata quella di aver formalizzato dei principi base a cui potersi ispirare per prendere decisioni sul “miglior software” da sviluppare, quando i tempi stavano cambiando e il modo di lavorare attuale non andava più.
Devi considerare che ogni sviluppatore, designer, PM, prende centinaia di decisioni ogni settimana su cosa fare e come farlo. Avere questa base comune è fondamentale.
Esempio: se uno di principi cardine è rilasciare solo cose che portano valore al customer, allora quando uno sviluppatore dovrà scegliere se sviluppare un nuovo pezzo di software per raggiungere l’obiettivo di sprint (sforando i tempi) o usare una soluzione esistente low-cost (nei tempi stabiliti) sceglierà sicuramente la seconda. Lo spreco è il nemico!
Se sei un responsabile di prodotto, come ripeto sempre, è molto più importante il modo in cui prendi decisioni, che le singole decisioni che prendi.
Update: riteniamo il Mindset Agile così importante che gli abbiamo dedicato un intero post.
Lo trovi qui > Agile Mindset: cosa è, esempi reali e casi pratici]
Nel momento in cui Agile non è una metodologia o una tecnica, ma un insieme di Valori e principi ti potrà sembrare una fregatura, se sei alla ricerca del framework già pronto.
In realtà se hai intenzione di lavorare nello sviluppo di prodotto per tanto tempo è molto più utile per te che sia così.
I team di prodotto cambiano nel tempo, cambiano al variare della dimensione dell’azienda, della nuova tecnologia utilizzata, etc. le pratiche e le tecniche cambieranno sempre. E’ molto più importante quindi condividere dei principi di base che durino nel tempo e diano solidità al gruppo.
Nella mia esperienza ho provato veramente di tutto e posso dirti che i maggiori casini li ho creati quando cercavo di trovare “l’organizzazione perfetta” copiata da Twitter, Spotify e simili. Perdevo più tempo a capire come loro facevano piuttosto di focalizzarmi sui valori di base da condividere e che andavano bene per il mio team, in base al prodotto su cui stavamo lavorando.
E’ la stessa cosa che succede in un’azienda ed è il motivo per cui è decisivo definire i valori e la cultura aziendale. Questi ti danno la mappa in base a cui prendere decisioni.
Tutto chiaro fin qui?
Se hai subbi scrivili nei commenti perchè nel prossimo post affronteremo le due metodologie più diffuse che sono nate grazie ai principi Agile, ovvero Scrum e Kanban.
Update: Qui trovi il post su Scrum e Kanban
Qui trovi la Guida Completa su Agile Scrum:
Co-Founder e Amministratore di Edgemony, società che fonda nel 2020, con il duplice obiettivo di accelerare lo sviluppo del territorio siciliano grazie alle competenze digitali e aiutare aiuta le aziende italiane, e non, a estendere in Sicilia il proprio Tech Team. Crea Product Heroes a fine 2018, la prima community per Product Manager in Italia che conta 6.000 iscritti alla newsletter. Product Heroes è il punto di riferimento per chi fa prodotto, e ha aiutato fino a oggi oltre 180.000 product lovers grazie al Master in Product Management, Programmi B2B, Contenuti ed Eventi on the ground. Dal 2008 guida il dipartimento di Prodotto e Digital Media di Mosaicoon, dal giorno della creazione fino alla chiusura per fallimento 10 anni dopo.
Le slide sono disponibili per studenti ed ex studenti del Master in Product Management