Prosegue la serie dedicata ai concetti abilitanti all’Agile. Dopo l’articolo introduttivo del mese scorso, in questa puntata parliamo di quelli che probabilmente sono i concetti alla base dei valori e dei principi dell’Agile. Parliamo infatti di falsi miti, di quale sia il giusto approccio quando si deve affrontare un problema per lo più ignoto e di come sia più opportuno organizzare il team.

Comportamenti privi di consapevolezza

Un importante aspetto da tenere in considerazione quando si decide di adottare una metodologia agile all’interno della propria azienda o gruppo di lavoro è quello di esercitare le giuste pratiche senza dimenticare i principi e i valori che ci stanno dietro: riprendendo quanto detto nell’articolo precedente, non è bene fermarsi allo Shu dello Shu Ha Ri.

Tale approccio non solo è poco funzionale, ma anche rischioso sia per gli esiti di progetto, ma anche perche’ instilla una errata convinzione circa i benefici derivanti dall’uso di una metodologia Agile. Detto in modo più prosaico, il rischio che si corre è quello di scimmiottare le cerimonie e le pratiche senza comprenderne completamente il significato: in pratica, diventare delle agile monkeys come a volte viene scherzosamente detto in gergo.

Cargo Cults

Il fenomeno è descritto in modo esemplare da un fatto realmente accaduto nel secolo scorso a partire dalla seconda guerra mondiale, tanto che si trova una letteratura smisurata nelle biblioteche e in rete. Questo fenomeno è stato definito culto del cargo. Per agevolare il lettore, riporto direttamente da Wikipedia [1] alcuni passaggi fondamentali:

“Il culto del cargo (in inglese, Cargo cult) è un culto di tipo millenarista apparso in alcune società tribali venute in contatto con culture tecnologicamente più avanzate. Il culto è basato sulla richiesta di beni e merci (appunto i “cargo”) delle culture avanzate attraverso rituali magici o pratiche religiose. I credenti del culto credono che la consegna dei beni sia disposta per loro da parte di un ente divino.”

“[…] Il periodo classico di attività del culto del cargo è stato negli anni durante e dopo la Seconda Guerra Mondiale. La vasta quantità di materiale di guerra che fu paracadutata sopra quelle isole durante la campagna del Pacifico avvenuta contro l’Impero del Giappone significò infatti un drastico cambiamento dello stile di vita degli isolani. Prodotti industriali come vestiti, cibo in scatola, tende, armi e altri beni di utilità arrivarono in grandi quantità per rifornire i soldati e anche gli isolani che erano le loro guide e ospiti. Alla fine della guerra le basi aeree furono abbandonate, e i cargo non furono più paracadutati.”

“Per far sì che i carichi di beni tornassero a essere paracadutati o anche portati per via aerea o per mare, gli isolani talvolta iniziarono a imitare i comportamenti che avevano visto assumere dai militari occidentali. Fabbricarono quindi cuffie audio di legno indossandole seduti dentro a finte torri di controllo da loro costruite; iniziarono a mimare i segnali di atterraggio aerei in mezzo alle piste e ad accendere segnali di fuoco e torce per illuminare le piste di atterraggio e i fari di posizione. I cultisti pensavano che gli stranieri avessero una speciale connessione diretta con i loro antenati, che secondo loro erano gli unici esseri ad avere il potere sufficiente a produrre le ricchezze dei cargo.

[…] Durante gli ultimi sessantacinque anni, il culto del cargo è diminuito fino a scomparire quasi del tutto.”

Si possono inoltre ricordare alcune interessanti evoluzioni di tali credenze e di tali pratiche, che hanno portato alla nascita di vere e proprie religioni.

“Sull’isola di Tanna, nella Repubblica di Vanuatu, sopravvive ancora il culto di John Frum, uno dei più conosciuti, che nacque prima della guerra e divenne in seguito un culto del cargo.

[…] Jon Frum (noto anche come John Frum o John From) è la figura centrale di un culto del cargo diffuso sull’isola di Tanna, nello stato oceanico di Vanuatu.

Tale movimento religioso sorse tra gli anni trenta e quaranta del Novecento, quando Vanuatu era un condominio anglo-francese con il nome di “Nuove Ebridi”. Le circostanze della nascita di tale culto sono poco note. Non è chiaro se esso sia sorto spontaneamente tra gli abitanti di Tanna o sia stato creato ad opera di un singolo predicatore. E, soprattutto, la stessa figura di Jon Frum risulta essere avvolta nel mistero. È noto come tale culto cominciò a svilupparsi con l’arrivo di circa 300.000 soldati statunitensi nelle Nuove Ebridi, incaricati di difendere l’arcipelago da una possibile invasione giapponese. John Frum è infatti descritto come un soldato americano della seconda guerra mondiale, a volte ritenuto un uomo di colore, a volte un bianco. Non si hanno però notizie storiche circa l’esistenza di un militare americano chiamato Jon (o, più correttamente, John) Frum.”

“[…] Secondo un’altra interpretazione, tale nome deriverebbe da una corruzione dell’espressione John from America (“John dall’America”), che gli isolani possono aver sentito usare dalle truppe statunitensi di stanza sull’isola durante la guerra. Si ritiene inoltre che la figura di Jon Frum possa essere stata notevolmente influenzata da una divinità-vulcano adorata localmente.”

“[…] I seguaci di Jon Frum, costruirono strisce segnaletiche e una torre di controllo nella speranza che arrivassero degli aerei a portare loro i cosiddetti “cargo”.

Nel 1957, l’allora leader del movimento, Nakomaha, creò l’Esercito di Tanna, un’organizzazione non violenta che organizzava parate di stampo militare, durante le quali i partecipanti sfilavano con i visi dipinti con i colori rituali, magliette bianche con la scritta T-A USA (Tanna USA Army) e con finti fucili fatti di bambù. Tale parata viene ancora celebrata il 15 febbraio di ogni anno (il John Frum Day). La data del 15 febbraio è ritenuta particolarmente importante dai seguaci, visto che si ritiene che Joh Frum ritornerà sull’isola proprio in quel giorno (l’anno non è tuttavia noto). Il simbolo religioso più diffuso tra i fedeli è una croce di colore rosso.”

“[…] Sulla stessa isola è vivo il Movimento del Principe Filippo. I seguaci ritengono che il principe Filippo, consorte della regina Elisabetta II del Regno Unito, sia il figlio bianco di uno spirito delle montagne, di cui parlavano le loro antiche leggende. Egli sarebbe anche il fratello di Jon Frum.

La figura di Filippo si sovrappose quindi a quella del figlio di tale divinità locale, il quale, secondo le tradizioni locali, avrebbe viaggiato oltremare e avrebbe sposato una donna di grande potere. Tali convinzioni vennero rafforzate dal fatto che gli isolani ebbero modo di vedere il grande rispetto che gli ufficiali britannici di stanza sull’isola osservavano verso la regina Elisabetta: ciò li portò a concludere che Filippo fosse il figlio della divinità di cui parlavano le loro antiche leggende.

Non risulta noto con precisione il momento in cui tale culto si sviluppò. Con tutta probabilità, esso ebbe origine tra gli anni Cinquanta e Sessanta del Novecento. Quel che è certo è che esso venne notevolmente rafforzato dalla visita di Filippo ed Elisabetta a Vanuatu nel 1974. Al tempo, Filippo non era consapevole del fatto di essere considerato una divinità dagli isolani. Tale particolare gli venne reso noto da John Champion, l’allora Resident Commissioner britannico a Vanuatu tra il 1975 e il 1978 (al tempo, infatti, Vanuatu era un codominio anglo-francese con il nome di “Nuove Ebridi”).  Champion consigliò a Filippo di inviare un suo ritratto: fu così che il principe decise di inviare una fotografia autografata. Gli isolani ringraziarono inviando a loro volta un nal-nal, una mazza tradizionale per l’uccisione del maiale. Altre due fotografie vennero spedite successivamente (l’ultima risale al 2000). Tutte e tre le fotografie sono attualmente conservate dal capo del Movimento, Jack Naiva. Il 27 settembre 2007 cinque isolani di Tanna visitarono il Regno Unito. Durante la loro permanenza, essi incontrarono il principe Filippo al quale, con la domanda: ‘La papaia è matura o no?’ chiesero quando egli avrebbe fatto ritorno sull’isola, come previsto dalle profezie. A tale domanda Filippo rispose: ‘Che la papaia sia matura o meno, dì al capo Kawia che ora fa freddo, ma quando farà caldo invierò un messaggio’ facendo capire loro che i tempi non erano ancora maturi.”

Il culto del cargo e l’adozione delle metodologie Agili

Dopo questa digressione, in cui abbiamo riportato le informazioni che tutti possono trovare su Wikipedia [1], veniamo alle nostre questioni.

Quando si parla del mito del cargo in riferimento a implementazioni di Scrum (o di altre metodologie Agili) stiamo parlando di un modo di introdurre la nuova metodologia applicando le tecniche e le pratiche ed aspettando una sorta di misteriosa magia che porti inspiegabili benefici, senza invece rendersi conto che è necessario adottare un utilizzo informato e consapevole del significato che ci sta dietro.

Due importanti personaggi nella comunità IT  come Craig Larman e  Bas Vodde, in un loro libro “Scaling Lean & Agile Development” [2], affrontano in modo eccellente il tema dell’adozione delle metodiche scrum in una prospettiva sbagliata, da cargo cults, appunto.

Nella sezione “Avoid… Fake ScrumMasters” affermano infatti per esempio che non basta fregiarsi del titolo di Scrum Master per assicurarsi che si faccia Scrum in azienda. Questo porta spesso a quello che loro definiscono “falsi scrum master”, i quali sono ottenuti “…cambiando la denominazione di qualcuno in ‘Scrum Master’, quando invece  questa persona agisce, ed è incoraggiato a farlo dall’organizzazione, ne’ più ne’ meno come un normale project manager”.

I due autori insistono nel rischio dell’adozione di Scrum non consapevole, in stile cargo cult descrivendo una situazione paradossale, in cui si dice di aver adottato Scrum, ma si continua a lavorare come prima:

“Abbiamo adottato Scrum. La lunghezza del nostro sprint corrisponde alla lunghezza del progetto. Il Product Owner decide gli elementi che vanno nello sprint e il project manager fa la funzione di ScrumMaster: è lui che fa il backlog per lo sprint e assegna i compiti ai membri del team”.

Dalle noci di cocco all’Agile

Il “culto del cargo” è usato come metafora quando si tenta di mettere in pratica una metodologia Agile, senza comprenderne i principi profondi che ne costituiscono la base. La domanda quindi è ovvia: come facciamo a riconoscere quando stiamo facendo “cargo cult implementation”? Di seguito riporterò alcuni esempi interessanti, che in parte ho trovato in letteratura, in parte ho vissuto di persona.

Cattiva implementazione delle “cerimonie”

Uno dei casi tipici è legato alla cattiva implementazione o a una implementazione solo parziale delle varie cerimonie, dei ruoli, e delle altre pratiche. Un caso tipico è quello della azienda che dice “siamo agili ormai da un anno; bella roba, anche se, per come viene venduto, devo dire che non mi pare sia tutta questa magia…”.

Approfondendo, si scopre che i gruppi, pur usando le pratiche base (Product Backlog, Sprint Backlog, Sprint Execution) per esempio hanno pochissima attenzione all’aspetto gruppo. Esemplare il caso del Daily Standup Meeting: nel caso in questione, questo incontro non era seguito dal team di progetto ma da un gruppo eterogeneo di persone che si incontravano in modo poco  regolare ogni due settimane. Il gruppo era composto da persone assemblate da vari team senza una logica precisa. Lo schema delle tre domande non veniva quasi mai seguito. Gli incontri erano invece organizzati in modo più o meno improvvisato senza una durata precisa.

Il gruppo chiamava Scrum questo meeting (non Daily Scrum) tanto che anche altri incontri presero in breve il nome di Scrum. Di lì a poco la parola Scrum era diventata sinonimo di incontro (in fondo scrum vuol dire “mischia”, no?). Questo è “cargo cult” perche’ si è perso il vero significato del Daily Scrum, perdendo gli eventuali benefici del confronto giornaliero fra i vari membri dei team.

Mancanza di attenzione al gruppo

Un altro caso emblematico è quello in cui si poneva poca attenzione agli aspetti di lavoro di gruppo: sulla base di improrogabili esigenze aziendali, le persone per esempio venivano più o meno regolarmente spostate o aggiunte al progetto. Il management aveva poco interesse nel proteggere il gruppo. Lo Scrum Master per esempio non aveva sufficiente potere per andare a bloccare gli impedimenti che arrivavano dall’alto.

La lamentela diffusa emergeva poi quando, in fase di pianificazione, il team non riusciva a fornire una velocity affidabile (cioè quante cose si riescono a fare nell’arco dello sprint) e soprattutto accadeva che il margine di errore era pressoche’ costante, iterazione dopo iterazione. Anche questo è cargo cult, perche’ non si consente di alimentare il consolidamenteo e la responsabilizzazione del team, che è uno dei principi di Agile. C’è chi parla addirittura di emancipazione come passo ulteriore a questo empowerment.

Uso sbagliato del Product Backlog

Un uso sbagliato del Product Backlog (senza raffinamento e senza sgrossatura) porta a considerare tutti gli elementi come User Story. Anche questo è cargo cult: il PBI non è una semplice todo list. È un raffinato modo di gestire le cose da fare, con priorità, riduzione dello spreco e molto altro ancora.

Qualche esempio divertente ma istruttivo

Riporto un esempio divertente, trovato in rete:

“[…] Cliente: Sì, facciamo Agile ormai da un po’ di tempo

Agilista: Benissimo! Quindi non avete avuto problemi a far lavorare il Product Owner a stretto contatto con il gruppo di sviluppo?

Cliente: Be’, aspetta… in realtà non abbiamo un Product Owner.

Agilista: Ah… Ma allora chi mantiene in ordine il Product Backlog?

Cliente: Mah… a dire il vero non abbiamo un vero e proprio Product Backlog.

Agilista: E come fate, allora, a pianificare gli sprint?

Cliente: Be’… non li pianifichiamo, almeno non in modo molto formale… Però facciamo il meeting tutte le mattine! Non è questo tutto quello che conta?

Accanto a questo, è significativa quest’altra affermazione del manager di quello che si definiva un gruppo Agile:

“Ci piacciono le cose così come sono. Sappiamo che non sono perfette… ma non vogliamo cambiare”… Alla faccia del kaizen e del miglioramento continuo.

Le due frasi seguenti mi piacciono molto perche’ rispondono a molte delle domande che si sentono fare quando c’è una percezione ostile nei cofronti di Scrum (in gergo, scrumbut):

“Non si dovrebbe mai cadere nell’applicazione di Scrum in stile culto del cargo, ma la realtà è che ogni passo sulla strada che conduce a Scrum è in genere migliore di tutto ciò che l’ha preceduto”.

E questa è la mia preferita:

“Non provate senso di colpa se la vostra implementazione di Scrum non è esattamente da manuale. Sentitevi in colpa se avete smesso di impegnarvi per renderla migliore”.

Curiosità “antropologiche”

Se parlare di temi “antropologici” per spiegare meglio le metodologie agili può sembrare strano a qualcuno, a dire il vero avevamo preso spunto da certe tematiche anche in un articolo di qualche anno fa [3] pubblicato su queste pagine, in cui l’esempio del “coltello dell’aborigeno” era stato utilizzato per spiegare il rapporto tra tecnologie e comportamenti.

E per rimanere a fenomeni “antropologici” moderni, ogni anno l’equivalente della popolazione di una piccola cittadina si raduna nel Black Rock Desert nel Nevada per partecipare all’evento Burning Man, uno strepitoso happening artistico e musicale che dura una settimana e si tiene tutti gli anni alla fine di agosto. Il nome è dovuto al grande fantoccio che, alla fine del festival viene incendiato, in una sorta di rito liberatorio. Ebbene… il tema dell’edizione del 2013 era esattamente il Cargo Cult.

Obbiettivi di alto livello, mezzi obbiettivi, obiettivucci, quaqquaraqquà

Il fatto agile che vorrei affrontare adesso è legato all’impegno e al tipo organizzazione che deve darsi il team.

L’argomento è estremamente vasto e impatta non solo sui temi agili ma anche più genericamente sul team building. Vorrei qui cercare di affrontare solo alcuni aspetti legati all’organizzazione del lavoro senza alcuna pretesa di offrire un’analisi completa e coerente, obiettivo peraltro veramente improponibile.

Team Scrum: impegno esclusivo?

La prima cosa di cui discutere è se un team Scrum debba essere impegnato al 100%,  ossia se le persone debbano fare una sola cosa: il progetto in questione, in esclusiva. Per rispondere, vorrei partire da un esempio preso in prestito dallo sport che secondo me funziona abbastanza bene per capire di cosa stiamo parlando.

L’esempio è quello della staffetta 4 x 400, ma potrebbero andare bene altri sport in cui la ricerca della prestazione si basa sia su allenamento fisico individuale ma anche sul lavoro di squadra, coordinamento, sincronizzazione.

Cosa serve a una squadra per vincere una gara di staffetta? Moltissime cose e, se si esclude il doping, molte sono inerenti al lavoro di team: serve sì allenamento fisico, ma anche una perfetta conoscenza dei meccanismi di base, messa in pratica con un estenuante lavoro sul campo; serve un perfetto affiatamento personale, tanto che spesso gli atleti devono essere anche ottimi amici.

Portando l’esempio nel caso di Scrum, è necessario quindi che il gruppo sia allocato al 100%? Be’, come diceva Guzzanti nella gag di Quelo, in questo caso “la domanda è malposta”. A me verrebbe da rispondere che un team per essere performante dovrebbe sempre lavorare in determinate condizioni che rappresentano l’ottimale. Il full-time è una di queste. In questo modo ci diamo un obiettivo di alto livello. Scrum si pone sicuramente obiettivi di alto livello: fra questi la qualità è ai primissimi, e quindi questa impostazione suggerisce che si cerchi di lavorare sempre in un certo modo piuttosto che in un altro.

In questo caso possiamo quindi dire che, siccome le teorie del team building ci dicono che se si lavora in modo full si è più felici e più performanti, allora in Scrum si assume che sia preferibile lavorare in modo completamente allocato sulla stessa attività: attenzione però, che 100% non vuol dire tutte le 8 ore lavorative, perche’ è sempre meglio stare su un limite più basso, per mantenere il cosiddetto ritmo sostenibile.

Team Scrum: solo “titolari” in squadra?

Cosa possiamo dire a proposito del turn over? Il team deve essere stabile? Cosa succede se ci sono persone che entrano ed escono dal team? Stiamo violando alcune regole di Scrum? A queste domande si può rispondere cercando anzitutto di chiarire alcuni punti: perche’ facciamo turn over? Che obiettivo ci aspettiamo di raggiungere?

Anche in questo caso, dato che Scrum si pone degli obiettivi alti, richiede che si operi partendo da una base stabile e forte, altrimenti è inutile cercare di volare in alto. Se non consolidiamo la base, per esempio con un significativo turn over sul gruppo, peggioriamo la stabilità del sistema: in questo modo in alto non ci arriveremmo mai, ma non è questione di ì Scrum, perche’ il concetto vale anche per RUP o Waterfall.

Per fare un esempio, in agile si parla molto di empowerment delle persone dello staff, perche’ è concezione comune che solo lo staff può valutare, decidere e agire meglio, se queste cose le fa direttamente piuttosto che seguendo dettami imposti.

Uno di questi ambiti è quello delle stime agili: in questo caso si dice che il team, iterazione dopo iterazione  impara a misurare la propria capacity, ossia quanto riesce a produrre per ogni iterazione.

Questo potente meccanismo funziona solo se il gruppo cresce insieme senza alterazioni nella composizione o nella modalità di lavoro. Introducendo un turn over quindi, si impedisce di perseguire una delle più importanti attività che Scrum si pone come obiettivo.

Ma se non possiamo fare a meno di fare turn over? Non possiamo fare Scrum? Senza entrare nel partito del totalitarismo agile, si può  certamente concordare che tanto vale tornare a usare la vecchia maniera: facciamo le stime in modo predittivo, prima che inizi il progetto. Funziona? Vi siete trovati bene? Forse sì. È affidabile? Poco. È Scrum? No. È il massimo che possiamo fare? No, questo no: c’è di meglio e lo sappiamo benissimo, anche quando ci raccontiamo che non ci possiamo permettere altro.

Team Scrum: una sola attività?

Discorso analogo per quanto riguarda il focus di progetto: il team deve lavorare solamente su una sola attività? No non è obbligatorio, anzi in Scrum esistono delle pratiche (alcune dai nomi pittoreschi, come il Batman team) che permettono ad esempio al team durante le iterazioni di un progetto che alcune persone possano fare anche altro, mettendo in pratica una sorta di part-time. Per esempio, si può far si che il team sviluppi la versione 2.0 di un prodotto, ma al contempo dedichi una fetta del tempo per fare manutenzione o bug fix alla 1.0. Questa è una pratica lecita: il team sa che la capacity del gruppo sarà più bassa. La differenza rispetto ad altri scenari, dove spesso non si sa cosa succede e cosa possiamo aspettarci dal gruppo di lavoro, è che, in questo caso, il team è esattamente in grado di prevedere l’andamento, il tasso di abbassamento delle prestazioni e farlo presente al management.

Scrum come specchio

Per questo si dice che Scrum is a mirror: ci mette di fronte alle nostre disfunzioni, delle persone e del processo. In altri contesti si può far finta di nulla. Scrum invece è cinico: te le sbatte in faccia. Un’altra metafora interessante è quella del laghetto a cui si abbassa il livello dell’acqua: man mano che scende affiorano scogli e pietre nascoste, che erano comunque pericolose per la navigazione.

Tornando all’esempio della staffetta 4×400: è necessario che lavorino insieme? Che il team non cambi? Che stiano concentrati su un solo set di allenamenti? Che si allenino in un solo sport? Tutte queste domande trovano risposta in funzione del tipo di gare che si vuole affrontare e dei risultati che ci aspettiamo.

Un fenomeno che si riscontra a volte, e che è frutto di questo scenario, è il seguente: è il team stesso a capire se una cosa va bene o va male e ad agiree di conseguenza. Può capitare per esempio che un membro della squadra abbia problemi personali o di lavoro legati ad altri progetti, tanto da non poter essere presente a tempo pieno e con la testa concentrata sul progetto: in tal caso un buon team deve avere la serenità e la possibilità di farglielo notare, chiedendogli di prendersi del tempo per risolvere i suoi problemi e tornare nel team più motivato e concentrato di prima. A volte è lui stesso che, comprendendo di essere un peso, si allontana dal gruppo per non rallentare tutto il team. Casi come questi rappresentano forse l’espressione più alta dell’essere una squadra.

Ispezione o pianificazione

Per concludere, un tema molto spesso dibattuto è legato al fatto se in Agile si pianifichi o meno prima dell’inizio del progetto. Una delle colonne portanti dell’Agile è l’inspect and adapt o come recita una delle massime dell’Agile manifesto è “rispondere al cambiamento” piuttosto che seguire un piano predeterminato. A volte questo instilla l’idea che in Agile non si effettui alcuna pianificazione preliminare ma anzi si viva il progetto alla giornata vedendo quello che si ha davanti agli occhi. Questa visione non è corretta, anzi per molti versi è proprio lontana dalla realtà.

In Agile infatti si fa una prima pianificazione di massima, pianificazione che però viene sempre rivista e aggiornata. Un processo Agile infatti è organizzato in iterazioni secondo il noto schema Plan Do Check Adjust  (PDCA, trovate milioni  di riferimenti in rete, dalla qualità totale di Deming, al Toyota Production System, al libro di Jurgen Appelo); in questo modello, in modo continuo si fa la pianificazione a breve termine, si agisce, si controlla il risultato del proprio lavoro, si aggiusta la mira.  Quindi si ragiona in modo iterativo e incrementale.

L’esempio dello sci estremo

Per capire meglio questo concetto riporto spesso un esempio che ho trovato all’interno di un testo piuttosto famoso e ben fatto: “Essential Scrum” di Kenneth Rubin [4]. L’autore prende come esempio quello della discesa estrema con gli sci dalla cima della montagna e racconta di aver chiesto a suo amico appassionato di questa disciplina estrema se prima di fare la prova fosse solito pianificare ogni singolo passaggio, visto che l’aveva osservato effettuare numerose ricognizioni prima della discesa. La risposta dell’amico fu un semplice “no…”, a cui però si aggiunge poi una motivata spiegazione:

“No… sarebbe impossibile. Io cerco di individuare a grandi linee dove voglio arrivare al termine della mia discesa, dandomi quindi un obiettivo di massima; poi cerco anche di capire a grandi linee la conformazione della montagna per poter avere una idea grezza del possibile percorso che potrò compiere. Ma non oso, ne tantomeno potrei, spingermi oltre: non è possibile infatti sapere a priori cosa si nasconda dietro una duna di neve fresca o come reagisca al mio peso un pianoro di neve apparentemente compatta. Dovrò quindi improvvisare affidandomi a tutte le mie capacità atletiche e mentali nonche’ alla mia attrezzatura. Non è quindi una questione di poter prevedere, ma anzi è fondamentale saper reagire in tempi rapidi a quello che mi capiterà davanti. Pianifico quindi la direzione, non la rotta specifica per arrivare all’obiettivo”.

Più ci penso e più mi convinco che questa è probabilmente la metafora migliore per esprimere il modo corretto di gestire un progetto in modo adattivo e iterativo.

Conclusione

Termina per ora qui questa miniserie dedicata ai “fatti” agili, ma non è detto che non mi vengano in mente altre pillole abilitanti; i temi dell’Agile Management, comunque, restano presenti sulle nostre pagine, con una nuova serie in cui parliamo di management tramite una delle metodologie più utilizzate in questo contesto. La “Guida galattica per Scrummers” presenterà un percorso di scoperta dei concetti teorici ma anche pratici di Scrum e di Agile. La serie fa parte di un progetto editoriale più grande che speriamo possa vedere la luce nella prossima primavera.

Riferimenti

[1] La voce “culto del cargo” su Wikipedia

http://it.wikipedia.org/wiki/Culto_del_cargo

[2] Craig Larman – Bas Vodde, “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum”, Addison Wesley, 2008

[3] Francesco Saliola – Giovanni Puliti, “Aspetti sociali del web – I parte: Tecnologie e comportamenti”, MokaByte 149, marzo 2010

https://www.mokabyte.it/cms/article.run?articleId=1XJ-SFX-Y22-RCV_7f000001_30087332_532365df

[4] Kenneth S. Rubin, “Essential Scrum: a practical guide to the most popular agile process”, Addison-Wesley Professional, 2012