Introducing Deliberate Discovery

Traduzione dell’articolo Introducing Deliberate Discovery di Dan North

Un’introduzione al concetto di Deliberate Discovery

L’anno scorso ho scritto sugli errori che commettiamo nella fase di pianificazione o, meglio, del fatto che quando facciamo pianificazione ci concentriamo sempre sugli elementi sbagliati.

Ci lasciamo ossessionare dalle story, dagli story point e dalle stime, perché così ci è stato insegnato. Tutto questo mi fa venire in mente una storia: un uomo incrocia un ubriaco, in piedi di notte sotto un lampione a fissare il pavimento. L’ubriaco gli dice che ha perso le chiavi e che le sta cercando. L’uomo gli spiega che ovviamente le chiavi non possono essere sotto il lampione, altrimenti riuscirebbe a vederle. “No“, gli risponde l’ubriaco, “le ho perse laggiù, ma c’è buio, così preferisco cercarle qui

Il nostro lampione è il Planning Game, che richiede la scrittura di Storie e il calcolo di una stima, l’uso di carte da Planning Poker e di altre Tecniche di Stima (tutti termini che nella Letteratura Agile sono riportati in maiuscolo e che così sono considerati Ufficiali).

Io sostengo che non stiamo usando il tempo per la stima in modo efficace e che dovremmo invece dedicare il tempo nello scoprire quante più cose possibile fintanto che siamo riuniti nella stessa stanza, ed ho chiamato questo processo “Deliberate Discovery“, “Scoperta intenzionale. Marc McNeill ha commentato: “Scoperta intenzionale. Come opposto di scoperta fortuita? O come un altro tipo qualsiasi di scoperta? Perché aggiungere la parola “intenzionale“?”

Scoperta fortuita

Se si ripete qualcosa un po’ di volte, ogni volta si impara qualcosa di più. Probabilmente. Potenzialmente. Può darsi. Ok, se si ripete qualcosa un po’ di volte e accadono cose inattese, allora si impara. Se ci si limita a fare e rifare sempre la stessa cosa, probabilmente si diventa più bravi a eseguire la sequenza, ma non si impara niente di nuovo. Pragmatic Programmer la descrive come la differenza tra dieci anni di esperienza rispetto all’esperienza ripetuta dieci volte.

L’apprendimento deriva dall’esperienza dell’inatteso, proprio come afferma il detto “Il giudizio viene dall’esperienza. L’esperienza viene dal giudizio sbagliato“. Quando si ottiene un risultato non familiare, si deve modificare il proprio modello del mondo per accogliere la nuova evidenza:in alternativa si può scartare il risultato come uno scherzo del destino e limitarsi a cercare dati di conferma; questo approccio si chiama confirmation bias, pregiudizio di conferma ed è un ottimo sistema per non imparare.

Nell’insegnamento Zen questo momento di illuminazione, di evoluzione del proprio modello del mondo, è chiamato satori e gli studenti Zen si sforzano di indurre i momenti di satori mediante i khan. Analogamente, il modello di Dreyfus delle conoscenze acquisite descrive come Principiante Avanzato qualcuno che che abbia iniziato a collocare le regole meccaniche nel proprio contesto e abbia compreso dove applicarle e dove non applicarle. Nuovamente, questo può accadere solo quando lo studente sperimenti esperienze che superino quel che gli sia già noto. Questo è il motivo per cui le Best Practice forzate artificialmente possano soffocare l’apprendimento.

Questo implica che lo studente possa accelerare il proprio apprendimento andando attivamente alla ricerca dello scontro laddove abbia desiderio di imparare. È questa la differenza tra scoperta accidentale e scoperta intenzionale.

Il vincolo è nell’apprendimento

Liz Keogh mi ha raccontato di un esperimento mentale del quale è venuta a conoscenza di recente. Pensa a un progetto o a una parte di lavoro significativo che il tuo team abbia completato, idealmente, nel corso di qualche mese. Quanto tempo è stato impiegato, dal principio alla consegna?
Bene: adesso immagina di dover eseguire nuovamente lo stesso identico progetto, con lo stesso team, gli stessi vincoli organizzativi, con tutto identico tranne per il fatto che il team abbia già tutte le conoscenze apprese durante il progetto. Quanto tempo sarebbe necessario, per rieseguire tutto da capo?
Fermati un secondo e prova a rifletterci.

Succede che le risposte più comuni siano dalla metà a un quarto del tempo per dover ripetere l’intero progetto. E questo porta alla conclusione che “il vincolo sia lo sforzo di apprendimento“.

Nota: Liz mi riferisce di aver saputo dell’esperimento da César Idrovo e che questo sia stato ideato da Ashley Johnson di Gemba Systems.

Se si assume che la sola differenza sia che nella seconda esecuzione sia sono acquisite delle conoscenze sul problema, questo dovrebbe suggerirci che il maggiore impedimento al rendimento era quel che non si conosceva. Cioè significa che tutto il tempo extra è stato speso nell’intensa attività di apprendimento.

Diamine, tutto questo non è solo divertente: è perfino utile!

In generale, probabilmente ti sarai trovato spesso ad annaspare nel cercare di trovare un modo di proseguire, o ti sarai trovato impantanato in riunioni in cui hai tentato di capire le priorità di altre persone per trovare il modo di superare qualche ostacolo, oppure a percorrere una strada in discesa che, inevitabilmente, si dimostrava essere un vicolo cieco (ah, se solo lo avessi saputo). Oppure, ti sarai certamente trovato a cercare di capire, per l’ennesima volta, come funzionino gli stupidi NIO socket di Java.

Quindi, il vincolo non è esattamente l’apprendimento: è ignoranza. Più precisamente, è l’ignoranza su aspetti specifici del problema sotto analisi. In altre parole:

L’ignoranza è il più grande impedimento alla produttività.

L’ignoranza multivariata

L’ignoranza agisce in più direzioni. Si può essere ignoranti su una particolare tecnologia utilizzata, ignoranti sulla vastità delle opzioni tecnologiche disponibili, ignoranti sul dominio, ignoranti sulle possibilità a disposizione per affrontare i problemi o sulle opportunità, ignoranti su un modo migliore per articolare il problema o su un miglior modello che renderebbe il problema ovvio, ignoranti sulle aspirazioni, le paure e le motivazioni delle persone del team, sulle relazioni che intercorrono tra di loro e tra loro e l’organizzazione, ignoranti sui vincoli dell’organizzazione, ignoranti sui rischi dell’integrazione di prodotti di terze parti, ignoranti sulle persone con le quali si dovrebbero costruire delle relazioni, ignoranti sulle metodologie di delivery, ignoranti sulla cultura aziendale. E qui sto solo sfiorando la superficie del problema: sono certo che non ti sia difficile immaginare molti altri fattori che potrebbero ostacolare la capacità produttiva e sui quali siamo più o meno ignoranti.

Più insidiosamente, ignoriamo quanto siamo ignoranti e questa ignoranza “di secondo livello“, piuttosto che renderci più cauti, ci induce ad una corsa folle proprio incontro al fallimento. Una citazione presa da una chat IRC di bash.org lo sintetizza meravigliosamente:

L’ignoranza ingenera confidenza più frequentemente di quanto ingeneri conoscenza – Charles Darwin

Che diamine! “ingeneri” non è italiano, smettila di inventare parole […seguono imprecazioni…]

La scoperta è non-lineare e incoerente

Adesso, ripensa al progetto che hai appena consegnato.

L’ignoranza è decresciuta costantemente e linearmente lungo tutti gli assi elencati sopra? È molto improbabile. Quel che è probabilmente successo, invece, è che in varie occasioni, alcune più memorabili di altre, hai avuto dei momenti di illuminazione e di consapevolezza, che sono sopraggiunti casualmente o sono stati indotti dalle circostanze esterne.

È possibile che molti di questi imprevisti momenti di apprendimento siano accaduti a fine giornata, accompagnati da molta incredulità, rabbia e, probabilmente, anche da vari altri stadi di malessere, come se si fosse dovuto accettare la disfatta del proprio solidissimo modello su Come Dovrebbero Funzionare Le Cose.

Per ognuno dei fattori, all’inizio dell progetto possedevi un particolare livello di ignoranza, e questo è decresciuto per salti, in modo indipendente in ogni episodio di apprendimento, fino a che al termine del progetto il livello si è trovato a una misura inferiore. Naturalmente, molti dei fattori sono in relazione tra loro, così che, in un singolo episodio, tu avrai avuto modo di imparare molte cose; e il tuo livello di ignoranza sarà decresciuto di una certa misura simultaneamente lungo diversi fattori simultaneamente.

Nella realtà, gran parte di questo momenti di apprendimento è gestito dai capricci degli dei ed è ampiamente fuori dal tuo controllo. Chi avrebbe mai scommesso che le API di quel tool di terze parti fossero così differenti rispetto a quanto dichiarato nelle specifiche? Chi avrebbe mai immaginato che la moglie di Dave avrebbe scelto proprio quel weekend per partorire?

Beh, in realtà avresti potuto eccome. Ok, non avresti potuto sapere che quelle cose sarebbero accadute, ma sarebbe insolito (per non dire anormale) negare che qualcosa sarebbe successo: e questo è il nodo cruciale del Deliberate Discovery.

Che accadrebbe se si assumesse che qualcosa di brutto accadrà di sicuro?

Noi possediamo un meccanismo innato di ottimismo scellerato. Viene chiamato pregiudizio di attribuzione e lo utilizziamo per proteggere il nostro fragile ego dalla grande, ingrata realtà che c’è là fuori. È un argomento trattato approfonditamente nell’affascinante libro A Mind of Its Own di Cordelia Fine, ma in sintesi, enuncia che quando accadono eventi spiacevoli alle persone, noi assumiamo che probabilmente se lo meritano perché hanno combinato qualche casino, o perché hanno deliberatamente trascurato il problema o per qualsiasi altro motivo. Tuttavia, quando gli eventi spiacevoli accadono a noi stessi, beh, allora è differente. Non potevamo avere modo di prevedere che sarebbero accaduti! Avrebbero potuto accadere a chiunque. Poveri noi!

Siamo affetti da pregiudizio di attribuzione quando facciamo delle stime (come Linda Rising ha notato) e quando valutiamo i rischi, e pertanto siamo costantemente stupiti – e, ammettiamolo, un po’ infastiditi – quando gli eventi spiacevoli accadono nei nostri progetti. Ecco un altro esperimento mentale: cosa accadrebbe se invece di sperare che niente di spiacevole accada assumessimo come un dato di fatto che:

molte (stabilire un numero) Brutte Cose Imprevedibili accadranno durante l’esecuzione del progetto. Non possiamo sapere in anticipo quali saranno: è proprio questo il significato di Imprevedibili. Le Cose Cattive comprometteranno la data di consegna: è proprio questo il significato di Brutte

In che modo cambierebbe l’approccio al proprio progetto?

Infine, la Scoperta Intenzionale

Ecco, io penso che abbiamo sempre cercato nel luogo sbagliato. Le metodologie, le pratiche e i pattern per stabilire la data di consegna sono cose buone e giuste, ma non tengono di conto del più grande vincolo al successo. Assumiamo per ipotesi che durante il ciclo di vita del progetto la nostra ignoranza si riduca lungo un certo numero di assi che risultano rilevanti per il progetto stesso. Assumiamo che l’attuale ignoranza su determinati fattori sia l’elemento che più ci limita. Assumiamo, infine, di non conoscere quali siano questi magici fattori: possediamo un'”ignoranza di secondo livello” su quali siano i fattori più limitanti. Una volta che comprenderemo quali siano questi fattori, potremo applicare una metodologia per superarli sistematicamente, ma fino a quel momento potremo solo andare alla cieca.

Certamente appare sensato investire nello sforzo di scoprire innanzi tutto su quali aspetti della consegna siamo più ignoranti (ovvero, il fatto che ignoriamo gli aspetti e, contemporaneamente, il fatto che ignoriamo come questi comprometteranno la data di consegna) e ancora di più appare sensato investire nel cercare di ridurre questa ignoranza – scoprendo deliberatamente e intenzionalmente abbastanza per liberarsi del vincolo e permetterci di proseguire. Durante tutto il progetto, giorno per giorno, dovremmo cercare di identificare dove e come l’ignoranza ci stia rallentando. Idealmente, vorremmo creare una discesa quanto più possibile ripida per la nostra ignoranza, su ognuno degli assi, così che intenzionalmente potessimo ridurre il grado di impedimento al quale l’ignoranza ci sta costringendo, piuttosto che restare vittime delle circostanze.

Per far questo ci vuole abilità, e come tale questa abilità è soggetta al modello di Dreyfus. Il che significa che, inizialmente, saremo molto scarsi. Poi inizieremo a comprendere quanto siamo scarsi e lavoreremo proprio su questo aspetto. Poi cominceremo ad adottare alcune Best Practice (mi spiace -. è inevitabile: è quello che le Persone Competenti fanno per “proteggere” i Principianti Avanzati) e, auguratamente poco dopo, troveremo il modo di sovvertire queste Best Practice per continuare a lavorare efficacemente. La parte più difficile sarà gestire il colpo al proprio ego non appena ci renderemo conto di quanto siamo sistematicamente inefficienti nei nostri impegni sui progetti, e di come siamo stati con lo sguardo imbambolato evitando di guardare il problema, perché la nostra metodologia è sempre sotto il lampione, ed è sotto il lampione che si siamo sempre sentiti a nostro agio.

Quali evoluzioni?

E questo ci riporta all’origine della mia premessa dell’anno scorso, e cioè al momento di iniziare un progetto, quando siamo più ignoranti sulla maggioranza degli aspetti del progetto, e al miglior uso che potremmo fare del nostro tempo dovrebbe essere quello di identificare e ridurre la nostra ignoranza lungo il maggior numero di assi ai quali potremo pensare. Indubbiamente uno dei primi esercizi dovrebbe essere quello di tentare di identificare questi assi e di cercare di comprendere quanto siamo ignoranti. Questo sì che è un esercizio di umiltà! Certo, se ci atteniamo strettamente al modello tradizionale di pianificazione Agile faremo delle scoperte non appena suddivideremo qualche epic in feature e queste in story e queste, infine, in scenario. Ma quanto potremmo realizzare di più se mettessimo tutto questo per un attimo da una parte e ci focalizziamo sulla vera difficoltà?

L’inventore del Domain Driven Design, Eric Evans, descrive l’analisi up-front come un “lucchetto sulla nostra ignoranza“. Beh, coglie nel segno, e quel che dice non è applicabile solo alla vecchia scuola dell’analisi dei requisiti. La morte per esercizio di pianificazione tramite story che ho visto in molti progetti agili è un testamento al medesimo problema The death-by-stories planning exercises I’ve seen on many Agile projects bear testament to the same problem.

Spero di aver reso l’idea di quali siano stati i miei pensieri. Ci sarebbe molto di più da dire sul deliberate discovery. Si pensi all’applicazione del principio al percorso di apprendimento di un nuovo linguaggio, o alla scelta di una nuova tecnologia, o ad un nuovo dominio. Cosa si potrebbe fare per identificare e ridurre la propria ignoranza più rapidamente? Perché i team che forniscono più rapidamente i feedback hanno più successo di quelli che procedono per cicli più lunghi? In che modo possiamo misurare l’ignoranza? Tornerò sull’argomento nelle prossime settimane e nei prossimi mesi, e parlerò di Deliberate Discovery al QCon di San Francisco a novembre.

I miei ringraziamenti vanno a Liz Keogh, Lindsay North, Joe Walnes, Chris Matts, Steve Hayes, Kevlin Henney e ai numerosi altri che mi hanno aiutato a maturare le idee per questo articolo. Un ringraziamento speciale va a Glenn Vanderburg e a Mike Nygard per la conversazione che abbiamo avuto al JAOO Australia sull’unità di ignoranza, che dovrà attendere un futuro articolo.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s