I 9 (+ 1) falsi miti sull’agile da sfatare subito!

Falsi miti sull'agile

I 9 (+ 1) falsi miti sull’agile da sfatare subito!

Indice dei contenuti

I 9 (+1) falsi miti sull’agile da sfatare subito: ma anche tu ci credi?

Provo qui a ragionare un pò sui più diffusi e radicati falsi miti sull’agile perchè di approcci agili negli ultimi tempi si parla ormai sempre più spesso (e questo è un bene!) ma spesso lo si fa senza conoscerli davvero a fondo e dando credito ad una serie di credenze e preconcetti che non hanno alcun riscontro in quella che è realmente l’essenza di questi approcci (e questo è un male!). Naturalmente, anche questa volta, troverete una mia infografica che sintetizza i contenuti del post: dovete perdonarmi ma, purtroppo, ho una necessità quasi fisica di esprimere graficamente i concetti. Buona lettura!

MITO #1: l’agile è una novità

FALSO. L’Agile non è una novità!

Il Manifesto per lo Sviluppo Agile del Software risale al 2001 e molti dei framework agili che conosciamo venivano già utilizzati in precedenza.
Solo per citare qualche esempio, Il metodo EVO di Tom Gilb risale agli anni ’70, il primo utilizzo di SCRUM risale al 1990 (da Schwaber presso la “Advanced Development Methods (ADM)” e da Sutherland presso la “Easel Corporation”). SCRUM è stato poi presentato ufficialmente alla Conferenza OOPSLA nel 1995. Nel 1996 parte il Progetto Chrysler Comprehensive Compensation System (C3) in cui Kent Beck utilizza il suo metodo eXtreme Programming (XP).

Per approfondimenti potete leggere il mio post sulla storia del movimento agile.

Quello che invece è vero è che l’agile è e rimane un approccio innovativo rispetto agli approcci tradizionali di gestione progetti e sviluppo prodotti.

MITO #2: se si utilizza un approccio Agile non si deve produrre documentazione

FALSO. L’agile non fornisce indicazioni prescrittive. OK alla documentazione se funzionale alla produzione di valore

Semmai dovremmo rifarci ai valori ed ai principi dell’Agile Manifesto.

“Working software over comprehensive documentation”. – 2^ Valore dell’Agile Manifesto

La chiave è tutta in quell’”over”: non è che la documentazione non sia importante è che il software (o il prodotto) funzionante lo è di più.

E ancora:

Working software is the primary measure of progress. – 7^ Principio dell’Agile Manifesto

E parlando poi del concetto di valore ricordiamo che:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – 1^ Principio dell’Agile Manifesto

Gli approcci agili adottano uno sviluppo guidato dal valore per cui se la documentazione aggiunge valore, serve davvero, viene realmente letta ed utilizzata da qualcuno allora ben venga. Se invece è auto-referenziale, inutile o, peggio, dannosa perché diventa un ostacolo alla comunicazione (o un pretesto per non comunicare) allora anche no, grazie! Ma questo dovrebbe andare oltre l’agile: è puro e semplice buon senso!

Inutile dire che se il nostro progetto o contratto prevede la produzione di documentazione in quanto “prodotto” che ha un valore che il cliente è disposto a pagare allora come tale va trattata, alla stessa stregua del software o di qualsiasi prodotto, servizio o risultato che il progetto deve produrre.

Infine:

“Simplicity–the art of maximizing the amount of work not done–is essential”. – 10^ Principio dell’Agile Manifesto

L’agile promuove la ”semplicità” e l’essenzialità: massimizzare la quantità di lavoro non svolto limitandoci a fare ciò che produce valore: nulla di meno e nulla di più. Il resto è spreco, waste, muda!

MITO #3: Agile significa “nessuna progettazione”

FALSO. Assolutamente no, anzi: il design è onnipresente nello sviluppo agile e non relegato alle sole fasi iniziali del progetto.

Infatti ciò che è contrario alla filosofia agile è di spendere inutilmente troppo tempo e troppe risorse in attività di up-front design nelle fasi iniziali del progetto preferendo invece lo stile di progettazione “emergente” del continuo refactoring.

MITO #4: Agile significa “nessuna pianificazione”

FALSO. Vale quanto detto per la progettazione. La pianificazione è onnipresente negli approcci agili e non relegata alle sole fasi iniziali del progetto.

Non solo in agile si pianifica ma lo si fa durante tutto il ciclo di vita del progetto anziché all’inizio, come avviene spesso nei progetti tradizionali producendo un piano iperdettagliato che, nella migliore delle ipotesi, diventa obsoleto 5 minuti dopo la sua creazione e, molto spesso, viene aggiornato solo alla fine del progetto o prima di ogni stato di avanzamento solo perché “il cliente lo vuole vedere”.

Anche qui una iperpianificazione iniziale è solo un inutile spreco.

I Team Agili accettano l’idea che più lontano è il futuro che si cerca di pianificare maggiore sarà il livello di incertezza ed il margine di errore che si dovrà accettare.

E’ il concetto di Planning Horizon per cui un team agile pianifica a livello di:

  • Prodotto
  • Release
  • Iterazione
  • Giornata di lavoro

La Planning Onion rappresenta graficamente i livelli di pianificazione di un progetto agile:

 

Agile Planning Onion

Agile Planning Onion

 

  • Strategy: la visione strategica si trova nello strato più esterno perchè definisce gli obiettivi di business dell’organizzazione, ciò che è e ciò che aspira a diventare. In genere copre un orizzonte compreso tra 1 e 5 anni e l’ownership è demandata al board aziendale che ha il compito di diffonderla e trasmetterla a tutti I livelli dell’organizzazione;
  • Portfolio: lo strato che rappresenta l’offerta complessiva in termine di prodotti e servizi . Anche questo livello di pianificazione è responsabilità del board aziendale;
  • Product: questo livello di pianificazione è compito del team agile (se il progetto adotta Scrum ad esempio, spetta al Product Owner) che delinea la propria vision e la roadmap di prodotto. Tipicamente traguarda un orizzonte temporale di circa 12 mesi;
  • Release: La pianificazione dei rilasci (release) di prodotto guida lo sviluppo del prodotto verso l’obiettivo finale rappresentato dalla vision. Anche qui il compito è del team (del Product Owner in Scrum) e l’orizzonte temporale è generalmente trimestrale;
  • Iteration: il team agile pianifica ogni iterazione (lo Sprint di Scrum), intervallo temporale time-boxed, della durata compresa generalmente tra 1 e 4 settimane, per sviluppare un incremento di prodotto auto-consistente e potenzialmente rilasciabile basandosi sulle priorità di business indicate dal cliente in funzione del valore attribuito alle singole features del prodotto;
  • Day: il team agile pianifica la singola giornata di lavoro per stabilire la tabella di marcia e l’insieme delle azioni necessarie a perseguire gli obiettivi stabiliti per ogni singolo requisito

MITO #5: in un progetto agile regna l’anarchia

FALSO. Un progetto agile segue un approccio rigoroso e si basa sulla responsabilità dei singoli nel perseguire un obiettivo condiviso.

I progetti agili si basano su processi snelli che minimizzano colli di bottiglia, sprechi e burocrazia superflua. Seguono poche ma rigorose regole e responsabilità distribuite all’interno del team: il Customer Representative (o il Product Owner) ha la responsabilità del prodotto mentre il team quello del processo di sviluppo.

Un team agile non deve ricorrere alle leve dell’autorità perché a guidarlo è l’insieme dei valori e dei principi descritti nel Manifesto.

MITO #6: l’agile non è adatto a progetti con scadenza o budget fissi

FALSO. Gli approcci agili funzionano meglio in progetti con scadenza e budget fissi.

DSDM (Dynamic Systems Development Method) è stato il primo tra gli approcci agili a proporre un Modello di Triangolo Invertito che rimanda ad un concetto di “fit for business purpose”: massimizzare il valore di business realizzato rispetto ai vincoli dati in termini di tempi e costi .

Diversamente dagli approcci tradizionali quindi gli approcci agili considerano variabile lo Scope, accogliendone in modo flessibile e dinamico le variazioni (Change) e tentano di realizzare il massimo valore possibile nella cornice prestabilita di tempi e budget.

 

Iron Triangle VS Agile Triangle

Iron Triangle VS Agile Triangle


  • L’ IRON TRIANGLE (a sinistra nell’immagine) sintetizza l’approccio tradizionale o Waterfall in cui  lo scope viene fissato all’inizio del progetto. e, a fronte dei change, tempi e costi subiscono variazioni
  • L’ AGILE TRIANGLE (a destra nell’immagine) descrive l’approccio agile in cui il valore rilasciato (e quindi lo scope) viene massimizzato tenendo conto dei vincoli imposti di tempi e costi.

MITO #7: l’agile è adatto solo ai progetti piccoli

FALSO. L’Agile può essere scalato ed essere utilizzato con successo anche in grandi progetti.

Un progetto grande è sempre una sfida, a prescindere dall’approccio utilizzato.

Il vantaggio degli approcci agili, rispetto ai metodi tradizionali, è che ci consentono di gestire un progetto di grandi dimensioni suddividendolo i piccoli iterazioni che lo rendono più facilmente gestibile.

Inoltre sono disponibili ormai diversi framework che consentono di “scalare” agile per progetti che, per le loro dimensioni, presentano la necessità di coordinare più team di lavoro.

MITO #8: l’agile è adatto solo ai progetti software

FALSO. L’agile può essere adottato con successo in molti i contesti produttivi.

E’ vero, l’agile è nato nel contesto della produzione di software ed il Manifesto Agile è stato scritto con l’obiettivo di trovare “better ways of developing software” ma oggi il suo utilizzo travalica il contesto originario e l’agile viene utilizzato con successo in molti ambiti diversi.

The Lean Startup” è il libro, pubblicato da Eric Ries nel 2011, che ha riscosso un successo tale da andare probabilmente oltre le stesse aspettative dell’autore e, da caso letterario, si è trasformato in un vero e proprio movimento globale con meetup che si svolgono in tutte le capitali mondiali ed europee. Rappresenta un eccellente esempio del passaggio dei principi agili dall’iniziale ed esclusivo dominio del software al contesto molto più ampio del management aziendale.

MITO #9: l’agile è un “Silver Bullet”

FALSO. L’agile non è un rimedio per tutto.

L’agile non è un rimedio a tutto ciò che può andare storto in una iniziativa di business ma, sicuramente, ha delle caratteristiche che possono aumentarne le probabilità di successo.

Ad esempio:

  • contribuisce a ridurre i rischi
  • aumenta la visibilità
  • fornisce un miglior controllo sullo stato di avanzamento
  • favorisce la collaborazione
  • promuove una comunicazione più efficiente

MITO #10: questo non è il momento giusto!

FALSO. Il momento giusto è sempre quello in cui se ne avverte l’esigenza.

Questa frase (e tutte le variazioni sul tema) ricordano quello che raccontiamo a noi stessi quando dobbiamo metterci a dieta (sempre “da Lunedì” o “dopo Natale” !) o smettere di fumare (“dall’inizio dell’anno” o “dopo il mio compleanno” !): sono solo scuse per rimandare una decisione!

When there is a hill to climb don’t think that waiting will make it smaller

La verità è che il momento giusto è ora, subito, quando si avverte l’esigenza di cambiare.

Con questo chiudo sperando che la lettura sia stata piacevole e di aver contribuito almeno un po’ a scardinare qualche falsa credenza sull’agile.

Naturalmente mi farà piacere ricevere qualsiasi tuo commento o riflessione sull’argomento.

Alla prossima e … Stay Agile !

No Comments

Give a comment