AGILE FOR INNOVATION 2019

https://www.agileforinnovation.com/

L’ evento è iniziato con lo speech di Alberto Ricchiari (CIO di Cattolica Assicurazioni), intitolato “Innovazione IT: un approccio bimodale alla trasformazione digitale”, che ha esposto la propria esperienza (tutt’ ora in corso), circa la trasformazione digitale cui è stata sottoposta la compagnia per cui lavora, descrivendo i pilastri su cui basata:

Ha indicato i percorsi di sviluppo interni seguiti, guidati sempre dall’ ottica della semplificazione della comunicazione e della proposta di nuovi prodotti anch’ essi più semplici e gestiti da una organizzazione semplice.

Tali percorsi sono principalmente basati sulla transizione da prodotti a servizi (si pensi alle coperture fornite con le vecchie polizze semplicemente basate su prodotti, contro le nuove fondate sui servizi come ad esempio l’ invio del carroattrezzi o la vettura sostitutiva…), e sulla necessità di una più frequente interazione con il cliente.

La piattaforma su cui è fondata la loro strategia di trasformazione digitale, è costituita da persone+tecnologie abilitanti ed è organizzata di modo da non essere più iper specializzata sui prodotti, ma essere in grado di adattarsi rapidamente ai cambiamenti imposti dalle richieste del mercato.

Nel successivo intervento di Mauro Servienti, dal titolo “Be like a water”, ha descritto la realtà organizzativa della propria azienda, caratterizzata da team distribuiti su 17 fusi orari differenti sull’ intero pianeta (una scelta organizzativa ben specifica). Ha tenuto a sottolineare che nessuno dei dipendenti è fisicamente localizzato nella stessa città di un altro, proprio per avere difformità di culture e abitudini tali da far emergere idee diverse da condividere.

Il titolo dell’intervento deriva dalla caratteristica della loro compagnia, ovvero la fluidità della conoscenza che viene condivisa tra i dipendenti adattandosi ai percorsi, proprio come l’ acqua in un fiume, dove gli argini del percorso sono per loro rappresentati dai processi da rispettare. Tutto ciò che viene fatto deve essere orientato alla condivisione della conoscenza, ed alle decisioni da prendere comunemente.

Le decisioni sono di tre tipi:

1- Architetturali (sul medio termine), come ad esempio l’introduzione di nuove release

2- Tattiche (sul breve termine)

3- Business (sul lungo termine)

Processi e decisioni vanno di pari passo…. E’ stato portato l’esempio di una ballerina che si allena: la sbarra rappresenta un processo, ma anche la conoscenza necessaria a compiere i passi giusti senza cadere, lo sono. Quindi la ballerina, per non cadere, non si affida al caso, ma all’ esperienza ed ai processi….

Le decisioni non vanno prese a caso, ma tramite processi derivanti dalle conoscenze (si ricordi il significato del controllo empirico nello scrum)…. ed i processi vanno costruiti considerando come valore chiave, la condivisione delle informazioni. Nel loro caso, trattandosi di una realtà sparsa su 17 fusi orari, è stato per forza di cose necessario condividere le informazioni in maniera scritta (e non faccia a faccia come raccomandato nel manifesto agile, a testimonianza della non rigidità dei framework applicati). Per sostenere quanto la condivisione delle informazioni sia importante all’ interno di una organizzazione, è stato specificato il risultato di uno studio interno secondo cui una altissima percentuale di decisioni rivelatesi successivamente sbagliate, fossero state prese da singoli e non da più persone insieme.

I 3 problemi identificati nel lasciare prendere decisioni ai singoli sono risultati essere i seguenti:

1- Accountability (spesso, la responsabilità univoca della decisione influenza la decisione stessa che viene presa più per mettersi al riparo da eventuali ripercussioni che la stessa potrebbe avere sul singolo, che considerando i vantaggi che l’ organizzazione ne potrebbe trarre)

2- Mancanza di informazioni

3- Mancanza di tutti gli skill necessari (essendo un tecnico, potrei sviluppare un prodotto tecnicamente perfetto ma che non porta alcun valore di business al cliente, rivelandosi quindi un fallimento).

Nessuno può quindi lavorare da solo, su nessuna tematica, neanche in casi come quello esposto, di una realtà sparsa sul territorio e multiculturale. Una decisione deve, quantomeno, essere presa da non meno di due persone, aventi possibilmente competenze differenti (il concetto di team multifunzionali in scrum), una delle quali deve eseguire la review di ciò che viene prodotto dall’ altra. Nella loro organizzazione, ogni card della kanban board viene presa in carico da almeno tre persone con skill differenti (tecnici, marketing e business). Alla domanda su come la loro potesse essere riconosciuta come una organizzazione “agile”, anche non rispettandone caratteristiche fondamentali quali la co-locazione, il dialogo faccia a faccia ed altro, è stato risposto sottolianeando quanto i framework agili non siano metodi ma, appunto, framework adattabili alle esigenze della compagnia! Nella loro realtà, i team, come detto multifunzionali e sempre distribuiti sui 17 fusi orari, sono di più tipi (TASK FORCE e SQUAD). Le “TASK FORCE” hanno breve durata (ad esempio uno Scrum team che lavora per 3 settimane ad una issue e successivamente si smonta per formare altre task force di modo che i componenti si occupino di qualcosa di diverso ogni 3 settimane…)

Tools utilizzati dalle task force:

• Slack (chat per comunicare)

• GitHub issues (per condividere issues)

• GitHub Draft/PR (prodotti dalla task-force)

Le task force restano in contatto tra loro tramite slack, ove possono aprire “request for content” per ottenere supporto da altre task force al fine di risolvere la issue per la quale potrebbero non avere le necessarie competenze. Al termine della “request for content”, la soluzione alla issue viene implementata e si fa retrospettiva per capire cosa sia andato bene e male nel processo. Nella loro realtà aziendale, sono presenti particolari task force denominate “SQUAD” che si occupano della business analisys:

Le squad hanno visioni di lungo termine, non prendono decisioni ma sono responsabili del processo di prioritizzazione e del mantenimento del backlog (vedi “product owner” nello scrum). Hanno a disposizione le “guild”, ovvero delle piazze per confrontare il proprio operato con quello di altre squad e per espandere la conoscenza. Chiunque nell’ organizzazione può richiedere di far parte di una squad, e la scelta degli elementi delle stesse viene eseguita semplicemente secondo l’ ordine di arrivo delle richieste. Anche grazie a questi criteri di assegnazione, la loro struttura organizzativa non è mai la stessa e si contrappone all’ organigramma fisso. La diffusione della conoscenza aumenta il “bus factor”, una metafora secondo cui potrebbe essere misurata la diffusione della conoscenza nell’ organizzazione..

Tale parametro indica quanti compponenti di una organizzazione debbano ipoteticamente essere investiti da un bus affinchè l’ azienda sprofondi, misurando la capacità della stessa di restare attiva grazie alla diffusione della conoscenza tra i restanti. Chiaramente, quanto più alto è il parametro, tanto più la conoscenza in azienda è diffusa, quindi tanto più funziona la condivisione delle informazioni….

Quindi: << le persone devono essere al di sopra dei tools!!! >> I componenti dei team devono essere autonomi ma perseguire uno stesso obiettivo comune (uno stormo di uccelli vola a forma di triangolo per questioni di aerodinamicità, ma tutti conoscono perfettamente la destinazione ed hanno un obiettivo comune, ovvero la migrazione).

Nel terzo talk “L’ agile, il manager, la piattaforma”, i consulenti Giovani Puliti e Stefania Calamai di “Agilereloaded” hanno condiviso la loro esperienza nel supportare la trasformazione agile di una grande azienda, dal punto di vista manageriale; La produttività, lo spremere le persone, non rappresentano un valore per l’ azienda che deve anche riconoscere il valore del tempo libero per i collaboratori.. Si sono ispirati al libro di Stephen Denning “Leader guide – Radical management” che propone 4 valori cardine:

Denning affianca 7 principi:

cui loro hanno, nella loro esperienza, aggiunto ulteriori principi:

In questo contesto, la piattaforma è lo strumento tecnico che permette di standardizzare i flussi informativi.

Le caratteristiche, le user needs di una piattaforma sono:

A differenza di altri tipi di prodotto, per i rilasci sw si tende a considerare concluso il rapporto con il cliente, una volta consegnato il prodotto di progetto, << è fatto quando è fatto!!>>, (si pensi alla colonna “Done” del Kanban per sviluppo di un determinato sw…). Bisogna instaurare un rapporto con l’ utente, fatto di assistenza, supporto …….. Con i rilasci sw, manca quindi un pezzo, è necessario introdurre il ciclo di vita esteso del prodotto, sino a che lo stesso non verrà ritirato dal mercato! Vanno quindi introdotte nuove metriche di misurazione (durante e post rilascio) per capire quale sia il valore realmente rilasciato e percepito dall’ utente:

Misurazione interna/indiretta (per cui non necessario coinvolgere il cliente)

• Analisi comparata della velocity

• Maintenace vs Dev

• Lead time, Cicle tyme etc….

Misurazione esterna/diretta (anche chiedendo direttamente al cliente)

• Chiedere all’ utente

• Survey

• Strumenti statistici per misurare la usabilità

Un esempio di misurazione indiretta/interna è rappresentata dalla “team velocity”. Un esempio di misurazione diretta/esterna è rappresentata dal numero di clic su una pagina web rilasciata. Ad ogni modo, esistono diversi testi contenenti strumenti di misurazioni di uso comune… La misurazione del ciclo di vita esteso porta innumerevoli benefici:

L’ Agile Portfolio Management, supporta la misurazione, fornendo una rappresentazione visuale del lavoro, tramite board e cartellini. Un “portfolio” permette di dare una pianificazione temporale alle attività (vedi 3 esempi):

(Dove Q1..Q4 dell’ immagine, sono “quarters”)

Nella loro realtà, è presente una board su parete lunga 10 metri, sulla quale tutti possono visionare in un luogo accessibile e di passaggio, lo stato delle attività in corso e dove sia possibile, dinnanzi alla stessa, soffermarsi per scambiare opinioni e consigli in maniera diretta senza passare da strumenti di comunicazione canonici che impedirebbero il flusso di informazioni praticamente immediato. Altro aspetto fondamentale, a cui bisogna fare particolare attenzione, è legato alla prioritizzazione delle attività. “Urgente ma non importante”, ad esempio, potrebbe avere priorità inferiore a qualcosa di meno urgente ma più importante che porta maggior valore al cliente! Qualsiasi attività si esegua, deve pervenire da un precedente processo di prioritizzazione, perché come noto, le aziende hanno più idee che risorse!!
Un esempio di strumento di prioritizzazione da utilizzare poterebbe essere la matrice di Eisenhower.

In conclusione:

Nel workshop del pomeriggio condoto da Gianluca Abbruzzese , intitolato “Innovazione intorno alle persone”, è stato illustrato come descrivere al meglio il prodotto di progetto richiesto, per fornire al cliente ciò che effettivamente richiede passando dalla definizione dell’ utente tipo destinatario del prodotto stesso. Agile ha successo perché modelli più complessi non sono abbastanza flessibili per i contesti moderni. I partecipanti sono stati divisi in 3 team di innovazione, ai quali è stato sottoposto un caso di progetto, concentrandosi nella definizione delle persone destinatarie del prodotto finale. Si sente spesso parlare di resilienza dei team, che reagiscono in maniera “forte” ad un problema. Un team antifragile, riesce a creare valore dall’ incertezza ovvero reagisce all’ incertezza stessa! Innovare significa creare qualcosa che abbia valore e significato per le persone. E’ stato utilizzato l’ esempio di un particolare prodotto, un trapano. L’ utente finale non vuole un oggetto, il trapano appunto, ma vuole semplicemente fare un buco nel muro! E’ il punto di vista delle persone (utenti finali) a contare, a definire quale sia il valore del prodotto del progetto. • 4 caratteristiche principali per un team Agile:

• Consapevolezza

• Franchezza

• Comunicazione

• Fiducia

In un contesto di innovazione, è necessario essere agili perché ci si muove in un contesto di incertezza (conosciamo la destinazione ma non il percorso) e volatilità (la conoscenza), quindi come essere agili in un team?

1- Dare risposte veloci

2- Creare strutture flessibili

3- Comunicare agile

Ovvero: Design thinking + Lean + Agile Come detto, divisi in 3 team di innovazione, con 20 minuti a disposizione, ci è stata richiesto di approcciare il seguente problema in modo agile per andare dal cliente a proporre il nostro prodotto: “varata la legge secondo cui sono stati resi obbligatori gli open data per le pubbliche amministrazioni, avendo noi del team sviluppato una poc MVP, ricercare l’ approccio agile per proporre ai clienti (ammistrazioni pubbliche appunto), la nostra soluzione”. Come linea guida è stata fornita la “Mappa dello scopo”, di seguito un esempio di quanto emerso inizialmente come primi punti:

Tra gli spunti, è emerso che, particolarmente trattandosi di una pubblica amministrazione, non bisogna andare oltre il richiesto, quindi il vero valore è la sola soluzione di ciò di cui hanno bisogno. In realtà tale caso reale è già stato affrontato da una startup ed il clamoroso risultato è che nessuno dei 150 comuni contattati, dopo la presentazione della soluzione, ha accettato di fare da partner. La causa principale del fallimento è stata ricondotta all’ errore della startup, nell’ avere focalizzato le proprie attenzioni sul prodotto e non sulle persone destinatarie dello stesso (vedi esempio del trapano riportato in precedenza). Ci si sarebbe dovuti concentrare su “chi andiamo and incontrare per vendere il nostro prodotto” piuttosto che su “cosa stiamo vendendo”! Parliamo delle “buyer personas”, ovvero chi decide se comprare, e non chi dovrà utilizzare il prodotto!! Infatti nell’ esempio riportato, chi doveva decidere se collaborare alla sperimentazione della poc, non aveva alcuna interesse nel rendere pubblici dati che sino ad allora non lo erano…..in altre parole, è necessario entrare nella mente dei buyers, conoscerli: chi sono? Dove vivono? Cosa fanno e cosa faranno? Come lo faranno (esperienza, compiti che hanno, come approcciano il problema)…… Avremmo quindi dovuto fare l’ analisi delle buyer personas e dei comuni che potrebbero potenzialmente acquistare il nostro prodotto… Quindi, per tornare all’ esempio del trapano: l’utente non vuole un “super-trapano” ma vuole semplicemente fare un buco nel muro …. Da dove emergono questi dati relativi alle buyer personas? Derivano da interviste fatte agli stessi, verificando sul luogo come funziona un comune, come sono mappati i dati etc…… E’ necessario raccogliere informazioni!!! La “Mappa dello scopo” è prorio un canvas utile per mappare le esigenze del cliente, mentre per mappare le esigenze degli utenti può essere utilizzato un ulteriore canvas denominato “Mappa degli utenti” (sono esempi). Nell’ immagine sottostante, un’ altra mappa: la “Mappa di vitruvio”:

In conclusione, in un processo di innovazione agile, non esiste una ricetta, ma per ridurre l’ incertezza:

1- Inquadrare il cliente

2- Scoprire desideri e bisogni REALI

3- Convalidare il problema (creare consistency, ovvero uno strumento x verificare oggetivamente che l’ intuizione è giusta..)

4- Creare valore (idee, progetti e potenziali soluzioni)

5- Definire MVP (minimum viable product) / MAP (minimum awesome product)