Introduzione

Quando parliamo di Agile e delle varie metodologie che ne incarnano le pratiche, a partire da Scrum, non dobbiamo mai dimenticare che alla base di queste ci sono una serie di principi, una cultura, una mentalità da cui tali pratiche scaturiscono. Uno degli errori più comuni in cui ci imbattiamo — e che magari abbiamo compiuto in prima persona — è proprio quello per cui un gruppo di lavoro, un’organizzazione, un’azienda adottano dei comportamenti che prevedono certe pratiche, senza però che i principi fondanti siano stati interiorizzati. Di questo argomento ci siamo occupati anche nella Guida Galattica per Agilisti e ripartiamo proprio da quel testo per passare poi a una serie di considerazioni derivanti da esempi concreti.

Cargo cults

Nel 1974, il fisico statunitense Richard Feynman, in un discorso al California Institute of Technology, mise in guardia i ricercatori dal non diventare “scienziati da culto del cargo” [1]. Feynmann coniò questa espressione rifacendosi a un tema ben noto agli antropologi culturali, ossia quello dei cosiddetti cargo cults, un fenomeno religioso affermatosi in alcune società tribali dopo i ripetuti contatti con società tecnologicamente più sviluppate.

I casi meglio documentati riguardano l’area del Sud Pacifico, in particolare nelle isole della Nuova Guinea e nell’arcipelago delle Nuove Ebridi. Qui, nel periodo precedente la Seconda Guerra Mondiale e ancor più durante tutto il conflitto con i Giapponesi, arrivarono enormi quantità di beni moderni, paracadutati o fatti atterrare con aerei cargo e destinati alle forze britanniche, australiane, neozelandesi e soprattutto americane di stanza in quei territori. Questi prodotti moderni (vestiti, cibo, utensili, apparecchiature varie) si diffusero anche fra le popolazioni native, determinando un drastico cambiamento nella cultura materiale e negli stili di vita degli indigeni [2] [3].

Con la fine delle ostilità e la capitolazione del Giappone. le basi aeree furono abbandonate e di conseguenza si interruppe il rifornimento di merci via cargo. Non comprendendo le ragioni geopolitiche della fine di tali rifornimenti, i nativi svilupparono una serie di cerimonie, basate su riti magici di “imitazione” delle pratiche e dei comportamenti che avevano visto compiere da parte dei militari alleati.

Sono documentati casi in cui furono costruiti simulacri di apparecchi radio con cuffie e microfoni, che poi erano utilizzati dentro finte torri di controllo costruite in legno e bambù. Furono riprodotti degli “aeroplani” in materiali di fortuna, furono create delle rudimentali piste di atterraggio illuminate con torce e altri segnali. Tali culti ebbero forte diffusione nel decennio immediatamente successivo alla fine della Seconda Guerra Mondiale, per poi declinare gradualmente negli anni successivi.

Alcuni di questi culti si sono evoluti e differeziati, con sfumature varie, in veri e propri movimenti millenaristi, tra i quali spicca il cosiddetto “culto di John Frum” il cui nome pare derivare dalla corruzione della frase “I am John from America”; gli adepti di tali movimenti, ancora in anni recenti, continuano a svolgere le loro cerimonie, tra le quali delle imitazioni di parate militari.

La lezione di Feynmann

Con “scienziati da culti dei cargo” quindi, Feynmann intendeva indicare quegli studiosi che imitano comportamenti scientifici, restando però in realtà solo alla superficie, senza comprendere le motivazioni profonde del metodo e degli strumenti che adottano.

Per non essere cargo cult scientists, occorre stare sempre in guardia nei confronti delle suggestioni e delle illusioni, mettere sempre in dubbio e sotto attento scrutinio i risultati delle proprie ricerche, e valutare i possibili punti deboli delle varie teorie, evitando di adottare in maniera acritica i risultati delle ricerche di altri scienziati, se questi non passino una attenta valutazione.

A partire dall’esortazione di Feynman, più genericamente oggi il termine cargo cult è utilizzato quando si applichino superficialmente a una disciplina le tecniche e le pratiche di un’altra materia, aspettandosi una sorta di misteriosa magia che porti inspiegabili benefici, senza rendersi conto che è necessario impiegare determinati strumenti solo se si ha una profonda consapevolezza delle loro caratteristiche e dei loro princìpi.

Il culto del cargo e l’adozione delle metodologie agili

Tornando alle metodologie agili di sviluppo del software, la tematica del culto del cargo viene spesso tirata in ballo quando si parla dell’adozione delle metodologie agili in una organizzazione. Fare Scrum meccanicamente o disegnare una Kanban board senza aver chiari i valori e i principi profondi che vi stanno dietro è un po’ come costruire una “radio” di legno e gusci di cocco su una spiaggia del Sud Pacifico, aspettandosi che arrivi un aereo cargo pieno di cibo e altri prodotti.

È quello che fecero i manager della Ford quando imitarono il Toyota Production System senza avere un’appropriata conoscenza del lean, dando luogo al cosiddetto Lean di Chicago. Fare cargo cult in Scrum significa, per esempio, organizzare gli sprint, fare planning e tutte le “cerimonie” senza però comprenderne realmente i valori fondanti, cercando poi spesso una scusa per derogare a queste pratiche.

Questo può significare interpretare in modo superficiale le cerimonie, i ruoli e le altre pratiche. Spesso si sente dire: “In azienda siamo agili ormai da un anno; bella roba, anche se, per come viene ‘venduto’, devo dire che non ci vedo tutta questa rivoluzione e questi benefici”. Queste affermazioni dimostrano un approccio limitato in cui è probabile che non si riesca a ottenere il famoso incremento delle prestazioni pubblicizzato da Scrum.

Esempi di cargo cult

Molti possono essere gli esempi di “culto del cargo” che possiamo ritrovare all’interno di un team che stia provando a fare agile. La maggior parte sono riconducibili al principio del “Facciamo questo perché va fatto”. Per esempio, abbiamo i ruoli attivati — PO e Scrum Master — e facciamo le cerimonie — perché Scrum dice che vanno fatte — ma senza capirne il senso o senza che portino un reale beneficio. Dato che cambiare modo di lavorare, introdurre nuovi ruoli, o fare altri meeting ha un costo, se il team non ne ha un beneficio, finiranno presto per smettere di farlo.

Vogliamo pertanto proporre alcuni esempi — che non sono affatto esaustivi ma solo un campionario ridotto — che ci mostrano proprio questo: pratiche agili implementate senza consapevolezza, denotano “culto del cargo” e che quindi spesso sono un freno all’adozione matura delle metodologie agili.

Per farlo, presenteremo vari casi d’esempio, accompagnati da un “indicatore di cargo cult” a vari livelli di attenzione: non è nulla di ufficiale o previsto da qualche “testo sacro” sull’argomento, ma è un modo semplice per capire al volo la questione e rendere la lettura più agevole.

Scrum Meetings in ordine invertito. Indicatore di cargo cult: ALTO

La guida Scrum dice di fare le riunioni: pianificazione dello sprint, review, retrospettiva etc.). Però, domani, giorno di review/retrospettiva non abbiamo tempo di fare tutto. Possiamo intanto fare il plan del prossimo sprint e poi la review — o, peggio, la retrospettiva — si farà dopodomani? Almeno inziamo a lavorare al prossimo sprint…

Se vari eventi di Scrum vengono chiamati addirittura “cerimonie”, forse una ragione c’è… ed quella di metterne in luce anche l’adesione a un preciso calendario e gli specifici ambiti entro cui tenerle. Riteniamo pleonastico ricordare che l’ordine delle cerimonie segue una sua logica.

La review serve per vedere cosa abbiamo fatto, la retrospettiva come abbiamo lavorato. Entrambi questi meeting producono un output che è indispensabile per poter procedere alla pianificazione dello sprint successivo. Nella review per esempio potremmo comprendere meglio se qualcosa non ha funzionato e come migliorarla al prossimo sprint: quindi magari questo ci porterebbe a decidere di prendere meno cose in carico al plan, perché dobbiamo investire del tempo nel miglioramento, oppure ci aiuterebbe a capire che non abbiamo le forze per prendere tutte queste cose in carico con un conseguente abbassamento delle stime. Viceversa, potremmo capire che al prossimo sprint c’è spazio per fare di più.

Fra tutte le “distorsioni” di Scrum, questa delle cerimonie mal poste, o della sequenza non rispettata, è probabilmente quella che maggiormente evidenzia una mancata comprensione del senso delle cose.

Si stima perché si deve. Indicatore di cargo cult: ALTO
Nello sprint planning, il Dev Team si impegna a prendere in carico una serie di attività compatibili con il proprio ritmo. A volte questa scelta è forzata — dal PO? Dal capo? — mentre a volte è fatta più o meno a caso… Comunque sia, si stimano le storie in punti o in ore perché lo dice la guida Scrum o l’Agile Coach. Ricordiamoci che la Guida Scrum [4] non parla esplicitamente di stime, ma invece ci ricorda che:

Il Team di Sviluppo lavora per prevedere le funzionalità che saranno sviluppate durante lo Sprint. […] L’input per questo incontro sono il Product Backlog, l’ultimo Incremento del prodotto, la capacità prevista del Team di Sviluppo durante lo Sprint e le prestazioni registrate in passato del Team di Sviluppo. Il numero di elementi selezionati dal Product Backlog per lo Sprint è definito esclusivamente dal Team di Sviluppo. Soltanto il Team di Sviluppo è in grado di valutare cosa può compiere durante il prossimo Sprint.

Quindi non si parla esattamente di “stime”. Le stime servono al team per avere un metro con cui confrontare effort delle cose da fare con la “potenza di fuoco” del team stesso. Paradossalmente, se il team fosse perfettamente in grado di comprendere cosa e quanto deve essere fatto, potrebbe non stimare. Se gli item del backlog sono tutti piccoli e simili  fra loro — p.e., se usiamo i punti come metrica, potrebbero essere tutti elementi da 1 o 2 pt — il team stima il numero di item da inserire nello sprint.

Bisogna impiegare le storie utente sempre e comunque. Indicatore di cargo cult: BASSO

Scrum non indica alcun formato da seguire per la compilazione del backlog. Ogni tentativo di “imbrigliare” il processo di raccolta dei requisiti prima o poi vi si ritorcerà contro: il formato non è adatto al nuovo progetto che sta partendo, il team compila pedissequamente senza comprendere il senso oppure il processo da mappare è più adatto a un approccio task/kanban. Cercate di capire utilità del formato che state adottando.

Mancanza del senso nelle user stories. Indicatore di cargo cult: ALTO

Capita spesso di incappare in PO poco consapevoli del loro ruolo. Sono spesso ex analisti funzionali abituati a scrivere 20 pagine di analisi, oppure Project Manager che erano abituati a lanciare richieste del tipo “C’è da fare questo… stop”.

Le storie utente sono un ottimo strumento per definire le funzionalità del prodotto che deve essere realizzato e si basano sul noto schema: “In qualità di…, vorrei…, affinché…”. La parte della storia definita da “affinché” è un passaggio fondamentale, eppure spesso lo troviamo non compilato: un “affinché” debole o assente indica una scarsa attenzione al senso di quello che stiamo facendo, del motivo del progetto. In questi casi, purtroppo si osserva spesso una disaffezione al formato e all’approccio nel suo complesso, dato che non se ne percepisce l’utilità. In casi come questi, le storie utente tornano a essere spesso un titolo non molto differente dal “C’è da fare questo e quello”.

Per chi fosse interessato a questo tema, riporto alcuni esempi di storie “deboli”:

• “Come utente, vorrei fare login, affinché…”
• “Come utente, vorrei fare login, affinché possa fare login”
• “Come PO, vorrei che utente facesse login”
• “Come PO, vorrei che il team implementasse la funzione di login” (anche se probabilmente la versione più precisa è “Come PO voglio che il team implementi la funzione di login!”)

Lista AC (Acceptance Criteria) vuota. Indicatore di cargo cult: ALTO

La lista dei criteri di accettazione serve al team per capire quanto lavoro dovrà essere fatto e come il PO desidera che sia svolto. Una lista di criteri di accettazione vuota è di fatto un rischio sia per il PO che per il team. Il primo potrebbe ricevere a fine sprint una cosa differente da quella che serve o che si immaginava; il secondo potrebbe sobbarcarsi un lavoro più oneroso del previsto.

Nel corso degli inteventi di coaching in azienda, ho osservato che questo punto è fonte di forti attriti nel team. Spesso si finisce per dare la colpa al team o alla metodologia e si finisce con un “Meglio tornare alla vecchia maniera, tanto se dobbiamo scrivere un sacco di cose che poi non ci servono…  Tanto vale abbandonare le storie o Scrum”. Oppure “Uffa! Ma allora come PO devo scrivere tutti i dettagli al team di sviluppo… Mi piacerebbe che se la cavassero da soli…”.

Plan che è direttivo. Indicatore di cargo cult: MEDIO

Un piano dai forti connotati “direttivi” è spesso una conseguenza dei problemi evidenziati ai punti precedenti. E allora perché non lo consideriamo un indicatore di cargo cult alto? A volte la cultura aziendale, le abitudini, le gerarchie portano a un “ingaggio direttivo” del team da parte del PO.

Non è detto che questo atteggiamento sia un male assoluto. Certo, se il focus è rappresentato da miglioramento continuo del team, crescita, presa di coscienza, collaborazione e co-creazione, questo approccio potrebbe rappresentare un problema. Ma non è sempre detto. Provate a capire se perseguendo questo atteggiamento vi state perdendo qualcosa in termini di performance di progetto o di team e organizzazione.

Retrospettive che non producono action plan. Indicatore di cargo cult: BASSO

Organizzare una retrospettiva utile o efficace non è facile. A volte il team inizia a discutere senza arrivare a un dunque. A volte le azioni non escono perché c’è molto da capire o discutere prima.

Avere, al termine di una retrospettiva, un piano di azioni è importante, ma non fissatevi nel produrre per forza qualcosa. Meglio comunque creare un contesto di discussione confortevole, sicuro, trasparente non ostile in cui tutti possano esprimersi. Se le azioni non escono, potrebbe non essere indicazione del fatto che non si è capito quel che si fa e che quindi si sta facendo “cargo cult”. Le ragioni potrebbero essere altre e sensate.

Mancanza di retrospettive. Indicatore di cargo cult: BASSO

Allo stesso piano possiamo mettere la mancanza di retrospettive: il team non ne sente il bisogno e in parte potrebbe anche essere giusto.

Ma, attenzione: un conto è che le retrospettive non siano fatte, almeno per determinati periodi, il che forse non è grave; un altro un conto è il fatto che il team non ne percepisca il valore. Come mai non si comprende l’importanza di uno strumento come la retrospettiva, alla base di un meccanismo iterativo di miglioramento continuo? Se le cose stanno in tal senso, allora, l’indicatore di cargo cult è alto.

Action plan che si perdono. Indicatore di cargo cult: ALTO

Se, dopo tutta la fatica di fermarsi e fare una retrospettiva, il team non prende nota delle azioni da svolgere, non ne tiene conto durante lo sprint successivo o non si premura della loro reale implementazione, è probabile che non se ne sia compreso il reale significato.

L’action plan è output della retrospettiva e serve per provare concretamente a fare qualcosa per migliorare. Sono esperimenti, tentativi; a volte potrebbero non essere efficaci o, con il senno di poi, si potrebbe comprendere che non erano le cose da provare a fare. Non preoccupatevi di questo. Preoccupatevi del fatto che ci sia un piano d’azione. Piccoli passi, inarrestabili, verso il miglioramento.

Lo stand up che dura troppo. Indicatore di cargo cult: BASSO

Rimanendo in tema eventi e cerimonie, un evento che spesso è causa di fraintendimenti è lo stand up che rischia a volte di durare più dei canonici 10-15’. Qui ho messo un indicatore basso perché in genere non si tratta di un cargo cult legato alla mancata comprensione deil senso di quel che si fa, quanto piuttosto della scarsa capacità di gestire il focus: nello stand up non si dovrebbe entrare mai nel merito delle questioni, ma elencare e condividere gli eventuali problemi.

Spesso la conseguenza è che le persone iniziano a stufarsi di partecipare ogni giorno a un meeting che prende molto tempo e del quale non si comprende l’utilità: in fondo stiamo tutti nella stessa squadra e ci vediam tutti i giorni, che ci sarà di tanto importante da dirsi? Invece di aggredire il problema — il meeting dura troppo tempo — si cerca di aggirarlo: e questo è cargo cult.

Conclusione

In questo mese abbiamo introdotto il tema del cargo cult come fattore di distrazione dal processo di adozione dell’Agile. Si tratta di un fenomeno derivante dal non comprendere il senso delle cose che si fanno e che quindi spesso porta a non comprenderne il valore. La conseguenza spesso è che questo finisce per rallentare o bloccare il processo di transizione verso l’Agile.

In questa puntata abbiamo parlato di cargo cult nelle cerimonie Scrum, ma si potrebbe allargare il discorso anche a Kanban. Il prossimo mese parleremo di come il cargo cult possa impattare sulla implementazione dei ruoli.