Breve ricapitolazione

La situazione è complessa, ma il quadro è chiaro. Un progetto: una società finanziaria deve realizzare un prodotto software e si affida a terze parti per l’esecuzione di sezioni del lavoro: fornitori diversi rispettivamente per l’analisi funzionale, per lo sviluppo software, per la piattaforma di credito e per il documentale.

Nel momento in cui si passa dall’analisi funzionale alle attività successive, emergono problemi, incomprensioni, accuse reciproche, e ci si aggrappa in maniera ossessiva ai contratti stipulati in precedenza. La blaming culture ha sicuramente il sopravvento sulla necessaria capacità di collaborazione.

Dobbiamo interventire come Agile Coach, o consulenti, se preferite, pur ricordando che tra le due figure c’è un approccio piuttosto differente.

Dopo aver valutato varie possibilità, abbiamo deciso di percorrere una strada decisamente anticonvenzionale, basata però su uno degli strumenti fondamentali della produzione intesa in senso Agile: il Product Backlog. Solo che inizialmente non lo abbiamo presentato come soluzione, ma come “nemico” comune intorno al quale coalizzare le energie dei diversi “contenndenti”.

Nemico comune

E quindi, per i motivi esposti nel precedente articolo e brevemente ricapitolati qui sopra, ho deciso di intervenire in maniera più “rettile”, nella speranza che anche in questo caso funzionasse quel meccanismo un po’ subdolo del “nemico comune”. Questo comune nemico era un backlog orribile.

Per farlo accettare inizialmente: ho presentato il Product Backlog come il cambiamento agile voluto dal cliente per cui le varie parti stavano lavorando. “D’ora in poi lavoreremo su questo!”.

E qui l’agile c’entra eccome. Possiamo partire da una mappatura delle funzionalità; poi creare un primo backlog; stimare nella modalità che pensiamo essere più utile; ipotizzare una data; monitorare l’andamento con un burn down chart. E in questo modo, per quanto in maniera non ossessivamente precisa, abbiamo però tracciato una strada, una roadmap appunto da seguire.

Di tutti queste attività e artifacts l’unica da cui veramente non si può proprio scappare è proprio il Product Backlog, che quindi è diventato il candidato principale a rappresentare “il nemico”.

Sono partito da due considerazioni: da un lato, l’analisi funzionale c’era — centinaia di pagine, anche molto tecniche — e non si poteva buttare via, un po’ perché comunque conteneva delle informazioni interessanti, un po’ perché era lavoro fatto da una delle terze parti e buttarlo via avrebbe creato tensioni da parte di chi ci aveva messo l’impegno di tanti mesi. Dall’altro lato, però, non si poteva neanche prendere l’analisi funzionale come unico punto di partenza, perché, in questo caso, le tensioni sarebbero nate da parte delle altre parti: “Quando hanno scritto questo, non ci hanno neanche interpellato!”; “Ma con che criterio hanno fatto questo ragionamento?”; “Chi è che non capisce, in questo caso?”, e così via.

Se tutti hanno da ridire…

… forse è bene lasciarli fare. Ho pensato allora che, se avessi creato un backlog brutto, orrendo, probabilmente le persone si sarebbero scagliate contro di esso e, di conseguenza, di concentrarsi  su di esso. Vista la situazione, si poteva rischiare. Proviamoci.

Approccio in linea con la strategia?

Vediamo come sono arrivato a questo Product Backlog. Non è propriamente la modalità del buon Product Owner, ma insomma, le premesse e le finalità ora le sapete…

Strumenti automatici

Ho generato circa 480 User Stories con l’intelligenza artificiale in circa 3 ore di lavoro. Com’era il backlog? Terribile, ovviamente. Ma sappiamo perché.

Cambio di processo

Ho chiesto alle persone delle diverse parti di investire due giorni per la sperimentazione di un nuovo processo:  lo User Story Mapping. Ho parlato con i responsabili di tutte le persone coinvolte per ottenere il sostegno all’esperimento. A questo punto, abbiamo tracciato tutto e iniziato a lavorare in modalità Scrum-like.

Perchè le persone ci hanno lavorato volentieri?

• Perchè partiva dalle analisi funzionali già fatte (analisti funzionali a bordo).
• Perché onsiderava le date di scadenza come inutili per il momento (tecnici a bordo).
• Perché introduceva il concetto per cui, d’ora in poi, più che i documenti dovesse essere centrale la conversazione tra le parti.

Lo story mapping

Tutti i responsabili hanno voluto partecipare, seppur da remoto, ed è stato un pò come essere in un’acquario: i vari responsabili volevano essere lì e toccare con mano le differenza.

Ma quali sono stati i risultati del processo di User Story Mapping? Vediamoli di seguito.

• Da ca. 800 pagine di analisi funzionale e un centinaio di analisi architetturale si è passati a circa 480 user stories.
• Da una stima “a corpo”, non legata alla realtà, si è arrivati a una stima rivista ad ogni sprint e basata sul delivery, quindi più realistica e aggiornata.

Discorsi intorno al backlog brutto

Ecco quindi che ci siamo ritrovati con un backlog brutto. Del resto, ve l’ho detto, le storie erano state gnerate con l’Intelligenza Artificiale e raffinate in maniera abbastanza grossolana: “Come operatore di rischio voglio fare l’override in decisioni automatiche se necessario, in modo tale che le discrepanze possano essere gestite in maniera appropriata”. Eh, va be’… È chiaro. Ma una cosa del genere, se un po’ ampliata, corrisponde a “Come essere umano, voglio la pace nel mondo, in modo che tutte le persone possano vivere senza i pericoli della guerra”. E di User Stories che “chiedevano la pace nel mondo” ce ne erano parecchie…

Nei due giorni dello Story Mapping, questi aspetti sono emersi: le critiche al backlog non sono mancate. Il nemico cominciava ad attrarre l’attenzione delle varie parti.

Qualche esempio di conversazione

Pian piano, dalla concentrazione sulle colpe — o presunte tali — delle varie controparti, le persone hanno cominciato a spostare il discorso verso le mancanze e le discrepanze del backlog. Che rimaneva per ora un nemico da criticare: il piano, quindi, funzionava.

Il fatto è che poi si è passati a cercare di migliorare il backlog, a volerlo rendere utile e funzionale. Ci i rendeva conto, ad esempio che c’erano delle storie utenti sostanzialmente uguali, e che quindi se ne poteva togliere una.

In diversi casi sono stati trovati requisiti con un titolo uguale e due analisi funzionali diverse: ma a questo punto, le persone si concentravano sul problema e sul trovargli una possibile soluzione, non sul biasimare chi aveva scritto l’analisi.

Altro aspetto interessante: tutto quanto veniva fatto in inglese, per motivi ancora non chiari. I titoli della documentazione erano in inglese, ad esempio. Ma sappiamo bene che un non-native speaker, un italiano ad esempio, spesso utilizza tale lingua in maniera non del tutto appropriata. Un limite al vocabolario, ad esempio, faceva sì che per dire che un argomento veniva affrontato in un altro capitolo, si usasse sempre solo il verbo tackle. E questo, paradossalmente è diventato utile perché, cercando tale parola, abbiamo potuto ricostruire le relazioni tra un argomento e un altro. Ma le abbiamo indicate non più con un verbo, bensì con una linea che indicasse appunto la relazione.

Stime

Un altro aspetto che ha avuto il suo ruolo è stato quello delle stime. Abbiamo cominciato a fare un po’ di stime: la stima classica, fatta per punti, fatta sulla base di una comprensione neanche troppo approfondita di cosa voleva dire “bassa complessità” e cosa voleva dire “alta complessità”. E anche questo è stato un passo avanti verso la nostra roadmap, perché un conto è trovare scritto nell’analisi funzionale che ci sono degli elementi ad alta complessità, un conto è vederlo espresso in punti, sulla storia stessa.

Collaborazione

Ma la cosa più importante è stata che, quasi senza accorgersene, le parti hanno cominciato a parlarsi. Il gergo è stato cancellato, ovviamente, perché la ragione sulla storia è funzionale. Avevamo lo story mapping e, per evitare di parlare di obiettivi comuni, l’ho venduta come “facciamo l’esperimento: credete in me per due giorni”. Anche il fatto che, seppur da remoto, fossero presenti i vari responsabili delle diverse aziende fornitrici, era importante in chiave di partecipazione collaborativa.

Chiaramente, a questo punto l’azienda principale, la finanziaria che era il nostro cliente, iniziava a spingere per cominciare ad avere delle date, delle idee sui rilasci. Inizialmente potevamo solo dire: “Abbiate pazienza, stiamo ancora raccogliendo i dati”, ma poi dopo un mese abbondante dallo story mapping, abbiamo cominciato a vedere le cose più chiaramente e quindi anche a essere in grado di pensare a un Burn Down Chart.

Il valore di un Product Backlog (anche brutto…)

Siamo riusciti a passare da una vista progettuale pura, di cui non si capiva esattamente che cosa succedeva, a una vista che consentiva una trasparenza totale: numero di story point, quanti per sprint, che cosa facciamo, cosa è dentro, cosa è fuori. A dire il vero, questa trasparenza, questa collaborazione è stata abbastanza inaspettata: il backlog, inizialmente accolto come punto di critica comune, in tempi relativamente brevi è diventato uno strumento utile di chiarimento. Ed è anche nettamente migliorato: non era più così brutto, ma diventava sempre più ordinato e raffinato, sprint dopo sprint.

Ed è stato anche uno strumento di scoperta, perché avendo davanti il backlog, si intravvedevano, ad esempio, delle parti del prodotto che mancavano, che non erano state pensate in fase di analisi. Infatti si è capito che il progetto era cresciuto oltre le aspettative.

Questo ha portato anche all’attuale fase di “ripensamento” dell’intero progetto: è parecchio più grosso delle attese e la scelta iniziale di queste terze parti, i “monomoduli”, non è risultata vincente. I workaround sul codice stanno creando un prodotto “custom” con ovvie ripercussioni sulla standardizzazione e alla manutenibilità. E quindi c’è l’idea di fermare il progetto.

Quindi, paradossalmente, più il backlog è diventato buono, più si sono evidenziati tutti i limiti e problemi di questo progetto.

Però, alla fine, il backlog è comunque servito per riattivare la comunicazione e far ricominciare le persone a parlare civilmente tra loro; è servito a far avere a tutti un un metodo condiviso, grazie al quale organizzarsi in maniera visibile e trasparente.