IAD 2021 – Unconference di Venerdì 12 Novembre

Agile Teams’ Structural Dynamics

Quali sono le dinamiche che si scatenano all’interno dei team Agili? Dove nascono le emozioni, le idee?
Da queste domande è iniziato il ragionamento di Cristina Paternoster sul tema delle dinamiche all’interno dei team Agili.

Da sempre noi esseri umani siamo un mix di idee ed emozioni talvolta difficili da esternare. Ricordando ciò che già sostenevano i grandi filosofi del passato, poteva all’epoca – come oggi – esserci di aiuto la figura di un mentore. Ognuno di noi è diverso per attitudini, comportamenti…a renderci unici intervengono altri fattori quali la cultura e l’habitat.

Come possiamo quindi stimolare l’immaginazione?

Tuckman Ladder e stili di leadership

Ci viene in aiuto il Tuckman Ladder model of team development – più conosciuto come Tuckman Ladder – proposto da Bruce Tuckman nel 1962.
Il modello, frutto di un’accurata analisi di molti lavori precedenti svolti su piccoli gruppi di persone, prevedeva inizialmente i quattro stadi forming, storming, norming e performing portati a cinque in un secondo momento con l’aggiunta dello stadio di adjourning. Queste cinque fasi caratterizzano il processo evolutivo mediante il quale i membri di un gruppo possono, laddove le condizioni lo consentano, dotarsi di strumenti adeguati per svolgere al meglio i propri compiti.

Come si combina tutto ciò con i team Agili?
Subentra il concetto di leadership o meglio dei vari stili di leadership che potrebbero essere adottati in ognuno degli stadi del modello di Tuckman. Cristina ci ha proposto alcuni esempi, ad esempio nella fase di forming si suggerisce di adottare uno stile di leadership direttivo mentre per il norming sarebbe meglio adottare uno stile più di supporto. Per ulteriori approfondimenti su Tuckman e gli stili di leadership vi consiglio la lettura di questo articolo.

Kantor 4 Player Model

Persone con abitudini e ruoli diversi formano un team funzionante. Il modello ideato da David Kantor può aiutarci a capire una squadra nelle sue interazioni perché si concentra sulle dinamiche che derivano dall’avere quattro ruoli diversi: promotori, seguaci, avversari e spettatori. A questa pagina potete trovare ulteriori dettagli sul modello che può essere applicato per la risoluzione di conflitti all’interno di un team.

In base al sistema in cui un team opera, l’Agile come si inserisce?

Cristina, durante il suo discorso, ha posto l’attenzione sulle tipologie di sistemi in cui un team opera. Questi sistemi possono essere:

• Aperti, e la metodologia e filosogia Agile funziona bene perché crea sistemi partecipativi, con teamwork, e inclusivi, dove tutti vengono ascoltati. C’è collaborazione.
• Chiusi, come le organizzazioni di una volta che lavoravano – e tutt’oggi lavorano – seguendo il modello Waterfall. Stiamo parlando di classici sistemi con gerarchia rigida e quindi ruoli e responsabilità ben definite e chiuse, poco aperte al cambiamento.
• Random, ovvero le startup. Situazioni ancora non ben strutturate, con confini deboli e quindi aperte a iniziative e creatività. Anche in questa tipologia di sistema l’Agile funziona molto bene.

Qual è quindi la composizione giusta di un team Agile affinché sia pienamente rispondente al cliente e che sia efficiente?

Secondo Cristina, al di là delle expertise verticali (team cross-funzionali), le cosiddette soft skill sono fondamentali facendo attenzione affinché ci sia una composizione mista del gruppo.

Guardiamo al futuro per costruire il presente

Eccoci ad uno dei talk curati dalle community invitate a questo IAD 21, parliamo di The Liberators Network – Italy.

Eleonora della Bernardina, membro della community, ha organizzato una sessione interattiva sull’Agilità ricca di riflessioni e interessanti spunti. Come da tradizione degli incontri della community – a tal proposito, vi invito a seguire la loro pagina MeetUp con tutti i loro eventi passati e futuri – Eleonora ha preparato una board online interattiva per stimolare la cocreazione.

Lo scenario scelto riguarda una situazione alquanto originale, in un futuro che oserei definire distopico: distruggiamo l’Agile.

Distruggere l’Agile

Partendo da questa frase abbastanza forte, Eleonora ha chiesto al pubblico di scrivere su dei post-it un pensiero in merito a questo scenario:

• “Il modo migliore per tradire i valori agili per me è…”
• “Il comportamento che io posso mettere in pratica per arrivare alla totale dissoluzione dei valori agili è…”
• “La pratica che voglio mettere in pratica per arrivare a distruggere il Manifesto è…”

Questo futuro è oggi?

Nella seconda parte di questo mini workshop Eleonora ha invitato tutti a dare la loro opinione rispondendo alla seguente domanda: “Fra tutto quello che hai ascoltato oggi, c’è qualcosa che assomiglia a ciò che le organizzazioni stanno mettendo in pratica oggi?”.

My 2 cents

In  conclusione, “a partire da domani, cosa posso fare io, nel mio piccolo, per mitigare gli effetti nefasti della deriva che ci accorgiamo essere in corso?”

Eleonora, nel tempo a sua disposizione, ha creato un momento di bella e sana discussione sul tema dell’Agilità e in particolare quanto per ognuno di noi siano importanti i principi e valori del Manifesto Agile. Questo grazie all’utilizzo di alcuni strumenti di facilitazione che rispondono al nome di Liberating Structures.

Per il sottoscritto non si è trattato del primo incontro con questa community, colgo l’occasione per condividervi un mio articolo su un altro loro meetup, a tema Zombie Scrum. Per chi non lo sapesse “The Liberators Network” nasce dalle tematiche trattate nel libro “The Zombie Scrum Survival Guide” di Barry Overeem e Johannes Schartau.

Agile Marketing from trenches: cosa abbiamo imparato ripartendo da principi e pratiche Kanban

Enrico Corinti, CEO e Head of Marketing in Webeing.net, ha dedicato il suo momento parlandoci di Agile Marketing, un nome che spesso viene confuso con i termini Growth Hacking e Content Marketing ma che in realtà indica un mindset strategico e operativo. Quello dell’Agile Marketing è un tema ai più sconosciuto, o quantomeno che si tende a dimenticare. Citando lo stesso Enrico

“L’Agile Marketing è come il Molise…esiste davvero!”.

Quale miglior occasione per condividere la propria esperienza e trarre spunti di miglioramento se non la più grande conferenza italiana sull’Agile?

La storia di Enrico e Webeing.net

Tutto ha inizio nel 2010 quando Enrico conobbe Jacopo Romei il quale lo illuminò sull’approccio Lean principalmente basato sulla riduzione degli sprechi.

Trello era

Enrico e il suo team fecero un primo passo decidendo di adottare Trello, uno strumento online per la gestione dei progetti e dei task personali. I mindset e i processi non erano per nulla Agili ma grazie a questo strumento ci si rese conto che avere la possibilità di visualizzare il lavoro non era affatto male. Occorse un problema, ovvero che il “tool guida i processi”: azioni quali “ricordarsi di spostare la card sulla board” oppure “creare una label per la card” legavano troppo le attività allo strumento.

Buzzword era

Per ovviare a questi problemi ed essere sempre pù vicini ad una cultura Agile, si pensò di adottare un linguaggio comune fatto di termini che dessero una definizione a tutto: le buzzword. Si iniziò quindi a parlare di Story Point, User Story ecc.

Scrumban era

Regnava ancora molta confusione nell’organizzazione del lavoro di Enrico e i suoi. Serviva un mentore, qualcuno che li aiutasse a prendere una direzione. Grazie all’attività di coaching con Jacopo Romei il team ed Enrico capirono pian piano come ripartire. Fu di grande aiuto l’utilizzo di Scrumban, una metodologia di Project Management originariamente pensata come strumento di transizione da Scrum a Kanban.
Vennero introdotti nuovi concetti (come ad esempio WIP limit, Cycle Time, no multitasking), strumenti quali Kanbanize e cerimonie. Il tutto adattato alle esigenze del team.

In questo periodo “ibrido” Enrico notò dei miglioramenti: più dialogo, l’uso di swimlane per gestire i task con maggior priorità, e l’utilizzo di misure per monitorare i progressi del team.

C’era ancora qualcosa che non funzionava, ovvero i processi e strumenti prima delle persone. Questo portò ad una riflessione: “Scrum per noi è un tool troppo rigido”.

Kanban era fino ad arrivare ad oggi

Enrico e i suoi sono ripartiti da Kanban, o meglio dalla teoria e basi di questo approccio. Dallo studio e l’applicazione hanno fatto loro questo metodo al punto di scrivere un Manifesto dell’Agile Marketing, seguendo i valori e principi del Manifesto per lo Sviluppo Agile di Software.

Ad oggi Enrico lavora in un ambiente ben definito e condiviso, fatto di tool e processi chiari e condivisi da tutti.

C’è ancora molto da imparare, chissà magari ai prossimi Italian Agile Days Enrico ci racconterà di altre loro evoluzioni.

Ridurre il Time to Market attraverso la sincronizzazione

Come Enrico Corinti, anche Andrea Portuese ha affrontato una tematica simile all’Agile Marketing portandoci la sua esperienza in ConTe.it.

Per misurare e ridurre il Time to Market Andrea e i team nel quale lavora hanno scelto il Cycle Time e lavorato duramente sulla sincronizzazione di persone e processi, rispettando il primo dei quattro valori del Manifesto Agile:

Gli individui e le interazioni più che i processi e gli strumenti

Time to Market

Diamo prima una definizione di Time to Market, ovvero

Il tempo che intercorre fra l’inizio del processo di sviluppo di un nuovo prodotto e l’avvio della sua commercializzazione.

Più precisamente con questo termine si indica anche la capacità di immettere velocemente nuovi prodotti sul mercato. Si concretizza in un processo che, attraverso una stretta integrazione con le funzioni di Ricerca & Sviluppo, Progettazione, Produzione e Marketing, mira ad abbreviare i tempi di ideazione di un nuovo prodotto, di realizzazione dei prototipi e di lancio nel mercato.

Cycle Time e Release Cycle Time

Prima ancora della nascita del Manifesto e del movimento Agile, ConTe.it era già un’azienda “People over Process”: tanta flessibilità ed energia, che non sempre si riusciva a tradurre in una maggiore frequenza di rilascio, e di valore.

Si è scelto di lavorare seguendo il Cycle Time che indica il tempo dalla presa in carico della User Story (U.S.) fino al suo completamento ovvero lo stato della U.S. in Done, test scritti ed eseguiti con successo e verifica da parte del Product Owner (P.O.).

Al classico Cycle Time Andrea e i suoi colleghi hanno aggiunto una ulteriore specifica considerando il tempo che intercorre tra la presa in carico della U.S. fino al rilascio in produzione. In tre parole, Release Cycle Time.

People, Tool, Process, Business e un’unica chiave: la sincronizzazione

Quattro sono gli aspetti o meglio i cardini attorno i quali si è lavorato e si continua a lavorare:

• People: le persone ingaggiate sull’importanza della frequenza e della qualità di rilascio. Non serve un calendario rigido, se non per particolari dipendenze.
• Tool: utilizzo di una “release chat” e l’istituzione di un “Magic Release Team” – temporaneo e multiskill – che si occupa della gestione delle release. Per il tracciamento dei task e User Story viene utilizzato il tool Jira.
• Process: ogni dieci settimane viene organizzato un Program Increment (PI) planning di due giorni dove, con una serie di riunioni, tutti gli Agile Team si coordinano sulle prossime attività.
• Business: i P.O. vengono coinvolti nella fase di rilascio e in casi di emergenza, ad esempio per hotfix da rilasciare per un certo software, tutti insieme ci si trova per ragionare su cosa migliorare in partenza. È importante avere sempre a bordo anche gli stakeholder in tutte le fasi del processo ad esempio per la definizione dei criteri di accettazione di una U.S. o la sua dimensione (in termini di complessità).

In tutto ciò, sincronizzarsi è la chiave:

• People: sincronizzarsi aiuta ad abbattere le gerarchie, dal momento che tutti sono sempre allineati. Ogni team è senza un capo.
• Tool: si è automatizzato fin dove possibile, e schematizzato utilizzando Jira per governare il processo di release, lavorando anche sulle label per ogni storia.
• Process: insieme e nel tempo sono state definite e diffuse delle linee guida e best practice condivise.
• Business: insieme alla community Enrico e i suoi hanno lavorato per affinare il processo di rilascio di volta in volta.

To the Agile & Beyond

Simone Raveggi e Teresa Cuomo hanno raccontato la trasformazione Agile della direzione IT di Findomestic con un case study molto pratico che descrive la trasformazione di un modello Waterfall verso un sistema più Agile.

Per aiutare il pubblico nel comprendere la complessità di un cambiamento che coinvolge un’intera azienda, Simone ha utilizzato una metafora tanto divertente quanto efficace.
Ricordate il film d’animazione Toy Story, e in particolare i due protagonisti Woody e Buzz Lightyear? Woody era un vecchio pupazzo che si sentiva minacciato dall’arrivo dell’ultima novità, l’astronauta Buzz Lightyear. Ebbene, prendete Woody e sostituitelo con ciò che era l’azienda prima, un grosso colosso di marmo che voleva e doveva muoversi per abbracciare la novità rappresentata dalla cultura Agile.

Non si capiva nemmeno il perché di una scelta del genere dal momento che al tempo era stata inaugurata la banca digitale, un progetto enorme che peraltro stava andando molto bene. Ma come ci ricorda Eraclito

Nulla è durevole quanto il cambiamento. Non c’è nulla di immutabile, tranne l’esigenza di cambiare. Tutto fluisce, nulla resta immutato

Simone e Teresa hanno spiegato le fasi che hanno contraddistinto questo passaggio dal “vecchio” al “nuovo”, ispirandosi al modello Spotify in cui i team Agili sono guidati dal business e dai “prodotti” e non più dai progetti. Questo modello collaborativo ha coinvolto l’intera azienda ed è stato ispirazione di una più ampia iniziativa legata alla Business Agility, già presente nel piano industriale dell’azienda.

In conclusione, riprendendo una citazione di Buzz Lightyear

To infinity…and beyond

Che rivisitata in chiave Agile diventa

To the Agile & Beyond