Tutta la verità su Agile: cosa è, a cosa serve

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:

1. Perchè usare Agile?
2. Definizione Agile
3. Manifesto Agile
4. Come funziona il metodo Waterfall
5. I 12 Principi del Manifesto Agile
6. A Cosa serve Agile

Perchè vuoi usare Agile?

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.

Definizione Agile

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.

Manifesto Agile e valori fondamentali

“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:

1. Gli individui e le interazioni più che i processi e gli strumenti
   
2. Il software funzionante più che la documentazione esaustiva
   
3. La collaborazione col cliente più che la negoziazione dei contratti
   
4. Rispondere al cambiamento più che seguire un piano

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.

Come funziona il metodo Waterfall

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.

I 12 Principi del Manifesto Agile

1. La nostra assoluta priorità è quella di soddisfare il cliente rilasciando continuamente e velocemente software che generi valore.
2. Le modifiche ai requisiti sono accettate anche a sviluppo già iniziato. I processi Agile sfruttano i cambiamenti per aumentare al cliente un vantaggio competitivo.
3. Rilasciamo frequentemente software funzionante, a intervalli che possono andare da un paio di settimane a un paio di mesi, dando preferenza ai periodi più brevi.
4. Le persone del business e gli sviluppatori devono lavorare insieme ogni giorno per l’intera durata del progetto.
5. Abbiamo fiducia che le persone che portano avanti il progetto, siano motivate. Abbiamo fornito loro le risorse e l’ambiente necessari per lavorare.
6. La comunicazione faccia a faccia è il modo più efficace ed efficiente per comunicare in un team di sviluppo.
7. Ia più importante misura di avanzamento dei lavori è software che funziona.
8. I processi Agile promuovono lo sviluppo sostenibile. Sponsor, sviluppatori e utenti devono essere in grado di mantenere un ritmo di lavoro costante per un periodo di tempo indefinito.
9. L’attenzione costante alla buona progettazione (design) e all’eccellenza tecnica aumenta l’agilità.
10. La semplicità, ovvero l’arte di massimizzare il lavoro che non viene fatto, è essenziale.
11. I team che si organizzano da soli realizzano le migliori architetture, requisiti e progetti.
12. A intervalli regolari il team deve riflettere su come diventare più efficace e modificare di conseguenza il proprio modo di agire.

 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.

Quindi? A cosa serve Agile?

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.

Perchè il Mindset Agile è più importante delle singole tecniche

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: