di Antonio Marino

Oggi giorno si parla molto di Scrum, e più in generale di Agile. Per questo motivo, spesso mi viene chiesto quanto sia realmente utile adottare questo tipo di approccio, con tutta una serie di domande annesse. Fondamentalmente, tutte racchiudibili con il seguente interrogativo: “che caratteristiche devono avere i membri del team per poter gestire progetti Agile?” Proprio in questo articolo, formulerò un suggerimento, fornendo così, ai cari lettori, delle indicazioni pratiche.

Partiamo quindi col comprendere “Quando” realmente occorre usare Scrum, e soprattutto “Perché”. Per rispondere esaustivamente al nostro quesito, in maniera semplice, faccio spesso riferimento ad un esempio in particolare, che tra l’altro spiego anche in un articolo sull’ormai noto Linkedin (https://lkdin.io/3nKX ) .

Ovvero, prendo spunto da un simpatico quanto famoso aneddoto, tratto da un film che tutti conosciamo del trio comico Aldo, Giovanni e Giacomo:

Ogni mattina in Africa, una gazzella si sveglia, sa che deve correre più in fretta del leone o verrà uccisa. Ogni mattina in Africa, un leone si sveglia, sa che deve correre più della gazzella, o morirà di fame. Quando il sole sorge, non importa se sei un leone o una gazzella: è meglio che cominci a correre.

Nel tempo, sono stati prodotti diversi modelli per orientarsi su “quando” adottare Scrum; alcuni di questi sono semplici, mentre altri molto più sofisticati; vi propongo il modello basato sulla matrice di Stacey (non troppo complesso).

Asse verticale per Agreement/Disagreement: si intende il grado di accordo sui requisiti di progetto, o in altri termini “quanto gli stakeholder conoscono ciò che vogliono”; possiamo quindi sintetizzare questa dimensione con WHAT TO BE DONE. I punti dell’asse più verso l’origine (Agreement), indicano le situazioni in cui gli stakeholder sono in grado di descrivere i loro bisogni, e nella loro mente c’è già un’idea piuttosto chiara di COSA vorrebbero ricevere dal progetto (es. il leone vede chiaramente COSA potrebbe soddisfare il suo bisogno di fame, cioè la gazzella), Ma, per contro, i punti più lontani dall’origine (Disagreement), diversamente da prima, indicano le situazioni in cui gli stakeholder, seppur in grado di descrivere i loro bisogni, NON hanno idea del COSA vorrebbero che il progetto stesso rilasciasse (es. la gazzella sa bene che deve salvarsi la vita, ma non conosce quale sia la destinazione finale che deve raggiungere).

Asse orizzontale per Certainty/Uncertainty: ci si riferisce alla connessione causa-effetto, o in altri termini,  “come il team può soddisfare le necessità espresse”; possiamo sintetizzare questa dimensione con il HOW WE WILL DEVELOP IT. I punti dell’asse più verso l’origine (Certainty), indicano quelle situazioni tipiche dove  sia la soluzione e sia la tecnologia per soddisfare le necessità degli stakeholder, sono note, per di più anche già usate varie volte in passato (es. il leone attua in modo ripetitivo il suo meccanismo per procacciarsi le prede; quando caccia, è usuale che si apposti, osservi e si sposti per analizzare le informazioni a sua disposizione; dopo una lunga pianificazione, scatena la corsa verso la gazzella che aveva adocchiato e studiato).

Proseguendo, per contro, i punti più lontani dall’origine (Uncertainty), indicano le situazioni in cui si deve obbligatoriamente far ricorso ad una forte sperimentazione (nulla di già noto), in modo da comprendere rapidamente COME realizzare il lavoro (es. la gazzella inizia subito ad andare verso le montagne, ma in tempi rapidissimi deve altrettanto verificare se la direzione è quella giusta, sempre in funzione sia della posizione del leone che del contesto orografico, man mano che corre).

A questo punto, avendo compreso i 2 assi di riferimento, possiamo ora intercettare delle aree in cui il nostro progetto potrebbe ricadere.

  • Area A: in questa area ricadono tutte quelle attività che oggi vengono genericamente chiamate Business As Usual (BAU); cioè, non si tratta di progetti, ma di attività ricorsive svolte molte volte. Non siamo di fronte ad un progetto, ma davanti ad attività ongoing, cioè continuative, che sorreggono un business lanciato da un progetto ormai concluso.
  • Area B: Stacey, chiama quest’area “la zona della complicazione”, poiché qui rientrano tutti quei progetti di tipo predictive (o traditional se si preferisce) in cui si creano specifici piani per ottenere i risultati attesi; risultati che vengono costantemente monitorati e confrontati con i suddetti piani, in maniera da comprendere chiaramente e tempestivamente se occorre correggere qualcosa, qualora ci si stia discostando dagli stessi. In quest’area si evidenziano prettamente due situazioni limite:
    • Media Certainty e Disagreement – qui è utile che il project management si focalizzi molto sull’area Risk management;
    • Certainty e medio Agreement – qui è utile che il project management si focalizzi molto sull’area Stakeholder management.
  • Area C: Stacey chiama questa grande area centrale “la zona della complessità”, dove gli approcci gestionali tradizionali non sono molto efficaci; qui deve prevalere la creatività e l’innovazione, si deve rompere con il passato per creare nuove modalità operative. Questa è l’area della sperimentazione, in cui i metodi Agile possono rappresentare una soluzione gestionale utile per guidare il progetto.
  • Area D: quest’area è la zona del caos. Queste situazioni, con alti livelli di incertezza e disaccordo, spesso sfociano in anarchia; in questi contesti i metodi tradizionali di project management sono insufficienti e l’Agile purtroppo non sembra essere efficace. Se ci si trova in quest’area, si può comunque adottare una strategia spesso condivisa da molti esperti, ovvero, si deve semplicemente evitare di affrontare immediatamente questi contesti, occorre “prendere tempo” per ricercare maggiori informazioni in merito. Sebbene questa strategia possa essere protettiva nel breve periodo, risulta purtroppo disastrosa se impegnata a lungo; in altre parole, ci si deve concedere del tempo per chiarire il progetto, ma non troppo, perlomeno non tanto da indurre gli stakeholder a dar per scontato che il progetto, nonostante tutto, si stia realizzando.

In un altro articolo riprenderemo questo discorso e analizzeremo meglio le caratteristiche che devono avere gli agile team member!

Antonio Marino

Antonio Marino è un ingegnere che avvia la sua carriera nel project management nel 1996 lavorando all’Agenzia romana per la preparazione del Grande Giubileo del 2000 SpA nella pianificazione e controllo degli interventi di preparazione della città di Roma e il Lazio all’evento.

Attualmente è business developer e competence leader sul project management in ELIS (elis.org) ma dal 2000 ha formato migliaia di persone sul project management con particolare focus alle certificazioni del PMI®, tema sul quale ha scritto diversi libri.

Membro del PMI® e revisore della Guida al PMBOK® (ed. 5, 6 e 7), dal 2005 è certificato PMP®, nel 2011 è stato il primo italiano ad acquisire la certificazione PMI-ACP® sui metodi Agile, è Project manager e ICT PM ai sensi, rispettivamente, delle norme UNI11648 e UNI11506, oltre ad essere un facilitatore certificato FranklinCovey.

Riferimenti social: