Agile goes to Hollywood

II parte: Il tema del valoredi

Il tema del valore e la sua misurazione

La volta scorsa abbiamo intrapreso la nostra riflessione presentando alcuni comportamenti che osserviamo all’interno delle grandi organizzazioni che stanno cercando di introdurre l’agilità. In questa seconda parte della serie Agile goes to hollywood vorremmo parlare di valore e di organizzazioni con fornitori esterni.

Produrre valore

In alcuni ambiti, frasi come “produrre valore”, “creare valore” sono diventate quasi scontate: in certi casi le si ripete più per sentito dire che per reale comprensione del significato che c’è alla base. In realtà, questo tema del valore è cruciale nel pensiero di matrice Lean, ed è un concetto “industriale” che precede di svariati decenni l’affermazione del paradigma Agile nello sviluppo software: in sostanza, non stiamo parlando di “fuffa” ma di un concetto importante riassume i motivi di successo di colossi industriali a livello internazionale.

Nel fare project management, spesso si limita l’attenzione a temi come stime, pianificazione, costi, contratti. Ma il progetto e la sua gestione sono lo strumento con il quale si produce qualcosa. In Agile qualità vuol dire soddisfazione utente, il che si traduce appunto nel produrre valore. Il tema del valore è un argomento scottante: quasi mai lo si considera, raramente si misura il valore prodotto.

Rilasciare valore per l’utente finale non è solo mettere in fila un elenco di funzionalità da implementare. Purtroppo, raramente vediamo Product Owner che si preoccupano di andare oltre, per esempio facendo comparazioni fra soluzioni differenti, o misurando la UX in modo da valutare il grado di soddisfazione dell’utente, o progettando soluzioni alternative, o coinvolgendo il cliente per rimettere in discussione il backlog delle funzionalità da implementare.

Non è raro trovare situazioni del tipo: “Mi è stato assegnato il compito di gestire un progetto con questo budget e questa scadenza”. Personalmente vorrei abolire il verbo “gestire” quando usato senza spiegazioni ulteriori: spesso infatti mancano quei fondamentali momenti in cui ci si chiede “Perché facciamo questo progetto? A chi serve? Che bisogno risolve?”. Nelle grandi aziende, spesso la gestione di progetto finalizzata al progetto finisce per sostituire la consapevolezza di volere/dovere realizzare un prodotto/servizio in grado di apportare valore all’utente/cliente che ne ha necessità.

 

Il tema del modello di miglioramento continuo

In ogni azienda che “fa Agile” — ma anche nelle altre — troviamo team di persone che sviluppano prodotti. Spesso, specialmente nelle grandi aziende, i team sono composti (anche) da fornitori esterni ingaggiati con il tipico “approccio da fornitore”. Capita che per questo motivo spesso i team non siano stabili, o che cambino poi i fornitori a fine progetto. Spesso le stesse persone interne all’organizzazione non sono stabili sul progetto o addirittura sui ruoli, nel senso che chi svolge il ruolo del Product Owner su un progetto, lo fa in modo estemporaneo, senza continuità sui progetti successivi, cosa che gli permetterebbe di imparare e crescere nel suo ruolo.

Stabilità e miglioramento

Questo scenario, in cui le persone cambiano continuamente e in cui non c’è continuità fra chi sviluppa un prodotto, chi dovrà rilasciarlo in produzione e chi poi dovrà farne manutenzione, è molto difficile, se non impossibile, sia lavorare sul miglioramento continuo delle persone e della qualità rilasciata, sia focalizzare il proprio lavoro sul valore rilasciato: come possiamo infatti misurare il valore del prodotto se, una volta finito il progetto, il prodotto esce dalla sfera di competenza del team di lavoro?

È quindi importante trovare un modo per creare un contesto stabile che permetta di lavorare sul miglioramento del team, dei ruoli, del valore prodotto. Questo non vuol dire abolire l’uso di fornitori esterni, “blindare” le persone all’interno di un team, oppure vincolare la carriera di una persona a un ruolo che gli venga “attaccato” in modo statico.

Stiamo invece dicendo di uscire dal circolo vizioso si svolge secondo un tipico percorso:

  • parte dal “non abbiamo team stabili”;
  • passa al “non riusciamo a creare un differente rapporto di collaborazione con i nostri fornitori”;
  • converge sul “non abbiamo percorsi di carriera per i PO”;
  • ritorna al “non riusciamo ad avere team stabili che possano seguire il progetto in tutta la sua evoluzione”.

Stimoliamo invece a trovare soluzioni compatibili con la cultura e il modello organizzativo presenti all’interno della vostra azienda, che si stacchino comunque da questo circolo vizioso.

Dal progetto al prodotto

Tanto per fare un esempio, potremmo citare un esperimento che stiamo seguendo all’interno di una grande azienda. In questo caso, ci siamo trovati a lavorare su progetti seguiti da team che poi sistematicamente venivano “smantellatia fine progetto.

In questo caso ci siamo chiesti come avremmo potuto abilitare un processo di verifica della qualità del prodotto una volta che questo fosse stato rilasciato in produzione, visto che in quella fase il team non sarebbe stato più fisicamente disponibile (p.e., 6 mesi dopo il rilascio). Per affrontare questo tema siamo partiti dal pensare cosa sia un progetto di sviluppo: persone che realizzano un prodotto.

Se le persone si sganciano a fine progetto o cambiano, cosa resta? Un prodotto… Un primo passo verso il miglioramento continuo potrebbe essere quindi quello di iniziare a parlare di product management: il prodotto ha una sua vita che deve essere seguita, osservata, guidata anche quando il progetto finisce.

Perché spesso è così difficile seguire la vita del prodotto oltre il momento del rilascio? Non solo: perché pensiamo che sia così difficile farlo? Perché manca un approccio sistemico alla produzione del valore? Come potremmo seguire il ciclo di vita del prodotto se il Product Owner è ingaggiato solo per la fase di creazione?

Figura 1 – Ciclo di vita di un prodotto.

Figura 1 – Ciclo di vita di un prodotto.

 

Forse potremmo semplicemente risolvere questa apparente difficoltà e “allungare” la fase di affiancamento, per esempio includendo nella Definition of Done (DoD) la verifica in produzione. Potremmo per esempio dire che il prodotto è terminato con successo se, fra 6 mesi, è utilizzato con soddisfazione da un numero sufficiente di persone.

Misurare dei Key Performance Indicator

Per capire cosa vuol dire “con soddisfazione” o “numero sufficiente” abbiamo provato a sperimentare questo: il PO ha il mandato di identificare già durante lo sviluppo del prodotto i KPI con i quali esso verrà poi valutato; talio KPI vanno agganciati al progetto.

Dato che il team verrà smantellato a fine progetto, abbiamo agganciato i KPI al prodotto, in modo da permettere anche ad altre persone di provare a darne una valutazione mentre è in esercizio. Questa è comunque una configurazione non ottimale: sarebbe bello che le persone che hanno sviluppato il prodotto poi lo seguissero e lo facessero evolvere; di certo permette intanto di non perdere per strada il senso di quanto fatto.

 

“Agile è efficace, non efficiente…”

Una volta un manager mi ha detto questa frase:

Mi sto rendendo conto che Agile è efficace, perché vedo che riusciamo (più o meno) a rilasciare sempre meglio e prima quello che serve, quello che il cliente vuole. Però vedo anche che Agile non è efficiente, nel senso che mi state facendo capire che servono persone più costose.

È difficile rispondere in modo sintetico ed efficace a una tale affermazione. Mi limiterò nel dire che sì, è vero, Agile punta all’eccellenza per rilasciare il massimo valore possibile all’utente. Eccellenza da tutti i punti i vista, anche tecnologica [1]; servono quindi persone preparate sulle quali poter investire ogni giorno per farle crescere.

Se il costo a giornata è la (sola) metrica per “affittare” consulenti esterni, senza pensare alla qualità del codice prodotto e quindi senza pensare al reale costo finale del prodotto, allora probabilmente stiamo perdendo un pezzo importante del senso di “fare Agile”.

“Agile è un lusso che non possiamo permetterci”

In tema con le obiezioni appena illustrate, un’altra “rimostranza” che ho ascoltato dai manager è “Agile è un lusso che non possiamo permetterci”, corredata da una serie di affermazioni.

“Dovremmo trovare stanze dedicate? Troppo complicato!”, senza capire che superare l’ostacolo iniziale porta poi a una rimozione degli impedimenti che rende migliore e più veloce il lavoro.

“Dovremmo chiedere al fornitore di mandarci persone in sede e fisse sullo stesso progetto? Non possiamo chiederlo, costa troppo!”, dimenticando che lo sviluppatore che lavora da remoto tipicamente viene allocato tre volte su tre progetti differenti, quindi costa poco perché il fornitore “lo vende” tre volte…

“Dovremmo individuare percorsi di carriera con ruoli chiari e remunerazioni adeguate alle performance? Non possiamo farlo, non abbiamo ancora chiaro cosa faranno da grandi!”, perdendo di vista il cruciale ruolo di un approccio Agile HR alla gestione delle persone e dei loro percorsi professionali.

Rimanendo al tema del “lusso”, proviamo a fare questo ragionamento: come mai una normale barca a vela può essere considerata un lusso e un moderno peschereccio d’altura no? Sono oggetti che fanno la stessa cosa: andare per mare. Probabilmente il peschereccio costa molto di più. La risposta è ovvia ed è legata al valore che permettono di produrre: piacere personale, sport, spirito di avventura, e molto altro nel primo caso; nutrimento da risorse naturali, attività economicamente remunerativa nel secondo caso. Quindi se applichiamo una logica costo/valore prodotto risulta banalmente ovvio rispondere alla domanda.

Quando diciamo che agile costa e che è un lusso, o che è efficace ma inefficiente, quindi, occorre cambiare la prospettiva e chiedersi anzitutto che cosa non stiamo misurando nel nostro computo.

Il problema di fondo spesso è infatti legato a una errata valutazione del costo/valore: si misura spesso il costo diretto ma non il valore prodotto. Si paga poco, ma si genera bassa qualità, che si porta dietro rilavorazioni, e conseguente sforamento dei costi e tempi: per cui, alla fine, si paga uguale se non di più.

 

Partnership con i fornitori

In molte grandi aziende in cui abbiamo lavorato, spesso i gruppi di lavoro sono costituiti da persone appartenenti a fornitori esterni. Si tratta di una pratica molto comune che spazia dal body rental di singole persone con professionalità specifiche (programmatori, analisti, esperti di vari argomenti, scrum master e perfino Product Owner), all’ingaggio di interi team già operativi.

A volte il singolo viene inserito nell’organizzazione e trattato (quasi) come se fosse un dipendente dell’azienda stessa; altre volte invece si nota una netta differenza nel tipo di trattamento riservato agli esterni.

In entrambi i casi — nel secondo di più — questa politica rappresenta spesso un impedimento per abilitare le buone pratiche che sono alla base dell’implementazione dell’Agile. Per esempioci si potrebbe chiedere perché uno Scrum Master non dipendente diretto dell’organizzazione ma “fornito” dall’esterno dovrebbe attivarsi per far crescere le persone; oppure perché il team di sviluppo esterno dovrebbe sperimentare nuove pratiche per migliorare la qualità del prodotto e i tempi di rilascio. Spesso ci si riesce. A volte no.

Ripensare la negoziazione e i contratti

Non è difficile scoprirne il motivo ed è argomento su cui si potrebbe parlare per giorni. Ad ogni modo, consiglio la lettura del libro di Jacopo Romei sulla negoziazione dei contratti, che presenta svariati spunti di riflessione [2].

Qui noi vogliamo solo suggerire di provare a passare da un modello incentrato sullo scambio di valori e basato sulla contrattazione posizionale (vorrei questo da te, sono diposto a pagare questo vs sono disposto a fare questo per te, ti costa tot) verso uno in cui entrambi i soggetti possono trarre un beneficio se le cose vanno bene o ricevere un danno o un costo se le cose vanno male.

Per esempio, il team dovrebbe avere un motivo per migliorare la qualità del codice prodotto perché questo porta a minor manutenzione, per esempio ricevendo un bonus — economico, strategico, operativo… lascio a voi la scelta — se il numero dei bug o il tempo medio di risoluzione di un problema diminuisce col tempo. Se il fornitore fosse pagato “a corpo” per la manutenzione del prodotto, sarebbe forse incentivato a produrre un prodotto di qualità più alta, perché poi la manutenzione si riduce.

Per definire questo nuovo modello di collaborazione riteniamo essenziale coinvolgere tutti i soggetti partecipanti in modo da creare un nuovo accordo in cui tutti credano.

 

Conclusioni

Lungi dal voler proporre soluzioni a “misura unica”, quelle riportate sono considerazioni derivanti dall’esperienza diretta in grandi aziende, dove l’introduzione di principi e pratiche Agile spesso si scontra con resistenze e difficoltà connesse alle dimensioni e alla complessità dell’organizzazione, ma anche dove le trasformazioni agili, quando avviate, possono davvero portare a risultati di grande rilievo.

 

 

Riferimenti

[1] Giulio Roggero, Trust me, I’m a Developer – Caratteristiche e pratiche dello sviluppatore affidabile. MokaByte 226, marzo 2017

http://www.mokabyte.it/2017/03/trustmeimadeveloper/

 

[2] Jacopo Romei, Extreme Contracts. Il knowledge work dalla negoziazione alla collaborazione

https://leanpub.com/extremecontracts

 

Condividi

Pubblicato nel numero
244 novembre 2018
Giovanni Puliti lavora come consulente nel settore dell’IT da oltre 20 anni. Nel 1996, insieme ad altri collaboratori crea MokaByte, la prima rivista italiana web dedicata a Java. Da allora ha svolto attività di formazione e consulenza su tecnologie JavaEE. Autore di numerosi articoli pubblicate sia su MokaByte.it che su…
Articoli nella stessa serie
Ti potrebbe interessare anche