Agile Life

marzo 2014 - Post

Essere sempre Agile conviene sempre, utilizzare una Metodologia Agile… dipende!

Il Post precedente, in cui abbiamo evidenziato le profonde differenze tra un approccio Agile e il modello a Spirale, ci consente di rispondere ad una domanda a cui spesso, chi ha l’onere (e l’onore ;-)) di dover gestire un progetto si trova a dover rispondere?

            “Conviene, per questo progetto, adottare un approccio Agile?”

Ebbene, chiariamo subito una cosa: la domanda è fondamentalmente sbagliata! Infatti la relativa risposta sarebbe sempre e soltanto “SI” perché l’approccio Agile migliora la collaborazione all’interno del Team e quella con l’esterno, puntando a creare il massimo Valore possibile per gli stakeholder. Ma tale aspetto (quindi i Valori e le Pratiche) possono essere sempre usati, anche senza una Metodologia Agile specifica.

La domanda corretta diventa quindi:

“Conviene, per questo progetto, adottare una Metodologia Agile o una Metodologia più Tradizionale, sia per la gestione che per lo sviluppo?”

waterfall-network

Waterfall vs Agile

e qui le cose si fanno decisamente interessanti, perché la risposta potrebbe riassumersi in un banale, ma assolutamente complicato: “dipende”. Ma “dipende” da cosa: dalla complessità del progetto, dalla preparazione del Team, dai tempi, dai costi, dall’incertezza tecnologica, dal contesto?

Tutti fattori validi (non esaustivi) che vanno opportunamente valutati e calibrati tra loro per effettuare la scelta giusta. In particolare, esistono una serie di framework che ci consentono di indirizzarci sulla strada giusta e, tra questi, vediamo uno dei più noti, ovvero Cynefin, che consente di individuare all’interno di quali casistiche di complessità ricade il sistema in analisi.

Partiamo dalle basi, ovvero dal modello che descrive il framework stesso (fig. successiva), definito sense-making dagli autori (Kurtz e Snowden, K&S):

cynefin framework

Cynefin framework

Il framework posiziona i sistemi in 4 quadranti idealmente ben distinti (anche se nella pratica i contorni sono decisamente più sfumati) e suggerisce i relativi pattern comportamentali:

  • Simple, i sistemi che ricadono in questo quadrante sono sostanzialmente contraddistinti da una chiara relazione causa-effetto, in cui l’aleatorietà è praticamente azzerata, e la soluzione è assolutamente evidente e non in discussione:

se butto un sasso da una finestra questo cadrà a terra”.

In questo quadrante è possibile decidere anticipatamente cosa fare, applicando, come suggerito, il pattern comportamentale sense-categorize-respond (valutare-classificare-agire). Lo sviluppo del progetto è affidato ad una catena di controllo (command-and-control) e a una serie di knowledge workers (KW) che applicano le proprie competenze in relazione a quanto deciso. Chiaramente la rete tra i KW è decisamente poco influente perché ad ognuno è demandato un compito ben specifico;

  • Complicated, i sistemi che ricadono in questo quadrante rispondono ancora ad una relazione del tipo causa-effetto, ma essa non è così evidente e non è univoca:
  • Complex, i sistemi in questo quadrante non possono più essere modellati secondo un approccio lineare (matematicamente secondo equazioni lineari) perché il funzionamento olistico è più della somma del funzionamento delle singole parti, dipendendo anche dalla sua evoluzione/storia. Un ottimo esempio di sistemi complessi sono i sistemi con rientranti (o feedback):

“se premo il pulsante di accensione del televisore, questo potrebbe accendersi a seconda del fatto che lo stesso sia o meno collegato alla rete elettrica”

In questo scenario, K&S suggeriscono di adottare il pattern sense-analyze-respond (valutare-analizzare-agire) che, parte sempre da una valutazione, ma poi si concentra sull’analisi del contesto che viene effettuata tramite l’approccio analitico di scomposizione del sistema in sotto-sistemi più semplici, basandosi sul fatto che il funzionamento d’insieme dei singoli componenti è equivalente a quello del sistema nel suo complesso (somma delle parti). I worker di tale sistema sono gli “Experts”, in grado di contestualizzare le proprie attività e relazionarsi con i propri colleghi per creare un Network che rende meno rigido (anche se non lo elimina) l’approccio command-and-control

 Un esempio concreto della sua applicazione: la catena di montaggio;

“lo stesso motore ha un rendimento diverso in base a come è stato utilizzato”

In questo caso l’approccio da seguire è quello di “metterci le mani dentro”, ovvero probe-sense-respond (sondo-valuto-agisco), anche sapendo che potrei perturbare il sistema stessa (principio di indeterminazione di Heisenberg).

In questo caso il Network tra i worker diventa fondamentale e il pattern comportamentale diventainspect-and-adapt, diminuendo anche l’importanza degli Expert a favore di worker più orizzontali in grado di spingersi oltre e rispondere nel modo migliore relativo al contesto;

  • Chaotic, i sistemi di questo quadrante non rispondo più a nessuna legge deterministica o, se lo fanno, ciò avviene per una frazione limitata di tempo che non ha valenza sul piano complessivo. Siamo in presenza di una elevata incertezza in cui ogni tipo di valutazione (sense) o di indagine (probe) non è di alcun aiuto. Ogni approccio di gestione di questi sistemi è destinati, nella stragrande maggioranza dei casi, ad essere fallimentari, e se proprio bisogna intervenire, l’unico pattern perseguibile è act-sense-response, in pratica si opera sul sistema a “naso”, si valuta il risultato e si agisce di conseguenza (agisco-valuto-rispondo). Ogni piccola perturbazione porta ad un effetto potenzialmente devastante e, la stessa azione ripetuta più volte, porta ad effetti diversi. Si è in presenza del cosiddetto effetto farfalla:

“il battito delle ali di una farfalla in Brasile può scatenare un tornado in Texas”

Sia il Network che la Gerarchia hanno ben poco significato.

Caratterizzati i quattro quadranti, vediamo come Cynefin ci indirizza verso una possibile metodologia di sviluppo:

  • Se siamo in presenza di sistemi Semplici o Complicati, possiamo ricorrere a metodologie tradizionali, perché il dominio di riferimento è noto e la variabilità è estremamente bassa. Ad esempio, per i sistemi Complicati, si può pensare di utilizzare il modello a Spirale, ma non è da escludere lo stesso Waterfall;
  • Se siamo in presenza di sistemi Complessi, le metodologie Agili sono la soluzione ideale;
  • Se siamo in presenza del Caos la scelta migliore è, probabilmente, quella di abortire il progetto!

Esistono chiaramente situazioni border-line dove l’esperienza e la maturità aziendale rappresenta l’elemento di scelta definitivo: ad esempio se il sistema è al confine tra Complicato e Complesso e la mia azienda utilizza già abbondantemente metodologie Agile, la scelta ricadrà quasi sicuramente su quest’ultime. Il caso duale vale un po’ meno perché l’entropia del sistema è più facile che aumenti piuttosto che diminuisca.

Prima di concludere, per completezza, bisogna evidenziare che Cynefin contempla anche un quinto quadrato, definito Disorder, in cui ci si trova quando non si riesce a inquadrare correttamente il sistema. Cosa fare in questi casi? Affidarsi alla propria esperienza!

 

[FELICEPESCATORE.IT]

Posted: 27 mar 2014 15:18 da felice.pescatore | con no comments
Inserito sotto: ,
Agile? Un attimo… ma non somiglia al modello a Spirale?

Durante le varie conferenze ed i vari incontri, capita (molto raramente a dire il vero) che qualcuno si ponga e ponga la seguente domanda:

“Scusate: ma il modello a Spirale non è un modello che assomiglia molto a quanto fatto con Scrum o, in generale, con le metodologie Agili incentrate sulla gestione del progetto?”

Questa domanda è da spunto per un confronto tra tali modelli di sviluppo che, nonostante presentino delle affinità, si differenziano profondamente, anche se, spesso, la confusione regna sovrana, soprattutto a causa della scarsa diffusione (e apprezzamento) del modello a Spirale stesso.

modello spirale

Modello a Spirale

Nella nostra analisi, partiamo proprio dal modello a Spirale, nato, principalmente, per mitigare i rischi annessi al classico modello waterfall, soprattutto in relazione alla rigidità dell’analisi dei requisiti UpFront. Come si vede dalla figura precedente, lo sviluppo è Iterativo, incentrato su quattro fasi caratterizzanti che si ripetono ad ogni loop: Determinazione degli obiettivi della faseIdentificazione e riduzione dei rischi con valutazione delle alternativeSviluppo e verifica della fase, Pianificazione della fase successiva. La forma caratteristica del modello è dovuto alla volontà di evidenziare l’aumento del costo del progetto all’allontanarsi dal centro.

Il modello a Spirale è spesso definito anche meta-modello perché sfrutta sia il modello a cascata che quello prototipale. Qui troviamo una differenza fondamentale rispetto all’Agile: lo sviluppo non è incrementale, ma vengono sfruttati uno o più cicli basati su prototipi per dirimere il rischio e poi passare, solo successivamente, allo sviluppo vero e proprio che avviene in chiave waterfall. In pratica è come se avessimo una fase di Inception (rif. RUP e DAD) molto lunga che però, una volta completata, viene completamente congelata tramite “pesanti” documenti di progetto.

Si intuisce che la complessità del modello (e il costo) lo rende applicabile a progetti di ampia durata, almeno 18-24 mesi, e con una forte componente di rischio. Inoltre, molto effort viene speso nella gestione dei processi annessi e nella realizzazione di documentazione di dettaglio (vi dice qualcosa l’SRS?).

Vediamo, dualmente, il confronto con uno sviluppo Agile (generico, senza riferirci ad una metodologia o ad un framework specifico).

agile development

Agile Development

Lo sviluppo in chiave Agile è Iterativo ed Incrementale, basato su iterazioni/sprint brevi (tipicamente 2-4 settimane) ed è incentrato sui Valori e sui Principi del Manifesto Agile. L’aspetto fondamentale è che ad ogni iterazione viene prodotto codice funzionante e testato che entra a far parte della soluzione finale, e non prototipi come accade nel modello a Spirale.

In tale ottica la metodologia Agile adottata, per quanto prescrittiva, punta a rafforzare il Valore intrinseco del Team e a produrre sempre e solo artefatti che rappresentano a loro volta un vero Valore per il cliente: non è necessario, ad esempio, produrre una documentazione approfondita, se non richiesta, come invece prescritto dal modello a Spirale.

Al di là delle differenze evidenti, esistono comunque alcuni punti di raccordo tra il modello a Spirale e l’approccio Agile:

  • In entrambi le stime (costi, tempi, ecc..) sono aggiornate ripetutamente, rendendole decisamente più attendibili;
  • La gestione (possibilmente abbattimento) del Rischio è uno dei fattori chiave di entrambi i processi (almeno fino all’inizio dello sviluppo nel modello a Spirale)
  • I Cambiamenti sono accettati con più elasticità (almeno fino all’inizio dello sviluppo nel modello a Spirale)
  • Il monitoraggio delle attività è flessibile e dinamico.

[FELICEPESCATORE.IT]

ALM, Be an owner not a tenant

Nel precedente post abbiamo riportato una interessante definizione di David Alberts afferente le “persone Agili”. Ma, come ripeteremo fino alla noia, Agile e Lean sono una questione di Team e non di singolo Team member: si ottiene vero Valore dalla metodologia scelta solo se essa diventa la linfa del Team stesso!

Come sempre, il riferimento massimo è il Manifesto Agile e, nel contesto in analisi, risultata particolarmente rilevante uno dei suoi principi:

“A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.”

evidenziando senza fraintendimenti la necessità di padroneggiare il modus operanti scelto, cosa ben diversa dall’adozione “fredda” di una metodologia secondo quello che è il disciplinare che l’accompagna. A tal riguardo, Ambler fa un interessante paragone esplicativo:

l’adozione profonda dell’Agile/Lean è paragonabile all’acquisto di un appartamento, così come la sua adozione “fredda” al fitto.

rent vs buy

Se ci pensate, quando prendete in affitto un appartamento, le attività di manutenzione/adattamento che dedicate alla struttura sono minimali: una imbiancata, se necessario, una bella ripulita e qualche mobile per abitarvi dignitosamente. Se, al contrario, acquistate un immobile, le attività annesse interessano, probabilmente, una vera e propria ristrutturazione: ad esempio potreste decidere di sostituire il parquet e gli infissi.

A primo acchito si potrebbe pensare che la prima opzione è da scartare a priori, ma, in realtà, non è detto, dipende dal contesto e dall’obiettivo. Se vogliamo introdurre una metodologia Agile all’interno della nostra struttura IT che, storicamente, segue un altro approccio allo sviluppo, allora ha senso cominciare con un progetto e un Team pilota, minimizzando il rischio di creare confusione e spingere ad una rapida (ed errata) conclusione che Agile non fa per noi! In questo caso la presenza di un trainer è fondamentale, perché guida il Team alla scoperta di un nuovo modo di fare le cose.

D’altro canto, in un contesto più maturo, la seconda scelta è praticamente obbligata. Infatti il Team deve far propria la metodologia scelta, adattandola continuamente al contesto e al suo know-how (inspect-and-adapt), percorrendo, insomma, la strada che lo porta a diventare un High Performance Team. La figura del trainer, in questa ipotesi più profonda, non può chiaramente essere ricoperta da un “istruttore”, ma bisogna affidarsi ad un vero e proprio coach che guida il Team sia nella crescita d’insieme e che in quella di ogni singolo Team member, soprattutto nella scoperta delle proprie attitudini.

Nel caso specifico di DAD (così come anche per SAFe), siamo difronte ad un framework process goal-driven, che, per definizione, è una infrastruttura portante delle nostre attività e che, quindi, rientra nella seconda categoria. La sua adozione comporta, quindi, un lavoro culturale profondo, soprattutto per adottarlo al meglio al contesto di riferimento, scegliendo le pratiche più consone, modificandole e aggiungendone di nuove.

In fondo, prima o poi, tutti vogliamo acquistare un’immobile per sentirci a casa!

 

[FELICEPESCATORE.IT]