Cos’è l’Agile spiegato a Nonna Elvira

Vi presento Nonna Elvira

Ero al mercato la scorsa settimana come quasi sempre faccio durante il weekend. Mentre ero totalmente assorbita dalla scelta di un buon melone da portare a casa si avvicina sbuffando impaziente Elvira, una simpatica vecchietta che incontro spesso e con la quale mi piace chiacchierare di tante cose: Elvira è curiosa ed ha una mente attenta e brillante ma mai avrei pensato di trovarmi a spiegare proprio a lei cos’è l’agile.

“Che noia, tutti i Sabati la stessa storia! Questo è il banco che ha la frutta e verdura migliore ma ogni volta ci sono ore ed ore di fila da fare. Sono proprio disorganizzati!”, irrompe Elvira.

“Oh Elvira buongiorno, come stai ? Eh si, hai proprio ragione, in effetti non hanno una organizzazione molto Agile!” le rispondo io.

“Agile ? Ma che dici ? Organizzata vorrai dire!” risponde Elvira.

Ed io ridendo: “Si Elvira scusa, hai ragione. Sai nel mio lavoro il termine Agile non ha esattamente lo stesso significato che gli diamo di solito …”. Ma nemmeno tanto diverso dopotutto, rifletto nel frattempo.

“In che senso ?” chiede Elvira. “Ma che è ‘sto Agile, qualcosa che ha a che fare con quella roba che fate voi al computer ?”

Scoppio a ridere e le rispondo: “Si Elvira, in un certo senso è così. E’ un qualcosa che è nato per aiutare nella produzione di Software ma poi si è dimostrato talmente efficace che oggi viene applicato anche in altri contesti, pensa!”

Elvira: “Ma dai! Mi incuriosisce, spiegami un po’ meglio. Tanto con questa fila qui ci facciamo notte: abbiamo tutto il tempo che vogliamo. Di cosa si tratta ? Ma, per favore, non cominciare con tutti quei termini strani che utilizza anche mio nipote, eh! Non è proprio la giornata giusta oggi!”.

“Beh Elvira, ti sembrerà strano ma non si tratta di nulla di tecnico ma piuttosto di una filosofia, di un approccio mentale con cui gestire le nostre iniziative, i nostri progetti. Guarda puoi vedere l’Agile come una specie di ombrello che racchiude sotto di se tanti approcci diversi tra loro che però condividono tra gli stessi valori e principi.” le rispondo.

Minestrone “Just-in-Time”

“Guarda, ti faccio un esempio. Vedi quel ragazzo dietro il banco ? Con tutta la gente che aspetta di essere servita sta li a preparare le bustine di minestrone già tagliato e pulito e continua ad accumularle sul banco. Se adottasse un approccio Just-in-Time, noi probabilmente non faremmo tutta questa fila ogni volta. Just-in-Time infatti significa proprio “appena in tempo” o “al momento giusto”. E’ inutile accumulare li quella roba se non sai nemmeno quanta gente la vorrà acquistare! Sarebbe molto meglio se aspettasse che le bustine di minestrone siano quasi finite per prepararle di nuovo e nel frattempo servisse i clienti. Questa cosa si chiama gestione Pull, che vuol dire tirare, cioè fare un’azione in funzione di un segnale da parte dei clienti, in base al loro fabbisogno reale. Al contrario, lui adotta un approccio Push anticipando, di troppo, la preparazione rispetto agli ordini.

C’è un approccio molto famoso che si chiama Kanban. E’ nato in Giappone ed il suo nome significa “segnale visuale” e si utilizza per rendere visibile, concreto il flusso di lavorazione in un processo. Si utilizza una cosiddetta Kanban Board dove in ogni colonna viene visualizzato una fase del processo. Te la faccio semplice quando, in base a delle regole che tutti conoscono, una colonna è quasi vuota, quello è il segnale che va riempita di nuovo. Immagina che il banco sia la nostra Kanban Board e le bustine di minestrone siano i nostri “cartellini” (chiamati kanban, con la “k” minuscola!): quando sono quasi finite allora è il momento di aggiungerne di nuove.

Il numero massimo di bustine pronte presenti sul banco è detto WIP (Work In Progress) ed oltre quello non è possibile andare: quando va sotto il numero stabilito allora è il momento di ricominciare a prepararle.

In questo modo si rende più efficiente il processo, si evitano sprechi e non è necessario avere una persona dedicata completamente alla preparazione delle bustine. Il nostro ragazzo potrebbe nel frattempo aiutare a servire i clienti. Che ne dici ?”

Un po’ di storia agile …

“Si, in effetti mi sa che hai ragione. Interessante ‘sta cosa raccontami un po’ come è nata ?” chiede Elvira.

“Beh, allora, agli inizi degli anni 2000, nel 2001 per l’esattezza, un gruppo di 17 esperti nel settore della produzione del Software si è riunito per analizzare insieme i problemi che più frequentemente incontravano nel loro lavoro e trovare un insieme di linee guida e principi che aiutassero a risolverli e superarli. Da quell’incontro è nato così un documento “Il Manifesto per lo Sviluppo Agile del Software” che segna ufficialmente la nascita del movimento Agile. Leggilo se ti capita è molto piacevole ed interessante.

Posso dirti solo una cosa: potremmo stare qui a parlare per ore, giorni ed anche mesi di Agile ma, in fondo in fondo, tutto ciò che serve davvero, l’essenza profonda di ciò che l’Agile rappresenta è scritto tutto li, in quel documentino di poche pagine …”. E proseguo: “Da quel momento in poi sono nate e si sono sviluppate tante metodologie diverse che si ispirano ai concetti agili”.

Un modo nuovo di fare le stesse cose

“Ma se è così, scusa, perché non lo utilizzano tutti allora ?” chiede Elvira.

“Sai le cose non sono proprio così semplici. Essere davvero agili non riguarda tanto l’imparare tecniche o strumenti nuovi ma, soprattutto, adottare un nuovo approccio mentale. E’ un cambiamento culturale radicale, un diverso modo di approcciare alle cose. E questo non è mai facile, ci vuole del tempo” le rispondo.

“Ma perché ? In cosa è così diverso l’Agile ?” chiede Elvira.

“Non mi stai mica facendo una domanda tanto facile, sai ? Provo a farti qualche esempio …” le rispondo.

Il team agile è cross-funzionale

E proseguo: “Intanto partiamo da come è diversa l’organizzazione di un team agile. Parliamo di gruppi relativamente piccoli di persone, molto capaci e motivate, ed altamente focalizzate sull’obiettivo del Progetto che in fin dei conti è uno solo: produrre valore per il Cliente.

Il Cliente è, dopotutto, colui che ci paga per quello che facciamo: direi che è un motivo sufficiente per farlo contento, no ?”.

E proseguo: “I Team sono innanzi tutto cross-funzionali. Ovvero sanno fare un po’ di tutto ed hanno sviluppato le cosiddette Competenze a T”.

Ed Elvira ironica: “Poverini: è una malattia grave ?”.

“No, daiiii!!! Pensa a come è fatta la lettera T: il ramo verticale indica la profondità delle competenze che si posseggono cioè quanto si è esperti o specialisti in una determinata area. Il ramo orizzontale della T invece indica le competenze trasversali e la capacità di comunicare e collaborare con esperti in altri settori. E’ chiaro ora ? In pratica: si può anche essere degli specialisti in una certa area ma, se serve, si deve essere in grado di dare una mano anche agli altri colleghi. L’importante è che tutto il team, nel suo complesso, possegga tutte le competenze necessarie a portare avanti il lavoro.” Ribatto io.

Il team agile è auto-organizzato

E proseguendo: “Altra cosa importante. Nei progetti tradizionali c’è un professionista, il Project Manager, che è di fatto l’unico responsabile della Gestione del Progetto e dei suoi risultati. Certo condivide le sue scelte con il suo team ma, in ultima analisi, risponde lui del rispetto dei tempi, del budget assegnato e della soddisfazione del Cliente. Il timone è tutto suo, nel bene e nel male. Nei Progetti Agili invece il Project Manager non c’è più ed i Team sono auto-organizzati: OK ?”.

Ed Elvira scettica: “Ecco lo sapevo. Le solite cose all’italiana: tutti comandano e quindi nessuno decide. Ognuno fa quello che vuole. L’anarchia assoluta, insomma!”.

Project Management senza Project Manager

“E invece no Elvira, questo è uno dei tanti falsi miti da sfatare sull’Agile. Senti, pensaci bene: quanti Stati, compreso il nostro, sono passati nella loro Storia da regimi autoritari o monarchici a regimi democratici ? Ma il fatto che non ci fosse più un Re non ha mica significato che ad un certo punto non ci fossero più leggi da far rispettare: giusto ?

Io ti ho detto che nei progetti agili non esiste la figura del Project Manager ma non che non si fa più Project Management. Infatti le attività e responsabilità di gestione del progetto vengono, per così dire, redistribuite tra tutti i membri del team. Ora ti è più chiaro ?” Le rispondo.

Un approccio iterativo e incrementale

Ed Elvira: “Si, più o meno. Ma allora, fammi un esempio concreto di come potrebbe svolgersi la cosa …”.

“OK. Allora … Supponiamo che io sia una pittrice e che tu sia una cliente che mi commissiona il suo ritratto. Ovviamente ci vediamo e tu mi racconti per benino cosa vorresti esattamente, come ti piacerebbe che fosse realizzato il tuo quadro: più informazioni sarai in grado di darmi e meglio io riuscirò a soddisfare le tue richieste. Alla fine della chiacchierata, ci penso un po’ su, ti comunico il prezzo e ti dico che tra circa 3 mesi avrai bello pronto il tuo ritratto. Ti va bene ?” Le chiedo.

La risposta di Elvira si fa un po’ attendere:”Beh, si, potrebbe andare ma, certo però 3 mesi sono lunghi! Tutto questo tempo per vedere il mio quadro … Non lo so, e se magari c’è qualche cosa che non ti ho spiegato bene, che non è chiara … Ce ne accorgeremmo solo alla fine, a quadro ormai completato!”.

“Perché hai dei dubbi ? Pensi che potrebbe esserci qualcosa di non sufficientemente chiaro ? Come potremmo fare allora ?” le chiedo.

Elvira risponde: “Beh, magari se potessi vedere ogni tanto il quadro mentre viene realizzato, potrei darti dei suggerimenti, chiarirti meglio cosa vorrei, sai, con il quadro davanti sarebbe più facile spiegarti …”.

“Brava Elvira, è esattamente questo uno dei capi saldi dell’Agile!

L’approccio tradizionale da per scontato che tutto debba essere chiaro fin dall’inizio mentre invece, nella realtà delle cose, questo non succede quasi mai: il Cliente stesso non ha le idee proprio chiare al 100% o non è ancora in grado di trasmetterle. Oppure chi deve realizzare il prodotto non sia ancora in grado di cogliere davvero tutti gli aspetti necessari. E questo accade soprattutto quando la natura di ciò che deve essere realizzato è intangibile, complessa e difficile da descrivere a parole.

Per questo spesso si parla di Approccio Predittivo contrapposto a quello tipico dell’agile che invece viene definito Adattivo ed Incrementale.

Negli approcci Agili si stabiliscono degli intervalli temporali fissi e piuttosto brevi, massimo un mese, chiamati Time-Box in cui viene effettuato un ciclo di sviluppo completo del Prodotto, dall’analisi alla realizzazione. I cicli di sviluppo prendono il nome di Iteration. All’inizio di ogni Iteration il cliente ed il team di sviluppo si incontrano per analizzare e chiarire nel dettaglio cosa va realizzato in quel ciclo e, sai qual è la cosa più bella ? E’ che alla fine dell’Iteration viene realizzato un incremento di prodotto funzionante ed auto-consistente con un reale valore dal punto di vista del cliente. Diciamo che alla fine di ogni Iteration tu potresti vedere e toccare una versione pronta del tuo ritratto ed insieme potremmo decidere come andare avanti. Ma questa volta ragioneremmo su qualcosa di veramente concreto e tangibile. Anzi, ti dirò di più, tu potresti anche renderti conto che quello che ho fatto fin a quel momento è proprio quello che ti serviva e che volevi e decidere anche di fermarti li. Ti piace ?”

Ed Elvira: “Certo che mi piace: così è molto meglio!”

Sviluppo guidato dal Valore

“OK allora” proseguo io “Decidiamo cosa fare nella prima Iteration. Ti propongo … Fammi riflettere un attimo … Ah, si, magari di completare tutto il paesaggio di sfondo del quadro ? Oppure parto dall’alto e dipingo la parte superiore ? Arrivo a dipingere fino a metà della tua testa, che ne dici ?”

Ed Elvira, alla quale davvero non sfugge mai nulla, replica un po’ piccata: “Beh però veramente, scusa se te lo dico, magari ho capito male io, ma così non è mica tanto vero che alla fine del ciclo io avrò un prodotto auto-consistente e finito! Cosa faccio ? Appendo alla parete un paesaggio con un buco in mezzo oppure un ritratto con mezza testa ? Non è che mi hai tanto convinta, sai ?”

“Elvira, sei davvero una forza della natura, sai! Ti ho teso un piccolo tranello, perdonami, ma tu non ci sei cascata! Quello che dici è giustissimo ed è un errore che a volte viene commesso quando si decide cosa realizzare in una Iteration. Ricordi cosa ti ho detto all’inizio ? Quello che conta è produrre valore per il Cliente: ribadisco per il Cliente, non per noi! Senza se e senza ma! Gli incrementi di prodotto vanno pensati in modo verticale e non orizzontale. Solo così si produce qualcosa che abbia davvero un senso per il Cliente. Nella prima Iteration potrei, per esempio, realizzare una prima versione in bianco e nero del tuo ritratto, nella seconda aggiungere il paesaggio come sfondo e, nella terza infine, aggiungere anche il colore. Così ti convince ?”

“Adesso si che ci siamo! Ho capito e mi piace!” e, continua soddisfatta Elvira: “Senti, perché non andiamo insieme a parlare con quel ragazzo del banco della frutta e lo aiutiamo ad essere un tantino più agile ? Sto perdendo le speranze di riuscire a tornare a casa in tempo per il pranzo!”.

“O no, si è fatto tardissimo, debbo scappare. Vai tu a parlarci: davvero, saresti un ottimo Scrum Master, sai ?” le dico ridendo.

“Cosaaaa ?” risponde lei.

Ed io, mentre baciandola la saluto: “Non fa niente Elvira, dai, te lo spiego la prossima volta, devo andare davvero. Ciaoooo!” E mi allontano ben sapendo che Elvira la prossima volta non si sarebbe certo dimenticata che le dovevo ancora qualche risposta.

Sperando che questa piccola dissertazione semi-seria non vi abbia troppo annoiati, vi saluto e … Stay Agile!