Agile Scrum: alternative più flessibili e agili

Durante le diverse discussioni con gli altri Eroi, ho spesso detto che Agile Scrum non mi sta molto simpatico e che preferisco delle alternative per organizzazioni del team di prodotto più flessibili. L’ho ripetuto così tante volte che alla fine mi hanno chiesto di raccontarvi com’è nata questa antipatia e come cerco di organizzare i miei team.

Il post è abbastanza lungo. Se sei di fretta puoi scaricarlo in PDF e leggerlo con calma quando vuoi.

Ma Agile è Scrum?

Innanzitutto, facciamo una premessa:

Agile non è Scrum, e viceversa. 

Il Manifesto Agile è un insieme di best practice che, mantenendo sempre il bisogno dell’utente al centro del prodotto, cercano di aggiungere una maggiore flessibilità e adattabilità alla fase di sviluppo. 

È difficile non essere d’accordo con il Manifesto.

(Se non ti accontenti della mia iper semplificazione e vuoi saperne di piu, Marco ha scritto un post molto completo sull’Agile) 

Scrum è invece un framework, una sorta di manuale delle istruzioni che promette di aiutarti a mettere un po’ agilità ai processi di sviluppo software. E’ ispirato dalle idee del Manifesto agile, certo, ma, come tutti i framework, aggiunge processi, regole e ruoli. Struttura la taglia e l’organizzazione del team, impone tempistiche e definisce cosa si deve e cosa non si deve fare. Ci sono libri su libri che descrivono come bisogna organizzare un team e una miriade di formazioni per ottenere il titolo di Certified Scrum Product Owner (io stessa ne ho seguita una, una decina di anni fa). 

È proprio a questo livello, che comincio ad avere più dubbi che certezze.

Scrum from the book, graal o demone?

Negli ultimi dieci anni, almeno in Francia, Scrum è diventato il framework di sviluppo più alla moda, una sorta di deus ex machina capace di risolvere tutti i problemi dell’azienda. 

Durante questo periodo, ho avuto modo di lavorare e discutere con diverse organizzazioni prodotto e il risultato era quasi sempre lo stesso: bisognava implementare Scrum per essere agili e creare dei prodotti migliori e, per non sbagliare, era meglio seguire pedissequamente il manuale! 

Moltissime aziende tech francesi hanno quindi applicato alla lettera le pratiche del framework scrum, creando delle organizzazioni prodotto che si assomigliano un po’ tutte.

Ma cos’è che davvero non mi piace nello Scrum, soprattutto se from the book?

L’idea che il framework sia tutto quello di cui abbiamo bisogno

Il from the book suggerisce che basti seguire il manuale per essere successful. Io, invece, sono intimamente convinta che non si possa scegliere un framework (qualsiasi framework, non solo Scrum) e implementarlo ciecamente in un’organizzazione. 

I team sono fatti da persone che vivono in un contesto, aziendale e culturale, specifico, con bisogni e aspettative ancora più specifici. 

Implementare Scrum from the book significa chiedere all’organizzazione di riprodurre regole e concetti che sono stati creati da persone completamente esterni al contesto. 

E’ giustissimo ispirarsi a un framework, ma bisogna poi adattarlo al contesto dei diversi team.

Non sono le persone a doversi adattare al framework, ma il contrario. 

L’organizzazione con un Product Owner funzionale e un team tecnico

Come dicevo Scrum impone dei ruoli, tra cui un Product Owner, responsabile funzionale, e un team tecnico, responsabile dello sviluppo. 

Della differenza tra Product Owner e Product Manager ne abbiamo già parlato in questo articolo, ma quello che mi interessa ora è la dicotomia tra sviluppo e prodotto. 

Concentrando le responsabilità della funzionalità sul PO, si allontana il resto del team dall’obiettivo primario: risolvere un vero problema degli utenti per aiutare il business. 

Il team di sviluppo esegue degli ordini e crea tecnicamente la feature richiesta. 

È responsabile della qualità, certo, ma non dell’impatto della soluzione. Più il tempo passa, e più gli sviluppatori diventano meri esecutori di decisioni prese da altri, basate su una visione strategica che si allontana ogni giorno di più dal loro quotidiano.

Quando voglio provocare un po’, riassumo questa cosa dicendo che “Scrum infantilizza il team di sviluppo”

Il Product Owner, dall’altro lato, è responsabile di feature spesso definite, almeno a grandi linee, da altri (stakeholders, richieste dirette del team Sales, top management…), in un approccio quasi completamente top down. Ha una conoscenza approfondita dei dettagli, ma poco tempo e visibilità per focalizzarsi sull’impatto globale. 

Sono invece convintissima che il team (PM, sviluppatori, designer…) debba essere un unicum, in cui tutti, a diversi livelli di dettaglio, siano in grado di spiegare cosa si fa e perché si fa proprio quella cosa. 

Non c’era scritto nella user story

Corollario del punto precedente: il focus sull’output e non sull’outcome, apre le porte a un po’ di cattiva fede. Tanti anni fa, nella prima azienda in cui lavoravo, scrivendo una user story, ho dimenticato di specificare che il pulsante “Cancel” avrebbe annullato l’azione. Quando ho fatto notare allo sviluppatore che quel pulsante non era lì solo per decorare la pagina, mi sono sentita rispondere “Eh, ma non c’era mica scritto nella user story…”

Caso limite, certo, e sviluppatore particolarmente simpatico. Ma la cosa mi ha fatto pensare. Quando si lavora su feature complesse, con poco tempo a disposizione e tante cose da fare, la tentazione di “spegnere il cervello” ed eseguire delle tasks quasi meccanicamente è molto forte. 

Scrum, poi, utilizza la velocity come unità di misura della capacità di produzione di un team. Teoricamente, la misura dovrebbe essere lì per aiutare a stimare la quantità di tasks da mettere in uno sprint, ma, molto spesso, è considerata una vera e propria misura della produttività del team. E chi dice “produttività”, dice “giustificazioni infinite (e a volte completamente artificiali) su perché questo sprint non sia andato come quello precedente”

In più di un’azienda, inoltre, ho visto il top management seguire questa metric come se fosse l’unico indicatore affidabile per controllare la salute del prodotto, arrivando addirittura a confrontare le velocity tra team.

In un contesto del genere, è facile immaginare perché il mio vecchio collega abbia preferito passare il ticket in Done, anziché spendere qualche minuto e riflettere a come rendere il pulsante Cancel più utile per l’utente finale.

Insomma, ho l’impressione che la rigidità de processi e le metriche predefinite distraggano dall’obiettivo principale che non è assolutamente quanto è stato prodotto, ma cosa e quale sara il suo impatto sull’azienda.

Agile Scrum, alternative o ScrumBut…

Ho iniziato dicendo che non esiste un framework miracoloso che può essere implementato ciecamente in un’organizzazione e ottenere risultati immediati. Questo vale per qualsiasi framework, ma nella mia esperienza ho incontrato molta più ossessione per l’implementazione di Scrum from the book, che per altri framework. 

Ok, Scrum è molto alla moda, ma per quanto abbia cercato non ho trovato nessun guru dell’OKR from the book…

Allora perché? Osservando le diverse organizzazioni con cui ho lavorato e le diverse teorie su Scrum, sono arrivata alla conclusione che è il modo stesso in cui Scrum si presenta che provoca un’ossessiva ricerca dell’implementazione from the book. 

Ogni volta che qualcosa non va con Scrum o che qualcuno emette un dubbio o una critica velata, l’esperto Scrum presente risponde “Ah ma tu non segui Scrum come dovresti, quello che fai è ScrumBut…”. 

Per quanto possa sembrare assurdo, un agile coach con cui lavoravo tirò fuori lo Scrum Guide per citarmi il passaggio in cui si dice “Scrum exists only in its entirety…”

Se il problema non è Scrum, ma il modo in cui si applica, allora è normalissimo che tutti cerchino di avvicinarsi il più possibile al modello descritto.

Io, in realtà, ho poca stima per qualsiasi tipo di estremismo, però mi dico: se negli ultimi 10 anni, tante aziende, fatte di eccellenti professionisti e orde di agile coaches, hanno cercato di implementare Scrum from the book con scarsi risultati, il problema non è forse altrove?  

Insomma, con tutte le sue regole e processi, Scrum non offre abbastanza flessibilità all’organizzazione prodotto. Cosa fare allora per cambiare le cose?

Semplice: ho cercato delle alternative ad Agile Scrum from the book

Storie di vita vissuta: la mia ricerca di un’alternativa ad Agile Scrum

Quando quattro anni fa sono arrivata in TheFork, i team di sviluppo erano essenzialmente a Parigi e avevano cominciato da qualche tempo la transizione verso Scrum. 

Io venivo da un’azienda americana in cui l’organizzazione prodotto era un po’ diversa e riscoprivo lo Scrum from the book per cui avevo già poca simpatia. 

L’azienda non lavorava ancora con gli OKR, ma aveva, ovviamente, degli obiettivi business abbastanza chiari e la volontà di integrare un sistema più generale e basato sull’impatto in un futuro. 

Ho quindi approfittato della creazione del mio nuovo team per cominciare a introdurre un sistema basato sull’outcome piuttosto che sull’output. Con la speranza di raggiungere velocemente un livello di maturità abbastanza elevato da permettere la creazione di un empowered product team. 

(Sulle empowered product team bisognerebbe fare un post a parte, ma consiglio la lettura dell’articolo interessantissimo di Marty Cagan)

Molto velocemente ho iniziato a includere il team di sviluppo in discussioni sul business dell’azienda, a parlare di problemi da risolvere piuttosto che di feature da costruire. 

Ho chiesto il loro aiuto per la definizione delle KPIs e ho messo tutti davanti a domande difficili come “Allora, cosa facciamo per aumentare il CR di 5% questo trimestre?”

Ho cominciato a delegare molte delle attività volte alla costruzione della soluzione, a chiedere anche al resto del team di prendere l’ownership delle user stories, sul backlog, e a non concentrarsi solo sulla qualità del codice. 

Tutto ciò con una buona dose di Scrum bashing, a volte un po’ violento, lo ammetto. 

Risultato: due mesi dopo nessuno voleva più lavorare con me. 

Le critiche andavano dal “Non sa fare il suo lavoro” a un più moderato “Cerca di delegare troppe cose”.

Nessuno capiva cosa stava succedendo, perché all’improvviso si trovavano senza una struttura, senza regole, senza manuale d’istruzioni e, soprattutto, catapultati in un mondo dove gli obiettivi business erano più importanti delle soluzioni in sé.

Al team mancava terribilmente Scrum, non solo perché faceva già parte del loro mindset, ma anche, e soprattutto, perché si sentivano improvvisamente disconnessi dal resto dei team, che continuavano la loro vita normale, segnata dalle diverse cerimonie Scrum.

L’esperimento, seppur interessante, si era rivelato un fallimento totale. 

Bisognava cambiare, ma come? 

Ritorno in trincea

Una volta accusato il colpo (lo ammetto, non è stato semplice), ho cercato di capire dove avevo sbagliato e come continuare. 

L’epifania e arrivata quando sono riuscita a guardare le cose con distacco: la visione era giusta, Scrum, così come era implementato, non era la soluzione, ma ero andata troppo in fretta. 

Fare Product management significa a volte anche fare Change management, ma non si passa da Scrum from the book a una struttura completamente autonoma in meno di due mesi. Quando si cerca di cambiare la cultura e l’organizzazione quotidiana, non bisogna mai avere fretta. 

C’e scritto in tutti i manuali di management, ma io ho dovuto sbatterci il muso per capirlo.

Dovevo reagire, ma come?

Back to basics

Non sapendo come trovare una soluzione valida, ho cercato di trattare il problema come un qualsiasi problema prodotto.

Quella che stavo cercando di costruire era una nuova organizzazione, un processo abbastanza lungo che poteva essere trattato come una qualsiasi product strategy. 

Ho quindi applicato a tutto il processo un canvas che di solito utilizzo per la strategia prodotto. 

Ne è venuta fuori una cosa cosa che assomigliava al canvas qui sotto 

Prima fase: la preparazione

Ancor prima di cominciare a definire delle attività pratiche per ogni obiettivo, ho voluto concentrarmi sulla difficoltà del team a vivere al di fuori della struttura Scrum. 

I feedback erano stati abbastanza chiari: il team non era ancora pronto a vivere senza una struttura di riferimento, seguendo una strategia completamente diversa rispetto al resto dell’azienda.

Iniziare un nuovo processo, seppur aggiungendo chiarezza e gradualità, senza prendere in conto questo punto, sarebbe stato un suicidio. 

Ho allora deciso di tenere la struttura generale e le cerimonie previste da Scrum. Ho mantenuto degli sprint di 2 settimane, la retrospettiva e, soprattutto, la demo a cui partecipano stakeholders e persone esterne al team. 

Per le altre riunioni (daily meetings, grooming…) ho lasciato la libertà al team di organizzarsi come volevano, invitandomi se necessario. 

Solo dopo ho cominciato a lavorare agli obiettivi, definendo le prime azioni da effettuare

Ho così deciso di lavorare con il Team Lead, una scelta dettata solo in parte dal suo ruolo all’interno del team. 

Il Lead, infatti, era la persona con più anni di esperienza in aziende tech, aveva già visto organizzazioni prodotto strutturate diversamente e aveva, naturalmente, una sensibilità per il business più forte rispetto agli altri. 

Inoltre, nei seppur pochi mesi passati insieme, avevamo scoperto molte affinità al di là del lavoro di tutti i giorni ed eravamo diventati amici. In pratica, avevo bisogno di un alleato e avevo trovato quello perfetto!

Velocemente abbiamo cominciato a lavorare mano nella mano per identificare gli obiettivi business più chiaramente collegati allo scope del team e a inserirli in tutte le discussioni, dalla più tecnica alla più strategica. 

Parlavamo degli obiettivi  business a ogni occasione, rischiando di sembrare dei fissati monotematici, ma la regola che c’eravamo dati era semplicissima: ripetere, ripetere, ripetere, fino alla noia!

In parallelo, ne ho approfittato per analizzare l’impatto delle feature sviluppate nei mesi precedenti, o ancora in corso di sviluppo, sugli obiettivi dell’azienda.

L’esercizio, anche se un po’ artificiale, è stato utilissimo per presentare al team un esempio pratico dell’organizzazione che avevo in mente e ha permesso di dimostrare concretamente che la misura di adozione seguita normalmente, seppur importantissima, non era la sola variabile per valutare la pertinenza del lavoro.

Nel frattempo, il team continuava a lavorare alla roadmap feature based definita per il trimestre, con una piccola differenza: il Team Lead aveva cominciato a scrivere delle user stories, chiedendo, saltuariamente e su delle task molto specifiche, anche l’aiuto degli altri membri del team. 

Seconda fase: la rivoluzione

Durante la preparazione del trimestre seguente, ho deciso che era arrivato il momento di accelerare e cominciare a mettere l’accento sui problemi, piuttosto che sulle soluzioni. 

Il supporto e l’aiuto del Team Lead durante i mesi precedenti era stato preziosissimo e mi aveva dato la possibilità di liberare un po’ di tempo e di focalizzarmi su quella che considero la vera task del product manager: l’identificazione dei corretti problemi da risolvere. 

Per ognuno dei problemi identificati, ho creato quindi un one pager semplicissimo in cui annotavo:

• Il contesto (i customers, le loro abitudini, ….)
• Il problema identificato
• I feedback raccolti 
• L’obiettivo business a cui era collegato e una prima stima dell’impatto
• Delle idee di soluzioni possibili

Il documento serviva quindi come base di lavoro con il team (nel primo periodo solo con il Team Lead, in realtà) per:

• Selezionare i problemi principali da includere nelle attività del trimestre
• Sviluppare i dettagli della soluzione, includendo il designer dall’inizio

All’inizio dettagliavo io stessa le possibili soluzioni e le discutevo con il team, ma molto velocemente abbiamo cominciato a lavorare insieme, partendo dal semplice problema. 

Il one pager finale, oltre alle informazioni già presenti, conteneva una descrizione sommaria della soluzione, le metrics, una prima bozza di design e, soprattutto, i casi che non avremmo coperto con la prima versione. 

Il documento era condiviso con il team, ma era lo stesso che usavo per la comunicazione interna e con gli stakeholders.

Già semplicemente a questo livello, i risultati erano più che incoraggianti. Dopo un primo momento di diffidenza, in cui mi si chiedeva ancora “Ma non dovresti dirci tu quello che dobbiamo fare?”, l’energia prodotta dal sentirsi partecipi della costruzione di qualcosa è stata più forte di tutto.

Risultato: il team ha cominciato a proporre idee nuove, soluzioni tecnicamente più semplici o più facilmente mutualizzabili con altri team. Più di una volta mi sono trovata a dover canalizzare la loro energia per non essere sommersa da mille proposte diverse, e ho visto nascere idee geniali che non avrei mai avuto da sola!

Una volta definita la soluzione, poi, la responsabilità dello sviluppo ripassava quasi completamente nelle mani del team, che si auto-organizzava per l’implementazione. Scrivevano i ticket e dividevano il lavoro in micro step che avrei potuto testare/mostrare agli stakeholders. 

L’unico mio consiglio era di cominciare, sempre, dalla parte più complessa (tecnologia nuova, dipendenze esterne, soluzione tecnica troppo vaga…) per identificare i rischi e risolverli il più in fretta possibile. 

Per il resto, erano liberi di organizzarsi come meglio credevano e di lavorare direttamente con il designer se necessario. 

Neanche un anno dopo, il team aveva acquisito una grande autonomia a livello di sviluppo e tutti erano ben coscienti del forte legame tra il loro lavoro e il business. 

Tra alti e bassi, e qualche contestazione naturale, riuscivano ad accettare e a realizzare con pragmatismo anche delle feature non direttamente collegate agli obiettivi principali dell’azienda (feature marketing, feature un po’ custom per alcuni clienti…). 

Agli occhi del resto dell’azienda, era diventato un team su cui si poteva sempre contare, uno dei migliori in termini di performance, sempre motivatissimo a far avanzare le cose nella giusta direzione. 

(Ndr L’organizzazione che ho creato assomiglia a quella descritta da Basecamp. Effettivamente quando l’anno scorso ho cominciato a leggere Shape up, ho scoperto io stessa molte similitudini e ne ho approfittato per introdurre delle nuove idee, soprattutto per seguire l’avanzamento dello sviluppo. Il punto veramente interessante della metodologia descritta da Basecamp è l’impossibilità di continuare a lavorare su un progetto al di là del tempo impartito. Nel contesto in cui mi trovavo, non potevo interrompere i progetti in ritardo. Ho quindi cercato di far rispettare le deadline, che ci davamo noi stessi, procedendo a delle regolari sessioni di descoping.)

Terza fase: L’imprevisto

Visti gli eccellenti risultati, stavo già pensando a come portare l’organizzazione a un livello superiore. L’obiettivo era di passare da un semplice test su un team, a livello di tutta l’azienda. Approfittando del fatto che avevo cominciato ad occuparmi di un altro team, rimasto scoperto, stavo introducendo lo stesso processo e cominciavo a discuterne con il resto dell’organizzazione prodotto. 

Ma le cose non vanno sempre come previsto e per l’azienda era arrivato il momento di procedere a un revamp completo (tecnico e prodotto) di tutta la soluzione B2B, da completare, ovviamente, in tempi strettissimi. 

Le complessità nell’effettuare un full redesign di soluzioni già mature meriterebbe un articolo a parte, ma uno dei challenge maggiori è sicuramente quello di mantenere la motivazione dei team. 

In questo genere di programmi, infatti, è sempre difficile evitare la metodologia progetto, con le sue direttive più top down che bottom up. 

Noi abbiamo cercato di limitare i danni partendo from scratch ed effettuando un completo revamp tecnico, design e prodotto, ma molti degli user journey esistenti erano validissimi e non c’era nessun bisogno di reinventarli. 

In un contesto così complesso, non avevamo tempo per occuparci anche di uno switch culturale dell’azienda e riorganizzare completamente i team prodotto e sviluppo. 

Ero convinta che tutto il lavoro fatto sarebbe andato perso e che avrei dovuto ricominciare daccapo una volta il revamp terminato. 

E invece mi sbagliavo! Il team con cui avevo cominciato l’esperimento è stato il primo ad adattarsi al ritmo elevatissimo imposto dal programma e ad accettare di dover lavorare con requirement già quasi completamente predefiniti. 

Ma non solo, sono stati anche loro i primi ad prendere, senza nessuna obiezione, la ownership su progetti difficili e non particolarmente interessanti, al di fuori del loro scopo ufficiale, e a trasmettere agli altri team tutte le best practice create durante i mesi precedenti. 

Ciliegina sulla torta, quando a malincuore ho lasciato il team nelle mani di un altro PM per occuparmi di altro, ho voluto rallegrare l’atmosfera dicendo “almeno lui scriverà le user stories”. La risposta del team è stata unanime: “Guarda che noi non abbiamo bisogno che qualcuno ci scriva cosa fare!”. 

Morale della favola

Quella che ho raccontato qui è, ovviamente, resta un’esperienza personale. Un tentativo imperfetto di passare da una metodologia “project based” a un “impact team”. 

Si poteva fare meglio? Certamente! Io stessa, scrivendo, mi sono resa conto dei mille errori commessi, soprattutto a livello della comunicazione. 

Resto comunque convinta che il solo modo per far crescere delle organizzazioni prodotto sia quello di effettuare il grande salto verso dei team impact oriented. 

Un salto che però deve essere fatto a livello dell’azienda, e non di un solo team. Inserendo una dose massiccia di trust da parte del top management sulla capacità dei team a lavorare correttamente, senza bisogno di micro management e roadmap per sprint.

Ma questa è un’altra storia…

E tu, cosa ne pensi? Utilizzi la metodologia Scrum per l’organizzazione quotidiana del tuo team? Sei già impact oriented?