Come un backlog, non bello, porta dal conflitto alla collaborazione

In questo articolo, voglio raccontare un progetto a cui ho partecipato in qualità di Agile Coach – o consulente, se preferite. Un’esperienza che considero istruttiva perché ha richiesto numerose deviazioni rispetto agli schemi convenzionali, e ci ha costretto ad affrontare problemi non previsti, fuori standard.
Seguendo uno dei principi cardine dell’Agile – “Rispondere al cambiamento più che seguire un piano” – ci siamo ritrovati a costruire, passo dopo passo, un assetto operativo “sartoriale”, cucito addosso al contesto specifico. Perché, come diciamo spesso: soluzioni universali non esistono.

Prima però di arrivare ai dettagli, è importante capire il contesto.

Il contesto

Il cliente era una società finanziaria che aveva deciso di investire nella realizzazione di un prodotto software per coordinare le proprie attività, principalmente legate a prestiti personali e finanziamenti per acquisti in store.
Se descritto così può sembrare semplice, in realtà il dominio era piuttosto articolato, con molte dipendenze, regole di business, e integrazioni complesse.
Come spesso accade, la società si è affidata a più fornitori per sviluppare le diverse parti del progetto. Una scelta sensata dal punto di vista organizzativo tradizionale, che prevedeva:

• un fornitore per l’analisi funzionale,
• uno per lo sviluppo del software,
• uno per la piattaforma di credito,
• uno per la gestione documentale.

L’impostazione iniziale

Quando siamo stati coinvolti, il progetto era in chiusura della fase di analisi. Il modello di governance era quello classico: un piano di progetto, con avanzamento aggiornato ogni due settimane, milestone definite e deliverable concordati in partenza.
Nel frattempo, solo il fornitore dell’analisi stava effettivamente lavorando. Il team di sviluppo era coinvolto nei meeting di allineamento, ma attendeva la conclusione dell’analisi per iniziare i rilasci. La data di consegna era già fissata, basata sulle ipotesi concordate con tutti i fornitori.

La crisi del settimo mese

È proprio all’inizio della fase di sviluppo che si è verificata la prima frattura.
Il responsabile dell’azienda di sviluppo, leggendo a fondo i documenti di analisi, ha dichiarato senza mezzi termini che la data prevista non era realistica, e che il piano andava completamente rivisto. Il messaggio era chiaro (ma difficile da digerire): con queste premesse, non rispetteremo la scadenza.

Il caos è esploso.

Tutti i mesi di analisi sembravano inutili, e l’impressione era che si fosse lavorato su ipotesi ormai superate. La società finanziaria, nostra cliente, si è trovata disorientata: perché tante riunioni, tanto lavoro, se alla prova dei fatti mancava una base solida su cui costruire?
È partita una caccia al colpevole: incomprensioni, ambiguità contrattuali, responsabilità sfumate. Tutti cercavano di difendersi.
Inoltre, le continue riunioni invece di convergere diventavano ripetitive e frustranti. Le persone, anziché collaborare, si proteggevano.

Agile, in tutto questo?

A questo punto, la domanda era inevitabile: ma Agile che c’entra?
A prima vista, nulla. La situazione era quanto di più lontano da un ambiente collaborativo, trasparente, adattivo. La tentazione di fermarsi e dire “mettetevi d’accordo e poi ne riparliamo” era forte.
In teoria, un buon Agile Coach lavora per facilitare la scoperta di soluzioni da parte degli attori stessi. Ma qui il margine era ristretto: il nostro mandato ci autorizzava a lavorare quasi esclusivamente con il cliente finale, con pochissimo accesso diretto agli altri fornitori.
Una situazione tutt’altro che ideale.

Cercare una via d’uscita

Dovevamo comunque agire. Il primo passo è stato tornare a ciò che contava davvero per il cliente.
Due cose erano fondamentali:

• Portare avanti il progetto: fermarsi avrebbe significato vanificare mesi di investimento.
• Avere visibilità sulle scadenze: non era tanto una questione di rigidità, ma di trasparenza e affidabilità.

Il tema della roadmap era centrale. Il cliente era disposto anche a rinegoziare le date, ma voleva smettere di navigare a vista.

Trovare obiettivi comuni? Non ancora

La prima idea è stata cercare un terreno condiviso, un obiettivo comune su cui far convergere gli attori. Ma cosa significa davvero “successo del progetto”? Dipende da chi lo definisce.
La verità è che, in quel momento, parlare di obiettivi comuni era prematuro. Prima bisognava ristabilire un minimo di dialogo.
Così ho messo da parte gli obiettivi comuni, mi sono concentrato sul contesto reale, cercando iniziative che rispondessero ai bisogni concreti del cliente: andare avanti con il progetto, avere un’idea affidabile di roadmap, con date di consegna attendibili, per quanto flessibili.

Occorreva pertanto trovare un meccanismo che:

• riconoscesse lo sforzo di analisi già fatto;
• valorizzasse le attività tecniche preparatorie;
• portasse il linguaggio degli incontri a un livello comprensibile a tutte le parti (senza gerghi tecnici/funzionali laddove possibile);
• riducesse la complessità del tutto.

E, in tutto questo, occorreva salvaguardare le persone, perché, anche se magari a loro non era chiaro, a me cominciava a risultare abbastanza evidente che, alla fine, tutti stavano cercando di fare il loro lavoro bene. Anche se adesso litigavano. Nessuno stava sabotando deliberatamente il progetto: non era quello il problema. Il tema era diverso, ma di fatto le persone avevano smesso di parlarsi.

Le soluzioni (im)possibili

Ho provato a ragionare su alternative più “agili”:

• Creare un team cross-funzionale? Ideale, ma impraticabile con aziende diverse e contratti rigidi.
• Promuovere l’empatia? Ottimo, ma richiede dialogo. E lì mancava anche quello.

Serviva una terza via.

L’idea fuori dagli schemi

Alla fine, mi è venuta in mente un’ipotesi alternativa. Forse anche un po’ brutale: introdurre un nemico comune.
Nella storia, le persone si uniscono più facilmente contro una minaccia che per un obiettivo astratto. L’idea non era quella di trovare un colpevole, ma un bersaglio simbolico su cui concentrare le energie.

Quel nemico è diventato un Product Backlog.

Non uno ben fatto. Anzi, volutamente imperfetto, caotico, incompleto. Ma visibile, commentabile, migliorabile. Un “oggetto di scontro” positivo, che ha stimolato il confronto e reindirizzato le energie. Il dialogo, prima fermo, ha ripreso.
Per introdurlo, l’ho presentato come una naturale evoluzione del percorso Agile richiesto dal cliente stesso: “Da oggi si lavora su questo.” L’Agile, in questo caso, c’entrava eccome. Siamo partiti da una mappatura delle funzionalità, abbiamo generato un primo backlog, fatto stime, proposto una prima roadmap e iniziato a tracciare il progresso con un burn down chart.
Tra tutti gli artefatti, il Product Backlog è quello da cui non si può prescindere. Ed è diventato, volutamente, il bersaglio perfetto.

La genesi del backlog

L’analisi funzionale esisteva: centinaia di pagine, anche dettagliate. Buttarla via avrebbe significato ignorare mesi di lavoro da parte di uno dei fornitori, generando attriti inutili. Ma prenderla come unica fonte sarebbe stato altrettanto dannoso: avrebbe scontentato chi non era stato coinvolto nella sua stesura.
La soluzione? Prendere tutto e farlo diventare qualcosa di contestabile. Un backlog così imperfetto da attirare critiche. Da lì sarebbe potuta partire una nuova forma di collaborazione.

Per costruire questo artefatto, ho utilizzato un generatore AI che, in circa tre ore, ha prodotto 480 User Stories. Ovviamente, il risultato era grezzo, incoerente, sovrabbondante. E proprio per questo adatto allo scopo.
Ho poi proposto un esperimento: due giorni di User Story Mapping, coinvolgendo tutti gli attori. Ho negoziato con i responsabili delle varie aziende per ottenere il supporto. E, sorprendentemente, tutti hanno accettato.
Il nuovo processo partiva da basi familiari (le analisi funzionali), ignorava per il momento le scadenze (cosa gradita ai tecnici), e spostava il focus dai documenti alla conversazione. Questo ha reso possibile il coinvolgimento.

Risultato dello User Story Mapping

Tutti i responsabili hanno voluto partecipare, seppur da remoto. 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.

Le prime reazioni: il backlog sotto attacco

Come previsto, il backlog è stato subito criticato. Alcune storie erano vaghe, altre ridondanti, molte scritte male. Ma è esattamente quello che volevo: un bersaglio comune.
Così, le persone hanno smesso di attaccarsi tra loro e hanno iniziato a migliorare il backlog. Hanno individuato storie duplicate, analisi contraddittorie, requisiti non chiari. Ma invece di cercare i colpevoli, cercavano soluzioni.

Le stime: un altro catalizzatore

Un altro passaggio chiave è stato l’inizio delle stime. Anche solo una prima suddivisione tra alta e bassa complessità, espressa in story point, ha dato una forma più concreta al lavoro. È diverso leggere “alta complessità” in un documento e vedere un “8” su una story.
Le prime stime non erano perfette, certo. Ma già il solo fatto di cominciare a dare una valutazione in story points, con riferimento alla complessità, ha reso le cose più tangibili.
Vedere una user story con una stima alta ha un impatto diverso rispetto a leggere la stessa informazione sepolta dentro un documento. Era l’inizio di una roadmap concreta.

Finalmente il dialogo

Il risultato più importante? Le persone hanno ricominciato a parlarsi.
Non c’erano più frasi vaghe, né gergo tecnico difensivo. C’era un oggetto concreto – il backlog – su cui ragionare insieme. Lo story mapping è stato presentato non come una nuova metodologia da adottare per sempre, ma come un esperimento: “Concedetemi due giorni di fiducia.”
Il fatto che tutti i responsabili, pur da remoto, abbiano partecipato, ha dato al processo un’importanza percepita superiore. Ha segnato una svolta.

Il cliente, ovviamente, cominciava a chiedere date. Inizialmente abbiamo chiesto pazienza: serviva raccogliere dati. Ma dopo circa un mese, siamo riusciti a proporre le prime previsioni e un Burn Down Chart con dati realistici passando a una visione trasparente sul numero di story points per sprint, la visibilità su cosa era incluso o escluso e lo stato aggiornato del lavoro.

Un backlog utile (anche se nato brutto)

Quel backlog, inizialmente caotico, ha creato chiarezza. È stato raffinato sprint dopo sprint. Ha rivelato anche elementi nuovi: funzionalità non previste in fase di analisi, bisogni non ancora emersi. Questa scoperta ci ha portato a una riflessione più profonda: il progetto era più ampio di quanto previsto. I moduli “monofornitore” non bastavano. I workaround iniziavano ad accumularsi, rendendo il prodotto troppo custom, poco manutenibile.
C’era addirittura l’ipotesi di fermarsi, rivedere tutto. Ma questo è un altro capitolo.

Il paradosso è chiaro: più il backlog è migliorato, più sono emersi i limiti strutturali del progetto.
Eppure, quel backlog – brutto, goffo, criticato – è servito a rimettere in moto le persone. A farle parlare. A creare un metodo visibile, condiviso, trasparente.

Non è questo, in fondo, il primo obiettivo dell’Agile?

Risorse
Articolo originale su Mokabyte di Pino Decandia
Foto di copertina di Jason Goodman su Unsplash