Pubblicato il

Report Agilità 2020: cosa ci racconta?

Loading

In Quale scenario viviamo? L’Incertezza

Un nuovo approccio è necessario da quando abbiamo esponenzialmente aumentato la nostra “velocità” di vita personale e professionale. Le tecnologie cambiano rapidamente, più della velocità di adattamento delle aziende che non utilizzano framework di gestione del progetto flessibili al cambiamento stesso, come mostra questo grafico.

Secondo i risultati forniti da IBM, il 90% dei dati disponibili  nel mondo sono stati prodotti negli ultimi due anni e ogni giorno vengono creati 2,5 quintilioni di byte dove un quintilione è pari a un miliardo di triliardi, ovvero 10 elevato alla 30, che corrispondono più o meno al download di mezzo miliardo di film in HD.

Viviamo quindi in un contesto altamente fluido in cui non possiamo avere certezza che la situazione odierna sarà la stessa che troveremo alla fine del nostro progetto.

Dobbiamo quindi essere antifragili, accettare il cambiamento ed utilizzarlo per evolvere.

Recentemente è stato pubblicato il quattordicesimo report sullo stato dell’Agilità, vediamo cosa dice…

Il Campione

I dati sono ottenuti da interviste fatte in aziende worldwide, il 41% delle quali ha meno di 1000 dipendenti. Tra queste il 36% sono aziende software. Gli altri range aziendali per numero di dipendenti sono il 19% tra 1000 e 5000, il 15% tra 5000 e 20000, il 25% sopra i 20000.

La maggior parte delle persone che hanno risposto al questionario sono scrum master, seguiti da PM, manager, team di sviluppo (nei diversi ruoli).

La maggior parte delle aziende dice che meno della metà dei propri team usa Agile.

L’aspetto interessante è che l’81% degli intervistati dicono che i loro team non sono co-locati ma lavorano da remoto. Questo dato è antecedente l’evento corona virus, quindi ci fa capire come la stessa agilità sta cambiando lasciando spazio a chi crede che la presenza non sia sempre necessaria.

Un altro aspetto interessante, che spesso viene richiesto è: come posso misurare il successo della trasformazione di uno o più team verso l’agilità?

Sebbene i KPI varino molto da una realtà aziendale all’altra e possano essere identificati andando ad intervistare direttamente il team, il report ci racconta quanto segue.

Il 58% risponde che il successo viene misurato attraverso la soddisfazione del cliente. Agilità infatti è anche maggior coinvolgimento del team e del cliente che attraverso i review meeting controlla a intervalli di “breve” durata la corrispondenza con le aspettative del cliente. Di seguito abbiamo il business value. Rilasciando spesso chiaramente si arriva prima a rilasciare “valore” e ad avere un ROI (return of investment) che, potenzialmente potrebbe anche autofinanziare il progetto.

Il report delinea anche i tool utilizzati maggiormente dai teams agili, ma vediamo quali sono i principali benefici, secondo gli intervistati, rispetto all’adozione dell’agilità.

Benefici Agili

Cambiamenti nelle priorità di business

Il 70% dei rispondenti al sondaggio attribuisce agli approcci agili la capacità di gestire i change delle priorità di business, del resto sappiamo tutti che le specifiche stile waterfall non sono stabili fino alla fine del progetto. In Agile il product backlog gestito dal p.o. è lo strumento per governare i cambiamenti nelle priorità di business. Il team poi accoglie questi cambiamenti gestendoli negli sprint.

Avere questa libertà è un grande vantaggio che consente al business dell’azienda di far procedere il progetto secondo piani di breve durata e non lunghi mesi o anni.

Visibilità sul progetto

Non serve il project manager, le informazioni sono appese alla parete o virtualmente. Può sembrare una provocazione ma nei progetti agili ci sono alcuni strumenti che consentono sempre al team di verificare lo stato del progetto. Ci sono poi metriche come il burndown chart e il control chart che aiutano il team ad avere importanti informazioni.

Allineamento It-Business

Il 65% pensa che i progetti agili migliorino la relazione tra it e business.

I progetti infatti seguono un approccio value-driven diversamente da quello dei progetti tradizionali che è plan-driven: ogni iterazione produce un incremento di prodotto autoconsistente e potenzialmente rilasciabile

  • minimizzando sprechi ed attività che non producono valore (priorità basse nel PB)
  • accolgono i cambiamenti come potenziali opportunità per produrre maggiore valore basandosi sulle evoluzioni del mercato e/o sui feedback del cliente
  • prevedono una strettissima e costante collaborazione con il business: il Product Owner è parte del team ed uno dei suoi compiti è fare in modo che il team comprenda i requisiti, condivida la vision e gli obiettivi del progetto
  • il backlogdi prodotto è costantemente prioritizzato: viene prodotto prima ciò che crea più valore

A questo punto è evidente che il team lavora su ciò che davvero genera valore e che conta per tutto il team.

E il Team?

Il morale dei membri del team risulta sensibilmente migliorato per il 61%

  • la possibilità di autogestirsi ed auto-organizzarsi da spazio alla creatività, all’innovazioneed alla possibilità di mettere a frutto la propria esperienza
  • un team cross-funzionale amplifica le possibilità di apprendimentoreciproco da parte dei membri
  • un ritmo sostenibile di lavoroprotegge le persone da eccessivo stress e gli consente di bilanciare lavoro e vita privata aumentandone il benessere
  • il modello di Servant-Leadership, contrapposto allo stile Command-and-Control, consente ai membri del team di accrescere la propria autonomia, l’autostima, l’impegno ed il senso di responsabilità
  • il generale clima di fiduciae rispetto accresce la soddisfazione ed il benessere
  • lo stile di comunicazione trasparentee face-to-face (anche virtuale) accresce la coesione e riduce incomprensioni e conflitti
  • la condivisione di vision ed obiettivi con il cliente accresce motivazione e senso di appartenenza
  • la co-locazione non è più un vincolo.

Tutti questi aspetti creano un “ambiente” fisico, virtuale e di relazione che permette alle persone di lavorare bene. Naturalmente è impossibile averlo se tutta l’azienda, col suo management, non è coinvolta nel processo di trasformazione agile. In caso contrario avremo infatti scrum master che spingono in una direzione e project manager che si intromettono per portare il team su binari tradizionali.

Altri interessanti aspetti vengono evidenziati dal report. Possiamo comunque trarre una conclusione generale, l’agilità si conferma un mindset che funziona, se applicato in modo pervasivo nell’azienda. Quest’ultima, nel management deve accettare un nuovo modo di gestione della leadership che sia “diffuso” e condiviso.

Si va quindi verso una servant leadership oppure una no leadership…?

Riferimenti

State of Agile report 2020

Pubblicato il

Progettazione Agile in tempi di cambiamento…(Parte 2/3)

Loading

Dopo aver visto, nella prima parte di questa serie di tre articoli, la necessità di pianificare vedremo in questo secondo episodio perchè la pianificazione fallisce.

Introduzione

Quando si mollano gli ormeggi uno non va a Capraia ma parte per Capraia.
"Andare a"  o "Partire per" sono due concetti che sembrano simili ma profondamente
diversi... (cit Marco Viganò: insegnante di vela, skipper, navigatore, imprenditore)

Partiamo da qui per riassumere i principali motivi, secondo Mike Cohn, per i quali la
pianificazione nei progetti fallisce:

  •  perché ragioniamo per attività
  •  perché i ritardi si accumulano e le attività non sono indipendenti
  •  il multitasking è dannoso
  •  ignoriamo l’incertezza
  •  le stime diventano “impegni

Ragionare per Attività

Nell’approccio tradizionale alla gestione dei progetti l’organizzazione e la suddivisione del
lavoro è fatto per attività anziché per feature, facciamo un esempio. In ambito IT una
attività può essere lo sviluppo di tutto il supporto per memorizzare i dati del back end, ad esempio
implementazione del database in cui memorizzare i dati. Al termine di questa attività non
potremo comunque dimostrare nulla all’utente perché la parte applicativa: le interfacce, le
pagine del sito, non sono ancora pronte. Quando verranno completate andremo dal nostro
committente per fare una prima demo e quasi sicuramente verremo “rimbalzati” con
alcune segnalazioni. Accogliere questi feedback può voler dire non solo modificare le
pagine del sito, ma anche scendere a livello di db e modificarne la struttura con tempi e
costi notevoli.
Se invece avessimo sviluppato la feature per memorizzare i dati di login e password,
avremmo contenuto i tempi per arrivare al primo rilascio senza sviluppare strutture non
necessarie e passibili di modifiche.

I ritardi si accumulano

Legge di Parkinson:
Il lavoro si espande fino a occupare tutto il tempo disponibile; più è il tempo e più il lavoro
sembra importante e impegnativo
Questo è vero in media, poi certamente ci sono eccezioni.
Prendersi tutto lo slot di tempo disponibile per quell’attività vuol dire che se sono in ritardo
non ho un buffer per espandermi ma finirò a passare il ritardo all’attività successiva. Inoltre
ragionando come detto per attività, vediamo spesso che queste non sono indipendenti fra
loro. Lavorare per feature limita questa dipendenza e isola i ritardi.

Il multitasking

Un falso mito. Per anni abbiamo pensato che svolgere attività in parallelo fosse
vantaggioso. In realtà è stato dimostrato come occuparsi di due task in parallelo aumenta i
tempi. Bisogna infatti considerare il tempo di switch per passare da un contesto di un task
all’altro. In alcuni ambiti e situazioni non sono immediati. Se devo riprendere un lavoro
complesso che ho abbandonato qualche giorno fa, può essere necessaria qualche ora
prima di ridiventare operativo.

Inoltre lo stesso "penny game" dimostra con un semplice gioco questa teoria. Lo potete vedere in un video su YouTube qui oppure descritto in tutti i suoi dettagli su Mokabyte.
In sostanza il multitasking costa energie mentali e psicofisiche, non produce benessere
per la persona, anzi, aumenta lo stress.

Ignorare l’incertezza

Pensiamo che una volta scritte le specifiche funzionali, fatta la stima , ottenuto e approvato
il budget, il progetto partirà e sarà stabile fino alla fine. Ma inevitabilmente le idee
cambiano, il committente ci darà nuove specifiche, incontreremo problemi tecnici e
gestionali (una persona si licenzia e va sostituita). In sostanza la differenza, come scritto
nella citazione iniziale di Marco Viganò tra partire per e andare a.
L’incertezza va prevista, accolta e ne va fatto un elemento che ci rinforza.

Le stime

Se io stimo un lavoro 5 giorni lavorativi ecco come verrà percepito.
Da me: ho detto 5 giorni quindi diciamo che in base al resto delle attività che ho da fare,
tra due settimane potrò rilasciarlo.
Dal cliente (lo stesso che mi aveva già assegnato altri task che non considera possano
occuparmi tempo…): mi ha detto 5 giorni, siamo a lunedì, quindi per venerdì ho tutto.
Una stima porta in sé un concetto di “probabilità” e quindi di incertezza. Non può essere
considerata come un commitment.

Quindi come possiamo pianificare e raggiungere delle stime in modalità Agile? Lo vedremo nell'ultima parte di questa serie di articoli.

Pubblicato il

Progettazione Agile in tempi di cambiamento…(Parte 1/3)

Loading

Introduzione

Alcune domande che ho avuto in testa nei miei primi approcci all’Agilità, intesa come modalità di condurre i progetti e lavorando nel settore dell’information technology in stile waterfall, erano: come faccio a gestire un progetto in modalità Agile dovendo gestire anche la pianificazione di budget e di scadenze? In altre parole se l’agilità accetta ed anzi promuove i cambiamenti in quanto fonte di miglioramento, come faccio a gestirmi il piano? Cambiano i tempi di consegna se accetto, anzi promuovo le modifiche in corso d’opera? Per non parlare dei costi.

Potrei anche accettare di non basarmi su un Gantt ma se ho stimato 100 giorni uomo e un costo di qualche centinaio di migliaia di euro, come faccio ad andare dal committente a dirgli che qualcosa è cambiato nella data di rilascio e nei costi?

In questa serie di tre articoli vi proporrò un percorso che ha come tema la pianificazione in ambito progettuale. Nel primo articolo analizzeremo la necessità di pianificare, nel secondo perché la pianificazione fallisce ed infine nel terzo ed ultimo vedremo l’approccio Agile alla pianificazione. Riassumendo come gestire l’incertezza iniziale di alcuni (o forse molti) progetti cambiando approccio.

Perché si pianifica 

Quanto mi costa? Quando me lo consegnerai ? Quando potrò vedere qualcosa? 

Spesso queste domande arrivano in coda al primo incontro col cliente in cui si sta delineando l’opportunità di realizzare un progetto/prodotto/servizio.

Le risposte a queste domande servono per pianificare campagne di marketing, gestire i costi aziendali, organizzare l’eventuale training degli utenti e così via.

Non è sempre possibile dare risposte perché non abbiamo chiaro il contesto o tutti i dettagli necessari. Non è solo importante la vision del progetto ma anche la vision degli stakeholder. In altre parole cosa vogliamo realizzare per loro? Se vogliamo avvicinarci alle loro aspettative dobbiamo quasi sicuramente avanzare a step. Se invece il nostro obiettivo è realizzare un progetto “chiavi in mano” e puntare a consolidare tutti gli step in anticipo, anche perchè non siamo troppo avvezzi ai cambiamenti, allora molto probabilmente avremo una visione degli stakeholder come soggetti che sono quasi fastidiosi nell’ambito del progetto. Gli stakeholder introducono cambiamenti, chiariscono in ritardo rispetto all’inizio e quindi alterano i piani.

Già da queste considerazioni si capisce bene il senso del concetto “mindset Agile”. Andare verso l’agilità non è solo organizzare persone e lavoro in modo da cambiare il nome alle riunioni e fare qualche board dove appendere i nostri post-it, bensì è qualcosa di concettualmente più profondo. Le interessantissime testimonianze portate da alcune persone, principalmente HR e It manager nel corso dell’Agile for management forum tenutosi a Milano e organizzato da AgileReloaded lo hanno dimostrato: 

l’agilità è sistemica. 

Sebbene molti abbiano iniziato con un progetto pilota, il progetto per essere sostenuto e per potersi poi diffondere ha bisogno di appoggi da parte di diverse funzioni aziendali. 

Per dirla con un bellissimo concetto espresso da Marquet nel libro Turn the Ship Around, non dobbiamo spostare l’informazione verso “l’alto” (intesa come vertici aziendali) ma portare “l’alto” verso l’informazione. Nell’agilità è proprio questo uno dei passaggi fondamentali. “L’alto” deve andare “in basso” e acquisire le necessarie informazioni per capire le criticità e per vedere come un diverso modo di organizzare il lavoro può migliorare il processo e la vita stessa dei dipendenti. 

Quando il piano sfugge

Recentemente mi sono trovato a parlare con il mio istruttore di vela e amico (M.V. metto solo le iniziali per rispettare la sua privacy), ottimo velista, imprenditore e skipper. Mi chiedeva cosa fosse l’agilità e scrum. Nello spiegarglielo (spero chiaramente) ho fatto spesso riferimento al suo mondo professionale: le barche a vela e la nautica.

Progettare in modo Agile vuol dire accettare di andare a vela. Conosco il tuo porto di arrivo ma quasi mai lo puoi raggiungere con una rotta diretta, se ho il vento contro dovrò “bordeggiare”, vedi figura.

Andatura di “bolina” di una barca a vela

Bordeggiare vuol dire adattarsi ai cambiamenti del vento, risalire le difficoltà, con una modalità antifragile piuttosto che robusta.

Sempre per rimanere in un contesto nautico, quanto impiega una barca a vela per raggiungere l’isola al largo delle coste dalle quali siamo partiti? Possiamo fare una stima certo, considerando il vento che probabilmente ci sarà, ma dovremmo anche considerare la corrente, già più difficile da calcolare. Quindi come facciamo a capire dopo quanto tempo arriveremo?

Stimiamo il percorso e accettiamo di avere una stima non totalmente precisa, iniziamo a percorrerne una parte e poi rifacciamo la stima per il percorso rimanente. Reiteriamo questo procedimento fino alla fine ad intervalli regolari. Questo è sinteticamente l’approccio che possiamo seguire ma, comandante dell’imbarcazione, equipaggio e persone che ci attendono a terra devono tutti essere consapevoli della modalità con la quale stiamo conducendo il nostro viaggio altrimenti andremo a creare delle false aspettative rispetto all’orario di arrivo.

Nell’accezione Agile di progettazione i cambiamenti sono i benvenuti. Naturalmente non è il solo principio da seguire, ma quello che vorrei qui mettere in evidenza. Se i cambiamenti sono i benvenuti e se i clienti sono sempre da soddisfare allora non sarebbe più facile lavorare day-by-day senza piani? Non avremmo l’assillo delle deadline, dei release plan, la velocity, gli sprint e quant’altro.

Chi ha lavorato con questa modalità sa, senza altro aggiungere, che lavorare così è una vera tortura. Alcuni addirittura si spingono a sostenere che non ci sono altre possibilità. 

Purtroppo a volte hanno ragione ed in contesti in cui gli stakeholder non sono in grado di formulare le proprie esigenze e il business dell’azienda è confuso non è facile pianificare e progettare. Malgrado queste premesse rimane costante domanda che tutti noi progettisti, PM, Agilisti e quant’altro temiamo:

“Ma quanto mi costa e quando me lo consegni?”

Sempre per cercare dei parallelismi credo che nessuno vada in concessionaria chiedendo: ”Vorrei un’auto che sia comoda da guidare in città e anche per lunghi viaggi con un pò di optional carini e utili e che trasporti un pò di persone. Quanto mi costa e per quando sarebbe pronta?”

Nella seconda parte di questo articolo risponderemo a queste domande.

Pubblicato il

Una diversa visione del project management, la commistione di framework: agile, lean, devops,kanban

Loading

Abstract

Riorganizzare e cambiare visione vuol dire abbracciare anzitutto una vision “del tutto”,

olistica, dall’alto. Nella gestione dei progetti e quindi delle persone passare da una “non

organizzazione” ad una organizzazione vuol dire scegliere nuove metodologie. Ma quali?

E se volessi unirle, intersecarle è possibile?

In questo articolo provo a dimostrare che è possibile e che alla base di Agile c’è un concetto

non scritto che ci aiuto a non fossilizzarci su regole e metodi come abbiamo fatto per anni

almeno nel mondo IT.

Un caso comune

Nell’ambito del project management e senza scomodare alcun framework, posso

tranquillamente dire, almeno nella mia più che ventennale esperienza, che il modello

waterfall non è l’unico. Esistono altre modalità per gestire un progetto in cui l’unico

prerequisito è avere un’idea iniziale, più o meno chiara, della necessità da parte del cliente.

Uno scenario è il seguente. Il cliente ha una necessità o un’idea che viene inizialmente

discussa assieme ai “tecnici” al fine di estrapolare un’analisi, quasi sempre non scritta.

Chi sono i “tecnici”? Sono gli sviluppatori, che in genere sono anche i tester gli integratori e

coloro che rilasciano il prodotto o servizio. In quest’ambito non sempre esiste una figura di

project manager quindi gli sviluppatori sono gestori e non solo di se stessi e del proprio

lavoro ma anche del proprio flusso: produzione del software, test, integrazione e deploy. Un

esempio di team auto-gestito ma sicuramente non motivato!!

Attenzione a non confondere questa visione come una sorta di system thinking. In questo

caso infatti gli sviluppatori vedono solo il proprio flusso, quello che permette di portare il

proprio task verso il deploy. Interagiscono poco con gli altri membri del team e non hanno

assolutamente idea della vision del progetto. Nessun sviluppatore può realmente

considerarsi responsabile del proprio lavoro perchè non c’è alcuna organizzazione, nessuno

sa su quale task sta lavorando l’altro, non c’è un release plan.

Volendo introdurre dei cambiamenti in questa gestione “non gestita” del progetto, è

obbligatorio affidarsi ad un framework e attenersi totalmente alle sue direttive oppure

possiamo integrare e incrociare tecniche, strumenti, metodologie?

Proverò a rispondere a questa domanda.

La Vision

Vediamo ancora come un progetto non gestito può procedere.

Nel corso dei rilasci il prodotto inizia a prendere forma e naturalmente anche le richieste di

modifica da parte del cliente così come le richieste di correzione bachi. Quasi nulla è

documentato, le richieste sono fatte via mail o al più nel corridoio antistante l’ufficio, se

proprio siamo all’avanguardia abbiamo un timido sistema di ticket tracking, quasi fosse la

panacea in questo marasma.

Le richieste vengono accolte secondo una modalità “ansiolitica”. In pratica lo sviluppatore

porta a termine prima il requisito che lo preoccupa di più o che preoccupa di più il cliente.

Se però è venerdì allora implementerà quello più breve così lunedi non si dovrà ricordare a

che punto era arrivato. Ah! Naturalmente in quest’ultimo caso, pur essendo venerdì, termino

lo sviluppo, faccio qualche test (se ho tempo) e ...rilascio!! In produzione ovviamente!

Ma cosa sto sviluppando? Quale contributo sto dando e dove stiamo andando?

A queste domande non è possibile dare risposta perché non esiste una vision del progetto.

Volendo quindi dare una degna organizzazione al nostro progetto cosa possiamo fare?

Sicuramente dobbiamo evitare di infilarci in un’altra rigidità.

Di fronte a questo scenario è necessario un cambio di visione e di cultura. Quali strumenti ci

vengono incontro?

Una visione sistemica

Siamo in un’ottica di cambiamento. Non vogliamo più gestire i progetti in questo modo,

vogliamo strutturarli. Ma i progetti non hanno di per sé una personalità, non sono persone,

non sono oggetti. Strutturare un progetto vuol quindi dire strutturare le persone e quindi

l’azienda.

Stiamo parlando di cambiare visione.

L’obiettivo è costruire ciò che interessa agli stakeholder ma per farlo bene è necessario che i

componenti del team abbiano una visione olistica.

A tal proposito ci viene in aiuto la storiella dei sei ciechi e dell’elefante, che qui sintetizzo.

Sei persone cieche dalla nascita tentano di capire cosa sia un elefante ovviamente non

avendolo mai conosciuto e visto. Ognuno di loro cerca di farlo attraverso il tatto

concentrandosi chi sulla coda, chi sulla testa, chi sulle zampe, ecc. Siccome ognuno tocca

una parte diversa il risultato saranno sei interpretazioni diverse che non si integreranno fra di

loro. Non si avrà una visione sistemica del tutto e le parti di oggetti descritte, anche molto

bene nel dettaglio, saranno comunque diverse dall’insieme delle parti.

Chi non ha sperimentato queste problematiche in progetti con scarsa organizzazione alzi la

mano!

Cambiare vuol dire passare dall’osservazione (in senso generale del termine) del particolare

a quella del generale ma non nel senso di più “distante da” ma più dall’alto. Una visione

olistica che ci fa comprendere il tutto e dalla quale possiamo partire per creare il nostro

nuovo modello di progetto e di relazione con le persone.

Il Team

Il primo step del cambiamento deve agire sul team. Occorre cambiare passando, come

abbiamo detto, ad una vista più sistemica. Scrum ad esempio consente di cambiare le

abitudini del team introducendo un ritmo, una sequenzialità delle fasi, dei meeting in cui

confrontarsi, delle priorità nei task.

In Scrum il development team ha responsabilità e libertà di decidere come organizzare il

lavoro e come realizzarlo ma sempre in un’ottica condivisa. Il team lavora insieme,

fisicamente nella stessa stanza e attraverso i daily meeting realizza una comunicazione

continua.

L’approccio Scrum prevede inoltre un continuo miglioramento attraverso review e

retrospective meeting. Scrum sfrutta l'impegno del team come agente di cambiamento.

Ma non è sufficiente.

Il Flusso

Occorre lavorare sul flusso, per esempio utilizzando il framework Lean.

I principi Lean si concentrano sul flusso più di ogni altra cosa: i colli di bottiglia nel processo

devono essere rimossi e le attività dispendiose devono essere identificate ed evitate.

Lean si concentra sul processo, sulla visualizzazione del lavoro da fare, l’identificazione

degli sprechi e passa la ownership del flusso al cliente. La produzione infatti è pull: tirata

dalle necessità del cliente. In questo senso è molto utile introdurre Kanban negli stessi

Sprint. Kanban ci aiuta ad avere una visualizzazione del lavoro, dello stato e di chi prenderà

in carico ciascun task.

Abbiamo quindi preso in considerazione due framework Scrum con Kanban e Lean.

Lean ha origine in Giappone presso la Toyota con il nome di Toyota Production System

(TPS). Le sue basi vengono sviluppate da Taiichi Ohno e Shigeo Shingo durante gli anni

’50. Successivamente, negli anni ’90, grazie al libro “The Machine That Changes the World,

Lean Thinking and Lean Solutions” di James Womack and Daniel Jones, viene formalizzato

con il nome di Lean, consentendo alle aziende di adottarlo in modo strutturale.

Agile è decisamente più giovane: la sua origine è databile agli inizi del 2001 quando un pool

di esperti di sviluppo software danno vita al famoso Manifesto, che ne definisce i valori ed i

principi.

E’ possibile però integrare i principi Agile e Lean in modo da avere una commistione di

tecniche e di procedura finalizzate a migliorare la conduzione del nostro progetto?

Nell’IT abbiamo passati lunghi anni ad adottare la metodologia cosiddetta waterfall. Fasi ben

definite, moltissima documentazione, pochi spazi alle modifiche in corso d’opera, tempi

lunghi di rilascio tra un deliverable e l’altro, rilasci complessi. Un framework molto rigido.

Ma anche la “non gestione” di cui ho già parlato è di per sé un framework. Potremmo infatti

codificarne alcuni aspetti e notare come sono ricorrenti tra un progetto e l’altro.

Se proprio vogliamo abbandonare questi modelli è auspicabile adottarne di più duttili, dove

la diversità è ricchezza e la visione olistica del tutto (leggasi progetto o azienda) è un

prerequisito importante.

Lean - Agile

Iniziamo quindi a confrontare e a trovare i punti di contatto tra Scrum e Lean.

In Lean dobbiamo:

● identificare ciò che vale (value) individuare ciò per cui i clienti sono disposti a pagare

un prezzo

● identificare il flusso del valore (value stream): allineare le attività che creano valore

nella giusta sequenza

● far scorrere il flusso del valore (flow): mettere in atto le attività a valore senza

interruzioni

● fare in modo che il flusso sia tirato (pull): fare scorrere il flusso in base alle richieste

del cliente

In Scrum viene creato il Product Backlog da parte del Product Owner. Il backlog è la

rappresentazione tramite user story delle necessità del cliente (Value) che vengono eseguite

secondo priorità (value stream) definite dal PO, che è la “voce” degli stakeholder. Gli item

selezionati dal development team sono quelli ad alta priorità e che hanno tutti i dettagli

necessari (flow). Il flusso è pull infatti nel review meeting le priorità del backlog possono

cambiare a seguito di richieste del PO o degli stakeholder.

In Scrum è inoltre intrinseco identificare ciò che non è importante (waste), si dice infatti “se

non è presente nel product backlog allora non esiste”. Il backlog è realizzato in base alle

reali necessità del cliente.

Il visual management in Scrum è realizzato attraverso l’utilizzo di diverse board in cui tutti i

componenti del team possono aver accesso. Kanban può essere integrato in Scrum

portando un ulteriore vantaggio.

Il dev team (al massimo di 9 persone secondo le direttive Scrum) è composto da persone

cross-funzionali, che lavorano fisicamente insieme, che stanno insieme per un lungo periodo

al fine di consolidare la conoscenza reciproca. Insomma un feature team in grado di portare

a termine, ad esempio, il task di assemblaggio dell’elefante. Nel team avremo le persone

specializzate nelle gambe, quelle esperte con la testa, quelle esperte di coda e così via e

naturalmente gli esperti di integrazione e test.

Il team è considerato un tutt’uno e come tale, nel suo complesso, ha tutte le skills necessarie

a portare a termine il proprio lavoro, è un team auto-organizzato e che ha come focus

massimizzare il valore per il cliente e non il numero di linee di codice prodotte da ciascun

membro.

Lean – Agile - Devops

In Scrum il rilascio avviene al termine di uno Sprint e dopo lo sprint review meeting.

E’ possibile integrare tecniche Devops per massimizzare i rilasci e ottimizzare il valore per

gli stakeholder, fermo restando che un task, prima di essere rilasciato, deve soddisfare i

done criteria e i criteri di accettazione. Lo sprint review infatti è un modo o un’opportunità per

avere il feedback degli stakeholder ma non vieta i rilasci anticipati. Oltretutto rilasci ed

integrazione continui facilitano la correzione di eventuali comportamenti che non soddisfano

il cliente.

Conclusione

Nel mondo della musica esiste una parola che mi è sempre piaciuta: patchanka.

In italiano si pronuncia pacianca. Non se ne conosce l’etimo certo ma si può interpretare

come un genere musicale caratterizzato da una commistione di stili musicali diversi, che

rimandano a punk, ska, reggae, rock, funk, rap e molto altro.

Ho esordito in questo articolo dicendo che per migliorare ed uscire da disorganizzazione o,

da eccessiva organizzazione, è opportuno abbracciare un pensiero sistemico, olistico e più

generale. La visione del tutto, termine sempre più presente anche in altre discipline

esoteriche e nella fisica quantistica.

Non pensiamo alle singole parti ma al tutto...

Un ingegnere fisico, ricercatore, e autore di numerosi libri e seminari, Vittorio Marchi, tra i

suoi illuminanti pensieri parlava proprio di questo concetto che provo a riportarvi con parole

mie. Se io prendo un bicchiere d’acqua dal mare, posso dire che ho ottenuto qualcosa di

diverso? Ovviamente no, è solo un modo diverso di vedere la stessa cosa. E’ quindi solo un

problema di visione, osservando più dall’alto il mare e il contenuto del bicchiere ci

appariranno come la stessa cosa.

La direzione che ho voluto qui delineare è quella della commistione (patchanka) di

framework:

Scrum, Lean e Devops. Non vedere lo Sprint come scolpito nella pietra ma permeabile di

miglioramenti continui anche nella sua stessa definizione.

Ogni cosa evolve in questo nostro universo, anche le metodologie di progetto.

Bibliografia

Numero di Gennaio 2020 di Agile Italian Magazine 

The Beer Game 

Scrum and DevOps 

Lean-Agile-Devops 

La quinta disciplina. Peter Sege