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
La quinta disciplina. Peter Sege
