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-rispondere). 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:

“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-rispondere ) 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;

  • 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):

“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 (sondare-valutare-rispondere), 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 diventa inspect-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 (agire-valutare-rispondere). 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!

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme