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

Alessandra FilippettiAgile Zone, Blog, Uncategorized4 Comments

Di agile negli ultimi tempi si comincia a parlare molto anche in italia (e questo è un bene!) ma spesso se ne parla senza conoscerlo davvero a fondo e dando credito ad una serie di credenze e falsi miti che non hanno alcun riscontro in quella che è realmente l’essenza di questi approcci (e questo è un male!).

Nella mia esperienza mi è capitato diverse volte di ascoltare questi luoghi comuni che spesso ricorrono e riguardano più o meno sempre gli stessi argomenti.

Ho quindi provato a raccoglierli ed a ragionarci su per sintetizzare i motivi per cui, dal mio punto di vista, sono assolutamente privi di qualsiasi fondamento.

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!

I 9 (+1) Falsi Miti sull'Agile da sfatare subito!

I 9 (+1) Falsi Miti sull’Agile da sfatare subito!

I 9 (+1) Falsi Miti sull’Agile da sfatare subito!

MITO #1: l’agile è una novità

FALSOL’Agile non è una novità!

L’Agile non è una novità! Condividi il Tweet

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. Va bene la documentazione se funzionale alla produzione di valore

Gli approcci agili non sono prescrittivi. OK alla documentazione se funzionale alla produzione di valore Condividi il Tweet

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

Il secondo valore dell’Agile Manifesto recita:

Working software over comprehensive documentation”.

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

E la conferma anche nel settimo dei principi:

Working software is the primary measure of progress”.

Parlando poi del concetto di valore ricordiamo il primo dei principi:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”.

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 il decimo principio recita:

Simplicity–the art of maximizing the amount of work not done–is essential”.

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.

Il design è onnipresente negli approcci agili e non relegato alle sole fasi iniziali del progetto Condividi il Tweet

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 Condividi il Tweet

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 iper-dettagliato 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 iper-pianificazione 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 deve 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:

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

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

  • 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 road-map 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.

Un progetto agile segue un approccio rigoroso e si basa sulla responsabilità dei singoli nel perseguire un obiettivo condiviso Condividi il Tweet

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. L’agile funziona meglio proprio in progetti con scadenza e budget fissi.

Gli approcci agili funzionano meglio in progetti con scadenza e budget fissi Condividi il Tweet

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.

Agile Triangle: lo Scope viene massimizzato in funzione dei vincoli di Tempi e Costi

Agile Triangle: nei progetti agili lo Scope viene massimizzato tenendo conto dei vincoli di Tempi e Costi

Iron Triangle: nell'approccio Waterfall, lo Scope viene fissato all'inizio del progetto. A fronte dei Change, Tempi e Costi subiscono delle variazioni

Iron Triangle: nell’approccio Waterfall, lo Scope viene fissato all’inizio del progetto. A fronte dei Change, Tempi e Costi subiscono delle variazioni

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

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

L’Agile può essere scalato ed essere utilizzato con successo anche in grandi progetti Condividi il Tweet

Un progetto grande è una sfida sempre, 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

Gli approcci agili possono essere adottati con successo in molti i contesti produttivi Condividi il Tweet

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 Silver Bullet Condividi il Tweet

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

Il momento giusto per la transizione ad approcci agili è sempre quello in cui se ne avverte l’esigenza! Condividi il Tweet

Questa frase (e tutte le variazioni sul tema) ricordano quelle che ci raccontiamo 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 !

Ma la verità è che il momento giusto è ora, subito, quando si avverte l’esigenza di cambiare:

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

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 !

4 Comments on “I 9 (+ 1) falsi miti sull’agile da sfatare subito!”

    1. Grazie Carola,

      mi fa piacere che tu l’abbia apprezzato. Il problema è che per poter sfruttare davvero i benefici che gli approcci agili possono offrire occorre prima chiarire cosa realmente sono, sgombrando il campo dai tanti pregiudizi che li circondano e che sortiscono il duplice e contrapposto effetto o di dissuadere dall’utilizzarli o di utilizzarli con delle aspettative di partenza che non trovano alcun riscontro nella reale essenza di questi approcci.

      Continua a seguirmi e … Stay Agile!

    1. Grazie Simone ! Spero proprio che possa essere un mio piccolo contributo alla diffusione della cultura Agile. Continua a segurmi: sto preparando altri contenuti “agili”!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *