Agile Mindset: cosa è, esempi reali e consigli pratici.

Abbiamo già parlato di cosa è Agile e di quali sono le due principali metodologie, ovvero Scrum e Kanban, e allora perchè continuare ad affrontare il tema Agile, addirittura dedicando un intero post al Mindset Agile?

La risposta è semplice: Agile è principalmente una questione di mindset, non di tool o framework. 

Questa immagine spiega bene il concetto.

Agile Mindset è più importante dei framework e delle pratiche giornaliere Agile
Credits: Forbes

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

Scarica il post in PDF

I Framework Agile sono semplici

Cosa è una sprint, come fare uno sprint planning e come condurlo nel migliore dei modi, lo impari facilmente. Ci sono decine di articoli online. Appena inizierai a farlo capirai cosa funziona meglio, nel tuo caso, e dopo varie iterazioni avrai trovato il modo giusto per te, la tua azienda e il tuo prodotto.

Il punto di base è che se impari a fare il perfetto “sprint planning” in un’azienda o in un team che non condivide un mindset Agile, sarà una lunga, eterna, estenuante battaglia contro i mulini a vento.

Avrai imparato una tecnica di Project Management sfruttando solo una minima percentuale di quello che Agile potrebbe darti.

Se sei già un lettore di Product Heroes saprai quanto siamo fissati con il WHY. Quindi partiamo da lì.

Importante: Questo è un post dedicato a tutti coloro che gravitano intorno allo sviluppo di prodotti digitali. Se sei un Product Manager avrai già chiari questi concetti. Probabilmente gli altri colleghi con cui lavori fianco a fianco o i tuoi capi NO! Fatti un regalo e inoltragli questo post 😎.

Perchè avere un Mindset Agile è fondamentale?

Anche qui la risposta è super semplice. Un po’ strana, se vuoi, ma semplice.

Devi sposare un Mindset Agile perchè “non lo sai”.

Sì, hai letto bene. Quando fai innovazione non sai come fare la maggior parte delle cose. Puoi fingere che non sia cosí per vendere la tua idea a investitori o a ai tuoi capi, ma dentro di te sai che non hai una risposta certa alla maggior parte delle cose che dovrai fare.

Quando non hai la maggior parte delle risposte cosa è più importante?

  1. Avere una singola risposta giusta? 
  2. Usare un metodo che ti aiuti a capire come avere a che fare con tutto ciò che non sai e con le centinaia di decisioni che dovrai prendere?

Il mio punto di vista è che semplicemente non hai alternative. O accetti l’incertezza e cerchi di capire come gestirla e, soprattutto come scalare la gestione dell’incertezza, o ti schianterai, è solo questione di tempo.

Cosa è l’Agile Mindset?

Non esiste una definizione univoca.

Io proverò a darti la mia definizione di Agile Mindset, ma con un approccio leggermente diverso. Partirò infatti dal presupposto che per creare, gestire e sviluppare prodotti digitali non hai alternative se non utilizzare metodologie legate al Movimento Agile, come Agile Scrum, Kanban, Scrumban, Extreme programming, etc.

L’Agile Mindset, per me, è quell’insieme di credenze e di valori diffusi e consolidati in un’azienda che ti permettono di applicare metodologie Agile (e Lean) nello sviluppo di prodotti digitali.

Ti spiego cosa intendo con tre esempi

Sprint Planning e Agile Mindset

Se in uno sprint planning abbiamo fissato un obiettivo e inserito 10 task, se a fine sprint per vari motivi ne abbiamo svolti solo 7, va bene così, per tutti: product manager, designer, sviluppatori, stakeholder, executives, anche per il CEO (nel caso di start-up in cui il CEO è ancora coinvolto nello sviluppo di prodotto).

Scope Creep e Agile Mindset

Se una sprint è avviata e l’obiettivo è stato definito, è ok dire di no a richieste che vengono dall’alto ed entrano a gamba tesa durante la sprint, a meno che non si sia verificato un cambio di scenario che renda “inutile” l’obiettivo di sprint.

Feature Factory e Agile Mindset

Se abbiamo appena rilasciato una feature, non continueremo a lavorarci sopra, aggiungendo altri pezzi, finché non avremo evidenza qualitativa o quantitativa (dipende dallo stadio in cui il prodotto è) che quella feature stia portando valore agli utenti.

Il Mindset Agile è qualcosa che sta sopra i valori e i principi e che se non è condiviso e diffuso in tutta l’azienda rende inutile l’applicazione delle singole metodologie.

I 5 pilastri del Mindset Agile

1 – Accettare l’incertezza e tutto ciò che ne deriva

Se dovessi scegliere solo uno degli elementi fondamentali, sarebbe sicuramente legato all’incertezza. Una chiara consapevolezza di cosa è l’incertezza, e dell’impatto che ha, è l’elemento determinante.

E’ nell’incertezza e nei continui cambiamenti di scenari che trova le sue radici il movimento Agile. Per farla semplice ci si è resi conto che non aveva più senso sviluppare software per come si progettano edifici.

Quando progetti un edificio hai già tutte le informazioni che ti servono sia riguardo la parte strutturale, che quella di mercato e degli utenti. Lo si fa da centinaia di anni, più o meno sempre nella stessa sequenza e così funziona. O almeno ha funzionato finora.

Lato software, ma in generale, in organizzazioni che hanno bisogno di evolversi velocemente, prima di avviare un progetto, che sia un nuovo prodotto, una riorganizzazione, o un nuova strategia di CRM, non si ha una chiara consapevolezza di quello che sarà l’impatto.

Di base si hanno solo delle ipotesi, che erroneamente spesso vengono scambiate per dati di fatto.

La soluzione: farlo velocemente, in piccoli pezzi e ad avere un riscontro dal mercato (esempio prodotto), dipendenti (esempio organizzazione), clienti (esempio CRM), il prima possibile.

Sacrificare la “qualità”, in nome della velocità e dell’iterazione. 

Alla base della metodologia Agile Scrum c’è la Sprint che racchiude il concetto stesso di Iterazione. Se ci pensi, se tu sapessi già tutto e non accettassi di trovarti in una condizione di incertezza, non ci sarebbe alcun motivo di iterare.

Useresti la Sprint, come purtroppo fanno in tanti, semplicemente come un “pezzo” di un rilascio più grande.

2 – Fiducia nelle persone e nella loro capacità di avere impatto

Per andare veloci e iterare devi avere fiducia nel team.

La fiducia va oltre il concetto di affidabilità, ovvero la convinzione che le persone con cui lavori faranno esattamente quello che tu gli dirai di fare e lo faranno “bene”. 

Per fiducia intendiamo la consapevolezza che tutti lavoriamo verso lo stesso obiettivo, che possiamo sbagliare, che cose terribili (nello sviluppo software) potranno accadere e che potrebbe anche non essere colpa di qualcuno in particolare.

Sostituiamo la caccia al colpevole, con la domanda “cosa posso imparare?” quando qualcosa va male.

Non si tratta di filosofia, ma della differenza tra realtà organizzative progettate per migliorare e avere impatto rispetto a realtà organizzative progettate per mantenere lo status quo e collassare dopo pochi anni.

La storia non conosce la staticità: o migliori o regredisci. Se non riconosci i cambiamenti di paradigma, non ti stai impegnando per migliorare e tracciare i progressi, regredirai. Punto. 

Come ho imparato ad avere fiducia?

Ho imparato la fiducia nel team a mie spese. Ho impiegato anni.

Non ho un background tecnico e ho sempre vissuto il rapporto con gli sviluppatori in modo conflittuale, come il 90% delle persone che non hanno un background tecnico e lavorano con sviluppatori.

Tutto è cambiato quando il team di cui ero responsabile ha iniziato a crescere. Ho capito che avere fiducia era l’unica scelta possibile, la più efficiente e nel lungo termine la più efficace.

Non ho scelto la fiducia per etica o perché sono “buono”. Ho scelto la fiducia perchè le altre soluzioni erano troppo costose e inefficaci. L’alternativa più comune alla fiducia è il controllo. Il problema del controllo è che non è scalabile e non permette ai team di crescere.

Nel momento in cui ho iniziato ad avere fiducia e soprattutto ad ascoltare è cambiato tutto. L’ascolto e la fiducia sono stati i due singoli elementi che più di ogni altro hanno contribuito alla crescita dei prodotti che ho gestito. Parliamo di KPI finanziari, non di filosofia.

Non bisognava cambiare il prodotto, ma il modo in cui lavoravamo insieme per sviluppare il prodotto. Ho sostituito il dire come fare le cose con lo spiegare il perchè era importante capire come fare delle cose insieme

3 – Il Fallimento è la via più sicura per imparare

Impossibile accettare l’incertezza e avere fiducia senza essere disposti ad accettare il fallimento. 

Adesso lo vedo come un processo inverso: accettare il fallimento e riconoscerlo come parte integrante e strutturale del processo di sviluppo di prodotti digitali ti renderà molto più semplice avere fiducia nel team. 

La possibilità che tu ti stia sbagliando deve essere la prima cosa da validare quando hai una nuova idea. Ormai per me è un’abitudine.

Quando racconto un nuovo progetto, la prima cosa che chiedo è: “Dove fa acqua questa cosa che ti ho appena raccontato? Cosa non ho considerato che invece avrei dovuto e che potrebbe distruggere il mio progetto? Dal tuo punto di vista dove sto sbagliando?”

Che tu sia un imprenditore o un manager, le persone con cui lavori devono avere chiarissimo che possono mettere in discussione quello che dici.

Attenzione: non va confusa la possibilità di mettere in discussione quello che dici con la possibilità di prendere decisioni al posto tuo. Deve essere molto chiaro, a tutti, perchè tu sei la persona che deve prendere quella decisione.

Ne parlavo proprio qualche giorno fa con dei product manager di una start-up che vorrebbero lanciare un nuovo prodotto. Parlavamo di quali KPI scegliere per misurare il successo del nuovo prodotto. Dopo qualche minuto abbiamo realizzato che già stavamo parlando del prodotto da costruire, senza aver ancora parlato con gli utenti per capire se aveva senso costruire quello che pensavamo sarebbe stata un’idea pazzesca.

Avere Torto è ok

Per fortuna non siamo (ancora) robot e ci preoccupiamo molto quando ci viene detto che abbiamo torto.

Il problema di questo tipo di approccio è culturale: sin da piccoli siamo stati abituati ad avere ragione. Avere torto è sbagliato. Quando ti sbagli è imbarazzante. Avere aree di debolezza, e quindi da migliorare, è da deboli.

Il punto è che tutti abbiamo delle debolezze e aree da migliorare. Tutti ci siamo sbagliati e ci sbaglieremo centinaia di volte. Dobbiamo accettarlo e riconoscerlo. Questo è l’unico modo che abbiamo per migliorare.

Il sistema educativo non ci aiuta. Prendiamo i voti a fine anno ed è finità lì. Non dovrebbe essere così. Quando prendi i voti è dove l’insegnamento dovrebbe iniziare. Non dovrebbe essere un sistema valutativo, ma migliorativo come gli OKR :).

Le idee non migliorano quando siamo d’accordo

Strettamente legato a quanto detto sopra, non c’è altro modo per migliorare che quello di cercare il confronto con persone che la pensano diversamente.

Tendiamo ad associare “disaccordo” a “conflitto” e questo in sé non è un problema. Il vero problema è capire come gestirlo, senza eliminarlo.

Se non l’hai mai fatto finora dedica del tempo a capire come gestire il disaccordo con le persone che reputi di valore e che la pensano diversamente da te. Sarà uno degli investimenti migliori che tu possa fare.

Uno degli errori principali che ho fatto in passato, quando ho iniziato a gestire team diversi è che tendevo a mediare tra le parti, non li lasciavo liberi di “confrontarsi”. Avendo responsabilità su tutti i team (PM, Design, Sviluppo, Product Marketing, etc.) e lavorando in team cross-funzionali, quando si accendevano gli animi cercavo di mitigare il confronto.

Dopo un po’ ho capito che non aveva alcun senso. Uno dei modi in cui sono cresciuto di più professionalmente erano i confronti con il CTO. Avevamo idee diverse praticamente su tutto, super diversi caratterialmente, ma riconoscevamo le competenze reciproche e soprattutto avevamo un obiettivo comune. Più che innamorarci delle nostre idee ci usavamo l’un altro per rifinire, distruggere, ri-costruire le nostre assunzioni per creare qualcosa di più efficace. Ci abbiamo messo anni, e ne è valsa la pena.

Quick Tip: lascia i team scontrarsi e confrontarsi in un ambiente protetto. Dai un obiettivo temporale e misurabile, chiarisci le responsabilità, fai in modo che siano “accountable” per il progetto su cui stanno lavorando. All’inizio sarà un inferno, poi sarà la tua arma segreta

4 – Se non lo misuri non lo sai.

Molto semplice: se non hai dei dati qualitativi o quantitativi sull’impatto che quello che hai fatto ha avuto sui tuoi customer sono solo opinioni.

Questa è la singola cosa più complicata da metabolizzare se sei tu stesso il founder e pensi di avere avuto l’idea del secolo.

Sono sicuro che anche a te capita spesso di fare cose semplicemente perchè pensi abbia senso farle. Perché ti fidi del tuo intuito.

Quando non hai riferimenti, l’intuito è tutto. Il problema dell’intuito quando è legato a tante scelte consecutivamente, e molto ravvicinate, è che non dà la possibilità di capire se la decisione presa è stata giusta o sbagliata.

Quel che accade allora, soprattutto nei soggetti molto ottimisti, è che si tende a interpretare positivamente qualsiasi segnale che arriva nei confronti della propria idea o prodotto. 

Se fai innovazione devi farlo. Devi essere particolarmente bravo a mentire a te stesso e agli altri, a re-interpretare continuamente i fatti negativi che ti accadono (tecnicamente si chiama re-framing), a convincere gli altri a seguirti in assenza di fatti, ma solo in previsione che qualcosa di buono possa accadere.

E’ giusto che sia così. Le piccole bugie sono una parte essenziale del fare innovazione. Le piccole bugie contribuiscono a creare la tua realtà, la realtà in cui credi fortemente, la tua vision, senza la quale non avresti mai tutta l’energia che ti serve.

Il re-framing è fondamentale per non buttarti giù, per prenderti solo quello che di positivo c’è dalle brutte batoste e per infondere energia al tuo team anche quando le cose non vanno per il verso giusto.

Ma devi capire quando sei andato troppo oltre e la tua bolla è cresciuta troppo impedentoti di vedere effettivamente come vanno le cose.

Le metriche ti servono a non oltrepassare mai quella sottile linea di confine tra ottimismo e distorsione della realtà.

Il modo in cui ancora in molti fanno Start-up in Italia non ti aiuta. L’obiettivo sembra quello di avere copertura stampa, interazioni sui post su linkedin o raccogliere capitali piuttosto che realizzare prodotti che hanno impatto.

Possono sembrare considerazioni banali, ma se entri nel “teatro del successo” uscirne è davvero complicato. Te lo dico perchè ci sono passato anch’io.

Questo principio, se hai già metabolizzato i tre precedenti sarà super semplice da applicare. Se ti fidi del tuo team, accetti l’incertezza e il rischio, la misurazione sarà naturalmente la via migliore per orientarsi tra le innumerevoli decisioni che dovrai prendere.

5 – Assumersi la responsabilità a tutti i livelli.

Se sei in un ambiente altamente competitivo con un alto grado di incertezza, l’unico modo per andare veloci e avere impatto è che tutti siano coinvolti direttamente ed abbiamo responsabilità sui progetti.

Semplicemente: non hai il tempo per prendere tutte le decisioni.

Allo stesso tempo impiegare 20 minuti per brieffare un team velocemente, senza avere chiaro il WHY, come verrà misurato il successo, e le modalità di lavoro, è la ricetta migliore per creare un disastro.

Come Manager devi creare le condizioni affinché le persone possano assumersi le loro responsabilità. Non lo fai spingendo un bottone. Se finora hai sempre detto alle persone cosa fare e peggio ancora come, non ti puoi aspettare che da domani le cose cambino dicendo loro “Ok ragazzi da domani la responsabilità è vostra”.

Semplicemente non hanno gli strumenti per poter lavorare in un modo diverso.

Un consiglio che posso darti, se stai cominciando, è che come manager principalmente devi fare due cose: 

  1. Ridurre l’ambiguità.
  2. Dare obiettivi chiari e misurabili.

Per semplificare ancora: “Boundaries set you free”, i confini ti rendono libero.

Devi creare quel “recinto” all’interno del quale le persone siano libere di prendere decisioni, eseguirle e soprattutto, sbagliare.

Molto complicato farlo, ma ti assicuro che è molto complicato sopravvivere se non fai così.

Il vero rischio è non cambiare.

6 replies on “ Agile Mindset: cosa è, esempi reali e consigli pratici. ”
  1. Articolo molto completo che spiega come l’agile mindset sia finalizzato a massimizzare l’impatto dei team sul prodotto e come questo si rifletta sui risultati di tutta l’azienda. Ho apprezzato soprattutto la centralità che hanno le motivazioni (il WHY) e di come possano e debbano poter sempre essere oggetto di “challenge” da parte di tutti i soggetti coinvolti nel progetto.

  2. Bell’articolo come sempre. Agile vuol dire anche tanto coraggio, coraggio di accettare errori e permettersi di sbagliare, se è facile farlo in una startup (relativamente), è davvero duro farlo in una realtà corporate dove il “fail fast” è spesso solo materia da slide deck.

  3. Una bella panoramica di cose parecchio importanti.
    Rileggendo ora questi principi e questi pensieri mi rendo conto di come sia difficile interiorizzarli e farli propri. Quando 3 o 4 anni fa leggevo il manifesto SCRUM e degli articoli sull’Agile, cercando di capire come incastrare il processo di Design con quello dello Sviluppo, mi sembravano tutte cose di buon senso e generalmente “corrette”. Ma ora che ci son passato ed ho un po’ più di esperienza riesco a dargli il peso che meritano e ad intuirne la profondità, al di là degli elenchi puntati.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *