Introduzione

In questi due articoli, vorrei raccontare quel che è accaduto nel corso di un progetto al quale ho preso parte in qualità di Agile Coach, o di “consulente” se volete, e che ha rappresentato un episodio secondo me abbastanza istruttivo perché ha comportato una serie di “deviazioni” dagli standard.

Assecondando una delle massime più citate in ambito Agile, ossia “Rispondere al cambiamento più che seguire un piano prestabilito”, è stato necessario arrivare a un assetto funzionante attraverso parecchie deviazioni rispetto a quel che inizialmente era stato previsto dagli attori in gioco. Si è trattato di un lavoro “sartoriale”: del resto, lo ripetiamo sempre, nel nostro campo la soluzione pronta all’uso e adatta per tutti non esiste.

Ma prima di vedere che cosa è successo, cerchiamo di descrivere il contesto.

Il contesto

Il cliente che ci ha contattato è una società finanziaria: ha investito nella creazione di un prodotto software che gli consentisse di esercitare in maniera coordinata le proprie attività. Nel loro caso si tratta di prestiti personali e finanziamenti per l’acquisto presso negozi: detto così potrebbe apparentemente sembrare semplice, ma ci sono invece tutte le complicazioni relative.

Terze parti

Come succede spesso, e per motivi di struttura, la società finanziaria, che poi ci ha contattato per seguire il progetto, si è affidata a terze parti per l’esecuzione di sezioni del lavoro; queste suddivisioni del lavoro erano state pensate in maniera assolutamente sensata, almeno in un’ottica “tradizionale”.

Quindi la situazione prevedeva che ci fosse

• un fornitore per l’analisi funzionale;
• un fornitore per lo sviluppo software;
• un fornitore per la piattaforma di credito;
• un fornitore per il documentale.

Ad ognuna delle società era stata richiesta una valutazione preliminare su requisiti di alto livello e, subito dopo, un’offerta “a corpo” sulla base della comprensione di quello che c’era da fare.

La gestione del progetto

Quando siamo arrivati noi in qualità di “esperti di Agile”, il progetto era alla fine della fase di analisi e prevedeva un meccanismo di governance standard: un piano di progetto, aggiornato con intervalli di due settimane con lo stadio di avanzamento.

Fino a questo punto, l’unico fornitore che effettivamente stava lavorando era quello incaricato dell’’analisi funzionale e tecnica. Il fornitore di sviluppo partecipava a meeting di allineamento su base regolare, ma non aveva cominciato a rilasciare software funzionante, in attesa della conclusione della fase di analisi. Era anche stata stabilita una data di consegna, sulla base delle ipotesi di durata delle varie fasi stabilite dai diversi fornitori per quel che atteneva alla parte di loro competenza.

La crisi del settimo… mese

Subito dopo il nostro arrivo, quando abbiamo cominciato a lavorare davvero a questa situazione, eravamo esattamente alla fine dell’analisi funzionale e dunque abbiamo assistito direttamente alla prima settimana di inizio dello sviluppo. O meglio, siamo stati testimoni del fatto che il responsabile dell’azienda di sviluppo, aveva cominciato a leggere approfonditamente di documenti di analisi funzionale. E della sua reazione: dichiarare che la data proposta per la consegna del prodotto finito non aveva senso e che il piano andava rivisto. Di fatto, gli sviluppatori stavano mandando un messaggio chiaro ma poco digerible: con queste premesse, non consegneremo nei tempi da voi previsti.

Chiaramente questa presa di posizione creava scompiglio: i sette-otto mesi di analisi sembravano persi, il team tecnico dichiarava che, ora che iniziava lo sviluppi, l’analisi non rispecchiava lo stato delle cose da fare.

Da parte sua, l’azienda principale, la finanziaria che ci aveva coinvolto e che, in ultima istanza, era il nostro cliente, si interrogava sul senso di aver fatto delle riunioni in precedenza, i vari attori cercavano di capire di chi fosse la responsabilità per questo grosso intoppo e si puntava il dito sulle possibili incomprensioni.

La litania delle riunioni

Ma occorreva trovare una via d’uscita. E il nostro cliente ha reagito con una serie di iniziative: riunioni da cui dovevano uscire azioni immediata, coinvolgimento di tutti gli attori già presenti nel progetto e anche di altri esterni, in una progressiva escalation.

Inutile dire che le varie riunioni erano diventate tese e ripetitive: invece di cercare soluzioni pratiche, si assisteva a un rimpallo di responsabilità, ad accuse neanche tanto velate, a una vera e propria litania di frasi tipiche di queste situazioni:

“L’analisi non è chiara”

“No, l’analisi è chiarissima, siete voi che non la capite”

“Questa cosa però non l’avevate detta”

“Ma il contratto è chiaro”

“No, su questo il contratto non è chiaro per niente”

“Questa è una change request”

“È che non siete adeguati, non avete il team adatto”

“Sì, comunque dobbiamo passare a RedShift”

“Che roba è RedShift?”

“…”

“Di chi è la colpa?”

Fatalmente le persone mostravano una crisi di fiducia reciproca. Era iniziata la corsa alla protezione.

Cosa c’entra Agile

A questo punto, i lettori si staranno chiedendo: “Sì, ma in tutto questo, cosa c’entra Agile?”.

Niente.

Almeno a prima vista. Perché le dinamiche erano lontanissime da quelle necessarie per uno sviluppo con approccio agile. Non nego che era molto forte la tentazione di dire: “Prima finite di litigare e mettetevi d’accordo almeno sulle basi… e poi cominceremo a lavorare insieme…”

Il buon coach agile, in queste situazioni, dovrebbe puntare a far emergere le soluzioni più adatte al contesto direttamente dagli attori coinvolti più che proporre dall’alto cosa fare e non fare. Ma, in questo caso, agire in questo modo era abbastanza difficile, visto che avevamo un mandato abbastanza “confinato”: lavorare principalmente sull’azienda finanziaria, e poter agire sono in misura molto ridotta sugli altri attori, cioè i fornitori dell’azienda principale. Non era una situazione ottimale.

Strategia per uscirne

Di fatto, ero lì e dovevamo fare qualcosa. Trovare una strategia per uscire dall’impasse, o perlomeno una serie di azioni che potessero riportare i partecipanti a concentrarsi sul prodotto da realizzare, più che stare a dibattere indefinitamente su eventuali “colpevoli” o sul punto in cui il meccanismo si era inceppato.

Visto che il nostro referente fondamentale era il nostro cliente, l’azienda finanziaria, abbiamo cercato di capire cosa desiderasse veramente il cliente. E il cliente voleva sostanzialmente due cose:

Primo: il progetto doveva andare avanti. Non era possibile interromperlo e annullarlo, perché c’erano degli investimenti di un certo tipo che l’azienda non poteva permettersi di far fallire.

Secondo: voleva una chiarezza sulla data di consegna. Perlomeno, non voleva scoprire a un punto avanzato del progetto che le date ipotizzate non sarebbero state rispettate. Questo era comprensibile, perché è un desiderio che tutti hanno. Occorreva capire in che modo “formulare” quella data. Alla fine, non erano neanche così rigidi sulle date, che diventavano “trattabli”, ma volevano avere sicuramente maggiore chiarezza sulla roadmap.

Obiettivi comuni

La prima idea che ho avuto, sperando che potesse contribuire a rimettere il progetto nella giusta direzione, è stata quella di individuare dei possibili obiettivi comuni su cui focalizzarsi e che avrebbero avuto la forza di tenere insieme le persone, orientandole verso un’interazione collaborativa ed efficace.

In teoria, sembrava un’ottima idea. Ma quali erano questi obiettivi comuni? La buona riuscita del progetto? Ma che significa “buona riuscita”? Per le diverse parti in causa poteva addirittura avere significati che nei fatti si dimostravano contrastanti.

Il sucesso sul mercato di questa iniziativa poteva apparire un obiettivo più concreto e “unificante”: ma come lo avremmo misurato nell’immediato, visto che era qualcosa di lontano nel tempo?

In più ognuno aveva proposto e sottoscritto un contratto “a corpo”, modalità che minava il ragionamento.

Di fatto, gli obiettivi comuni delle varie parti del progetto non erano comuni per niente: le persone intanto continuavano a litigare e questo mi ha definitivamente convinto che parlare di obiettivi comuni era prematuro e inutile finché gli animi non si fossero calmati.

Immersione nella realtà

Messi da parte gli obiettivi comuni, ho fatto una valutazione generale del quadro, sperando che dalla realtà dei fatti emergessero quelle iniziative che potessero corrispondere ai desideri del cliente: andare avanti con il progetto e 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.

Per andare un po’ più a fondo, se vogliamo individuare il problema, questo era in parte nel meccanismo di organizzazione del progetto e di scelta dei fornitori da parte dell’azienda finanziaria. Che, sia chiaro, aveva agito in perfetta buona fede, ma replicando un meccanismo che aveva funzionato in altre occasioni, per esempio nell’ambito della gestione finanziaria: analizzo le necessità, individuo chi o cosa meglio risponde a queste necessità, guardo al mercato e acquisto i “pacchetti”, i “moduli” che si domostrano migliori. Li combino e funzionano. Ed è quello che era stato fatto in questa occasione: scelgo chi è bravo a fare l’analisi funzionale, chi sa sviluppare bene software, faccio un contratto con chi cura il documentale e tutto fuzionerà a dovere. Ma nei sistemi complessi non va esattamente così.

Quindi bisogna dire chiaramente che nessuno stava sabotando deliberatamente il progetto: non era quello il problema. Il tema era diverso, ma di fatto le persone avevano smesso di parlarsi.

Ipotesi alternative

Ho provato quindi a ipotizzare altre soluzioni: cosa si poteva fare per prendere un gruppo di persone e “costringerle” in qualche modo a guardare tutte in una stessa direzione?

Fare un team cross funzionale? Ideale in termini agili, ma nel concreto impossibile in questa situazione, con aziende diverse che, anche per motivi contrattuali, non erano molto disponibili.

Fare in modo che le persone si mettessero una nei panni dell’altra? Sempre giusto, ma sarebbe stato necessario anzitutto che si parlassero. E, sempre per i motivi di suddivisione dei compiti non solo fra persone diverse, ma fra persone di diverse aziende, la cosa era abbastanza improponibile.

La soluzione non convenzionale

Scartate le ipotesi appena elencate, ho provato comunque a vedere se esistessero alcuni artifacts agili che in grado di aiutare. Ed è qui che mi è venuta in mente un’idea, che lì per lì ho anche valutato come orribile, ma che in questa peculiare situazione poteva avere un senso.

In definitiva, era necessario che le persone iniziassero a concentrarsi su qualcosa di diverso rispetto a quello che era stato fatto fino a quel momento, pur salvaguardando e riconoscendo gli sforzi di ognuno.

Qual è il modo più rapido, e anche effimero, di spingere le persone a unirsi e a comportarsi in maniera coesa, lasciando alle spalle divisioni e incomprensioni?

È qualcosa che, nella storia delle vicende umane, si è visto tante volte e che, nelle nostre società postmoderne, ancora continua a funzionare: creare un nemico comune. Esattamente: percepire qualcosa come minaccia da combattere avrebbe spinto le persone a concentrarsi su quello e a superare conflitti e divisioni. Non si trattava propriamente di un obiettvo comune, quanto piuttosto, appunto, di un nemico comune. Un bel diversivo: qualcosa che costringesse le persone delle varie aziende a parlare di questo nemico e di come sconfiggerlo.

La mia speranza era che poi, piano piano, parlando tra di loro di un nemico comune, alla fine le persone si accorgessero che dall’altra parte c’erano altre persone che fanno il loro lavoro cercando di dare il meglio, e questo avrebbe contribuito a disinnescare le tensioni.

Ovviamente, però, il nemico non doveva essere un’azienda o, peggio ancora, una persona, ma doveva essere qualcosa di più effimero.

E qui, invece, l’Agile c’entra, perché il candidato più adatto a ricoprire il ruolo di “nemico comune” era un bel Product Backlog. Anzi, un brutto, quasi orribile, Backlog. Un “irraggiatore di informazioni” su cui i diversi attori avrebbero potuto concentrarsi.

Conclusioni

Ma di come si è comportato il nostro “nemico comune”, ossia di come questo specifico backlog-non-tanto-buono è stato creato, di come è stato proposto e degli effetti che ha sortito sull’andamento del progetto parleremo nella seconda parte, concludendo il nostro racconto.