Agile per aziende di servizi, si può?

Il manifesto AGILE descrive dove e come porre l’attenzione nello sviluppo del software; tuttavia, negli anni successivi alla sua definizione, questi concetti sono stati espressi e descritti in framework o metodologie in grado di guidarne l’applicazione pratica; i due più noti ed utilizzati sono SCRUM e Kanban (con la K maiuscola).

Questi framework sono stati ideati e pensati per essere applicati in quei contesti in cui erano più necessari, ovvero in grandi società di prodotto che si trinceravano dietro a contratti e processi.

 

Il framework SCRUM è molto efficace per team che collaborano ad un unico obiettivo ben definito, ovvero team di prodotto o progetti molto ampi. Uno dei principali compiti del team è armonizzare il lavoro e rendere costante e prevedibile il tempo di sviluppo. All’interno della vita del team ci sono dei momenti specifici in cui questo si riunisce per stimare le storie e/o le epiche, per analizzare i singoli task, etc… Tutto questo è necessario affinché il Product Owner possa dare la corretta priorità alle attività da sviluppare, al fine di rispondere al meglio alle richieste del business. È importante notare che in questo contesto il tempo speso nelle attività di stima non è tempo perso, poiché permette di identificare tutte quelle azioni che portano il maggior valore con il minore sforzo.

Il ciclo di vita appena descritto differisce da quello di una società di servizi, a partire dal primo contatto con il cliente. In una società di servizi, quasi immancabilmente il cliente, che sta chiedendo di svolgere un lavoro su commessa, pronuncia la fatidica frase:

“ma quanto mi costa?”

Esistono molte tecniche per gestire questa domanda e nei prossimi articoli approfondiremo i contratti agili, gli workshop e la composizione dei team; per adesso limitiamoci ad asserire che accettiamo la sfida di trovare una risposta. Riflettendoci meglio, quante volte ci è capitato di ingaggiare un meccanico, idraulico, imbianchino muratore o artigiano qualsiasi, senza chiedere “ma più o meno quanto vado a spendere?”? Quasi mai.

Ho provato quindi a mettermi in gioco e rispondere alla stessa domanda che anche io pongo quando ingaggio un professionista.

Ligio alle scritture

Il primo approccio è stato quello del “ligio alle scritture”; ovvero implementare in maniera dogmatica quanto descritto da SCRUM. Ho quindi chiesto al Product Owner di fare una full immersion di qualche ora con il cliente e confrontarsi con il team per produrre epiche, user story e relative stime di effort, utili a produrre un preventivo “a corpo”. Dopo qualche tentativo abbiamo capito che:

• il PO (proxy PO in questo caso) ne sapeva troppo poco dell’argomento e, di conseguenza, le informazioni che dava al team erano insufficienti per produrre stime accurate e affidabili
• Il cliente aveva difficoltà a farci capire quali erano i pillars del suo prodotto e quali i nice to have, non mettendoci sempre in grado di indirizzarlo verso le attività a basso costo e alto valore, alle quali dare la priorità
• Il costo interno del preventivo era molto alto poiché tutto il team era coinvolto nella stima per lungo tempo ed il risultato era comunque impreciso
• In alcuni periodi dell’anno, per esempio appena prima della costruzione dei budget, le aziende chiedono molti preventivi andando a saturare il tempo del team con conseguente impatto anche sulle roadmap di sviluppo già concordate per altri clienti
• Ultimo ma non meno importante: il tempo impiegato nei preventivi non vinti era tendenzialmente tempo e denaro sprecato

 

Durante una retrospettiva ci è risultato chiaro che stavamo cercando di dare priorità al processo/tool, ovvero SCRUM, invece di dare la precedenza alla collaborazione con il cliente ed alla creazione di software di valore per esso. Dopo aver sperimentato e misurato questa strategia, abbiamo deciso di cambiare rotta.

Lo spregiudicato; a.k.a. contratti AGILI

Il secondo approccio che abbiamo percorso è stato: niente progetti, niente preventivi, solo lavoro di team. Dopo vari approfondimenti sulla letteratura (come ad esempio “Extreme Contracts” di Jacopo Romei), abbiamo provato a proporre ai nostri clienti il “nostro” contratto Agile.

Ci siamo posti, come obiettivo più importante, quello di aiutare il cliente a guidare la roadmap di sviluppo in modo da massimizzare il valore creato, fornendo un PO che potesse riferirsi direttamente ai decision maker e un team cross funzionale che avesse al suo interno tutte le competenze necessarie. Questo ci permette di mantenere i prezzi di mercato senza abbassare la qualità del prodotto.

Abbiamo proposto, lavorato e tutt’ora usiamo questo tipo di contratti con alcuni dei nostri clienti selezionati; tuttavia, esistono delle condizioni necessarie per renderli efficaci e profittevoli per entrambi. Prendiamo per esempio un classico contratto “money for nothing and changes for free”. Questo tipo di contratto stabilisce un prezzo per un team cross funzionale che sia in grado di produrre un determinato ammontare di valore ad intervalli regolari. Nel caso in cui ci siano cambi di pianificazione, non esistono vincoli se non quello di tenere costante il valore per unità di tempo. Tipicamente stimiamo le user story e andiamo a dichiarare un numero di storie per sprint; in questo modo, se il cliente vuole cambiare priorità ad una attività, dovrà semplicemente interfacciarsi con il PO e scambiarla con un’altra con la stessa stima.

Anche in questo tipo di ingaggio con il cliente, le sfide sono molteplici:

• Calcolare la velocità del team è inizialmente molto complicato e contemporaneamente essenziale. Nelle fasi iniziali si costruisce un rapporto con il cliente che ha dato fiducia all’azienda, ed essere precisi nel “passo del team” aiuta a tranquillizzarlo. Le insidie sono però dietro l’angolo: inizialmente il team, appena generato, deve imparare a lavorare insieme e, verosimilmente, il dominio applicativo è nuovo agli sviluppatori che possono affrontare le attività da svolgere con eccessiva confidenza o diffidenza. Sicuramente è un momento critico che va gestito con moltissima attenzione.
• Il cliente potrebbe non riuscire a stare al passo con il team. Questa è una situazione spiacevole; fin dall’inizio cerchiamo di sviluppare un rapporto di reciproca fiducia mettendoci in gioco (skin in the game) e far pagare al cliente un team che non rilascia abbastanza valore, sarebbe come contraddirsi. D’altro canto, anche il cliente che non riesce ad alimentare il team con decisioni e/o azioni, sta tradendo il patto iniziale poiché il team è allocato per lui e non può lavorare per altri. È simile ad uno stallo alla messicana in cui cercare una soluzione di compromesso scontenta un po’ tutti.
• Il terzo punto critico è la fase di maintenance: alcuni clienti, dopo aver finito una milestone di progetto, vogliono giustamente andare a monetizzare i loro investimenti e tendono ad andare in maintenance per almeno qualche mese. In questa fase vengono fatti minor change e bugfix, quindi non è economicamente percorribile allocare un intero team per la sola maintenance. Quello che abbiamo capito è che ogni soluzione che proviamo ad applicare contraddice una “regola di buon senso”: per esempio potremmo fare un team che fa maintenance per tutti i progetti in questa fase, ma sappiamo che non è una buona pratica (leale) avere un team che “fa” e uno che “sbaca” (N.d.R: sbaca = corregge gli errori).

Per questo tipo di contratto selezioniamo clienti che abbiano già un rapporto con noi e con cui abbiamo creato un rapporto di fiducia, oppure clienti di cui conosciamo il dominio applicativo. Questo ci permette di essere fin da subito efficaci nella pianificazione.

Oltre a questo, valutiamo la capacità del cliente di stare al passo con lo sviluppo senza creare quei vuoti di lavoro complicati da gestire. Infine, come organizzazione del lavoro e delle maintenance abbiamo chiesto ai team di ricavarsi degli spazi per gestire tutto il ciclo di vita del software. Questo frammenta un po’ il lavoro, ma permette alle persone di avere la possibilità di imparare e crescere non relegando alcuni team alla maintenance.

Purtroppo alcuni clienti non accettano comunque questi tipi di contratti, soprattutto al primo approccio.