Author Archives: Felice Pescatore

Nelle mie ultime esperienze ho avuto l’occasione di sperimentare l’applicazione dell’universo Agile all’interno di un contesto di sviluppo che guarda alla Robotic Process Automation (RPA).

Di cosa stiamo parlando nello specifico?

La Robotic Process Automation (RPA) raggruppa tutta una serie di tecnologie software che hanno lo scopo di automatizzare in modo profondo i processi di back office. Non stiamo quindi parlando di robot fisici o sistemi di alta intelligenza artificiale (almeno in quelli odierni), ma di agenti softwareche sono in grado di completare attività deterministiche e ripetitive che prima venivano effettuate da un operatore umano.

La cosa interessante è che, tipicamente, un robot“attraversa” diversi sistemi, mettendoli in correlazione attraverso lo scambio la gestione dei dati, per portare a casa un risultato unico, spesso la risposta ad un quesito (query) o un report aggregato.

Lo scopo principe di RPA è quindi quello di Mimare il comportamento umano, automatizzando un processo ben delineato che sia suddivisibile in attività e task atomici. Il tutto, ovviamente, con la capacità di ripeterlo all’infinito (fermo restando le condizioni abilitanti) e ottenere sempre un risultato in linea con le attese.

Tra i settori che stanno dimostrando maggiore interesse a questa tecnologia troviamo, ad esempio, quello finanziario dove il costo delle attività di back office rappresenta una parte importante delle proprie spese operative. Secondo una indagine condotta da Deloitte tramite il suo Global CPO Survey, la necessità di diminuire questa fetta di costi è la importante per il 30% dei Global Services Leaders.

Ma torniamo all’esperienza pratica.

La prima sfida da affrontare è stata quella di assemblare il team di lavoro (circa 10/11 persone): completamente in outsourcing, anche se co-localizzato per 4gg su 5, ad esclusione del PO (senza alcuna esperienza pregressa nel mondo Agile, ma grandissimo conoscitore dei processi specifici) e alcuni rappresentanti dell’IT interno, fondamentali per l’interconnessione coi sistemi interessati. Il resto del team era composto da 7 tecnici afferenti a tre diverse aziende fornitrici, con 4 esperti dell’ambito RPA e gli altri dei software e del dominio su cui attivare la mimica.

Si comprende quindi che mettere insieme fornitori diversi, con legittimi interessi diversi, e farli remare in una direzione unica non è proprio la cosa più semplice che si possa fare. Inoltre, il Team Lead apparteneva ad una degli outsourcer, per cui c’era un po’ di diffidenza iniziale da parte degli altri. Fortunatamente lo stesso si è rilevato molto competente e con spiccate dote di Leadership, in relazione al contesto e alla sfida che eravamo posti, così come tutti i componenti del neo-team si sono dimostrati ottimi professionisti e interessati all’approccio.

Essendo una sorta di progetto “pilota/sperimentale”, la prima attività che ho messo in campo è stata quella di chiedere ai presenti di lavorare con strumenti per creare un primo sharing dell’iniziativa da realizzare (Product Canvas, Elevator Pitch, ecc). Tali attività sono state fondamentali per inquadrare meglio i diversi aspetti del prodotto e creare una prima azione di Team Building.

(le immagini sono volutamente a bassa qualità)

Fatto questa prima attività (che, come ben sappiamo è sempre on-going), tutto il team era allineato sugli obiettivi, sui constraintse sul perimetro d’azione. Il passo successivo è stato quello discutere degli aspetti cardini dell’Agile, utilizzando Scrum come framework ispiratore, anche per scelte calate dall’alto, ma con un’ampia libertà di adattamento.

La maggior parte delle tematiche erano nuove un po’ per tutti, ad esclusione del Team Lead che aveva avuto esperienze in merito e che, su proposta del committente, ha accettato di imbarcarsi nel ruolo di Scrum Master. Complice la volontà generale di provare a fare qualcosa di nuovo, le resistenze rispetto all’adozione di Scrum sono state veramente minime, probabilmente grazie anche al lasso di tempo prospettato per il progetto di 6 mesi, cosa che però non ha portato ad una reazione di indifferenza (vabbè, tanto sta roba passa!), ma a una positiva-curiosità verso il tutto.

Nel prossimo post vi parlerò del primo Sprint e di cosa abbiamo imparato da esso.

Stay tuned J

Una delle caratteriste che spesso ci meraviglia dei bambini è la loro perseveranza nel compiere con estrema attenzione ed esattezza determinate azioni, curandone i particolari in modo quasi ossessivo. Quando sono attratti da un’attività, e finché non la sostituiscono con la successiva, la ripetono più e più volte, pretendendo, in qualche modo, di farla sempre in modo similare (standardizzazione) con l’aggiunta di qualche piccola variazione (sperimentazione).

La cosa veramente illuminante è la loro reazione se un adulto tenta di sostituirsi nella definizione della loro “idea di ordine” e di “corretto”, provando a spingere, e in alcuni casi imporre, verso una soluzione differente. Quello che si ottiene è che al primo momento utile (quando è solo, alla nostra prima distrazione, ecc.) il bambino si adopererà per riportare il tutto nell’ordine che aveva precedentemente eletto a quello “giusto”, basato su quanto pazientemente sperimentato ed appreso.
E’ per questo che la Montessori vede sempre i tempi e le soluzioni specifiche di ogni singolo bambino come gli unisci giusti per la sua crescita, riservando agli educatori il ruolo di angelo custode che osserva e non interviene quasi mai (4 principio).
E’ un aspetto incredibilmente similare a ciò che accade se si forza una organizzazione (ma anche un solo team) a seguire una strada che non ritiene idonea per la sua natura: non è possibile costringere le persone a fare qualcosa in cui non credono e di cui non avvertono la necessità, ancor peggio se sono convinte del contrario. Una delle migliori formulazioni di questo concetto è nel processo di cambiamento di Kotter, in cui come primo step del percorso viene identificato il Senso di Urgenza, ovvero il convincimento da parte dei destinatari che sia necessario farlo.

Ma la cosa che accomuna ancor più quanto avviene nel mondo Agile con quanto in oggetto (riferito al terzo principio del Metodo Montessori: Abituare un bambino a fare con precisione è un ottimo esercizio per sviluppare l’armonia del corpo) è che la ripetitività dell’azione specifica sviluppa un fare preciso e metodico, esattamente come accade quando si utilizza un Improvement Kata per migliorare, adattare e innovare costantemente all’interno di una organizzazione.
In tal modo si acquisisce consapevolezza e padronanza, consentendo di sviluppare un’armonia sociale, sia del singolo che della collettività, rafforzata dal padroneggiare metodi, tecniche e strumenti che consentono di soddisfare gli obiettivi aziendali ma anche quelli motivazionali propri della persona, così come rappresentanti anche in Management 3.0.

La capacità di sentirsi realizzati e non essere assimilati a Macchine Banali, trova, inoltre, un naturale sbocco nell’affinamento dell’utilizzo delle pratiche di automation di DevOps (che, ricordiamo, sono diretta derivazione di Lean e di eXtreme Programming) con un robusto utilizzo dei moderni tool a supporto del Deploy e della Delivery. Le persone possono così dedicarsi a quanto le attrae professionalmente (così come i bambini fanno in modo naturale, senza costrizioni) e dare il meglio di se con la massima concentrazione e passione.
Insomma, lasciare le persone libere di sperimentare ed adattarsi è un principio fondamentale che però deve portare a risultati che standardizzano quanto è risultato proficuo per l’organizzazione, in perfetta chiave Lean.

Nei prossimi post parleremo dei 10 principi portanti del Metodo Montessori, provando a confrontarli con i Principi del Manifesto Agile.

Stay tuned

Per quanto si possa eccellere nella scrittura di codice, esiste una triste verità: nessun programma sarà mai privo di bug! Questo porta a riflettere sul come gestire i bug durante una Iterazione, evitando che il team ecceda la normale capacity prevista e risponda in maniera strutturata ad essi.

Per affrontare la questione, è necessario definire cosa si intende per bug: 

un bug è un funzionamento anomalo che si verifica durante il normale utilizzo del software.

Ora questo porta ad alcune considerazioni fondamentali:

• Se i test di unità e funzionali evidenziano un problema durate l’iterazione di sviluppo del Product Backlog Item, non si tratta di un bug, ma di un’azione di “correzione” intrinseca all’attività di sviluppo stessa
• Se il nostro Product Backlog Item è stato validato da Product Owner (e dal key stakeholder), una successiva richiesta di modifica è una “change request” non un bug, e per accoglierla deve essere creato un regolare Product Backlog Item da prioritizzare nel backlog
• I bug hanno sempre alta priorità di risoluzione, in modo da costruire e mantenere una main-line di sviluppo di qualità, ridurre il costo di risoluzione relativo, e poter ottenere una build affidabile in ogni istante (second way di DevOps)

Fatte queste precisazioni, è utile, in fase di Iteration Planning, tenere sempre presente dell’andamento medio dei bug (tre/quattro iterazioni possono essere sufficienti) in modo da riservare una parte della capacity del team proprio per la loro risoluzione. Chiaro che se non si ha un trend decrescente del numero di bug, è necessario individuare un’opportuna azione di riduzione del debito tecnico e approfondire la tematica della Built-In Quality in retrospettiva, decidendo con il Product Owner un opportuno bilanciamento tra nuove funzionalità e aumento della qualità.

A tal proposito, Martin Fowler raccomanda il mantra del “Refactoring forever”, ovvero risolvere immediatamente i bug (critici) intervenendo in modo strutturato per pulire il codice (clean code), senza dimenticarsi di aggiungere gli opportuni test di unità e funzionali (ma non solo) necessari a irrobustire il codice e supportare adeguatamente la pipeline di deploy a partire dalla Continuous Integration.

La cosa importante è quella di non ricadere nella trappola del Team di Supporto (Support Team): non bisogna istituire un team che si occupa esclusivamente di bug a cui si demandano le relative responsabilità di risoluzione. Ciò ha alcune implicazioni molto evidenti, soprattutto dal punto di vista della Cultura Agile:

• Il Support Team si sentirà presto un team di serie-B, perché non coinvolto nelle nuove attività ed iniziative
• Il costo di risoluzione è decisamente più alto visto che il problema non sarà risolto dal team che lo ha (involontariamente) generato
• Il know-how relativo ai problemi scoperti e risolti dovrà essere condiviso con il team originale che ha sviluppato la funzionalità specifica, causando un ping-pong di informazioni e ulteriori perdite di tempo

Il consiglio è quello di prevedere sempre, per ogni team, una gestione in stile Kanban dei bug, riservando una opportuna capacity dello stesso (la regola 80-20 è un buon punto di partenza se non si hanno dati storici del team)) per gestire i bug e occuparsi del refactoring e irrobustimento del codice: Do it your self!

Stay tuned J

Termini come Continuous Integration, Continuous Delivery, Continuous Deployment, DevOps, ecc, sono orami entrati nel gergo comune del mondo dello sviluppo software, complice il cambio di paradigma che inesorabilmente ha interessato l’Application Lifecycle Management (ALM) negli ultimi anni.

Risalendo alle origini comuni che ritroviamo in Agile, e in Lean prima per certi aspetti, la Continuous Delivery è esplicitamente descritta dal primo principio Agile:

“La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua”

La Continuous Deliverynon è esclusivamente un insieme di strumenti e pratiche, ma enfatizza la capacità delle Personedi instaurare una Relazione Sociale(Cultura) e sfruttare Toole Processi per generare Valore continuo per l’utente finale, in funzione di quattro principi fondamentali:

• Il software è sempre rilasciabile, il che significa che la priorità è mantenere il software distribuibile piuttosto che aggiungere nuove funzionalità. Per fare ciò, si prediligono modifiche atomiche (piccole), e meno rischiose, rilasciate continuamente piuttosto che

tutte in una volta

• Le attività di gestione dei requisiti (backlog), la loro formalizzazione ed il loro aggiornamento sono parte integrante del ciclo di valore
• Un (veloce) feedback loop delle fasi di compilazione, teste deployconsente a tutti gli attori coinvolti di stabilire se è possibile approvare un rilascio immediato in qualsiasi ambiente
• L‘automazione del processo di build, teste deployè fondamentale per rendere il processo ripetibile e per supportare una maggiore frequenza del tutto

La Continuous Deliveryimpone letteralmente di mantenere il software sempre in uno stato rilasciabile: nulla può andare in produzione senza aver prima superato i test e le validazioni previste! Tale stato di rilasciabilità consente di spostare con confidenza la build in qualsiasi ambiente in qualsiasi momento. 

Tutto ciò implica l’adozione di pratiche Agili che aumentano la frequenza di build, test e deploy, grazie al supportato di strumenti che ne automatizzano le parti ripetitive.

La Continuous Deploymentsi occupa di automatizzare lo “spostamento” della build su un qualsiasi ambiente, azione supportata da strumenti di configurazione automatica e test di varia natura. Per efficientare il tutto si ragiona intermini di Deployment Pipeline, andando ad automatizzare il più possibile il flusso che porta dalla Continuous Integration(in seguito al check-in del codice) fino al rilascio su diversi ambienti previsti, ognuno con specifici test. 

La Continuous Deployment è quindi un assett tecnico/tecnologico a supporto della Continuous Delivery, rendendo le attività di compilazione/deploy/test, affidabili, elastiche, e capaci di adattarsi automaticamentealle modifiche al codice, agli aggiornamenti dei repository dati e alle configurazioni del server. In pratica avremo:

• Continuous Build, supportato da script e tool per la Build Automation
• Continuous Deploy, supportata da script e tool per l’Application Release Automation
• Continuous Testing, supportato da script e tool per Testing Automation e Virtualization

Una delle rappresentazioni classiche che crea confusione è quella della figura seguente:

In cui si minimizza la differenza tra Continuous Delivery e Continuous Deployment nella sola automazione dell’intera catena, rappresentando addirittura la Continuous Deployment come uno step successivo alla Continuous Delivery. Un po’ poco per giustificare l’esistenza di due terminologie che creano tanta confusione e che differiscono “solo” in un passaggio automatizzato in più, senza, tra l’altro, allargare lo scopedella rappresentazione anche alle fasi di planning e coding. Se si ritiene di voler automatizzare anche il deploy in produzione resta una opportunità e una scelta di business, che può variare anche nel tempo, ma la Delivery ha sempre l’aspetto intrinseco di “guardare all’utente”.

Una possibile rappresentazione più significativa, che abbraccia quanto ci siamo detti, nobilitando la Continuous Delivery è la seguente:

In cui è toccato tutto il ciclo ALM e la Delivery è effettivamente letta in chiave Agile/Lean.

Stay tuned J

Molte pratiche agili, come lo stesso Manifesto, sono nate un ventennio fa(quasi si rabbrividisce nel dirlo). Inutile sottolineare come il contesto relativo in ambito sviluppo, e il significato stesso di “software”, fosse decisamente differente da quello odierno.

Vero è che molti dei problemi organizzativi/di svilupposono nella sostanza molto simili, tant’è che non finiamo mai di ripetere: Persone e Interazioni più che Processi e Tool [primo Valore del Manifesto] ma questo non deve creare delle barriere ideologiche, soprattutto in alcuni aspetti che ormai trovano difficile riscontro con la realtà.

In particolare, mi riferisco alla co-localizzazione dei membri di un team (o di più team), cosa oggi sempre meno frequente e che pone una serie di riflessioni su come “aggiustare” alcune delle pratiche fondamentali del mondo Agile, prima tra tutte la Retrospettiva/Reflection, un dei pilastri portanti dell’agilità stessa.

Non si può di certo immaginare di obbligare tutti i membri del team (laddove chiaramente non lo siano di base) ad incontrarsi di persona, cosa che potrebbe essere sconveniente sotto diversi punti di vista: tempo utile, costi, concentrazione, ecc.

D’altro canto, dobbiamo assolutamente evitare, con tutte le nostre forze, che ciò si trasformi in una scusa per non farla, visto che da remoto le persone si “addormentano” o non riescono a seguire.

Fortunatamente negli anni sono stati sviluppati una serie di tool molto interessanti che provano a mantenere viva la natura stessa della retrospettiva, pur consentendo di abbattere le “nuove” barriere che si presentano nel mondo odierno dello sviluppo. Tra questi il mio preferito, che vi consiglio di provare, è Retrium (retrium.com)

Retrium

Retrium è espressamente realizzato per organizzare e gestire retrospettive con team misti composti da persone in presenza e remoto (in realtà si può usare anche con persone tutte in presenza, l’importante è non porlo davanti all’obiettivo dell’evento!).

Come si può vedere dall’immagine seguente

Sticky Notes e Team Radars

è possibile sfruttare una serie di “template” (definiti Sticky Notes in Columns) che in pratica pre-settano la retrospettiva con alcune delle attività note sicuramente a tutti gli agilisti. Una volta scelta l’attività, il tool fa un breve recap della stessa e permette di gestire i tempi, i feedbacke altri aspetti tipici di una retrospettiva.

Retrium, Mad/Sad/Glad

Ho trovato molto interessante anche la possibilità di creare i Team Radar ( pensate all’High Performance Treeo al THC di Spotify) che consentono di auto-valutare la maturità dei team e ragionare sui punti di improvement.

Chiaramente Retrium permette di registrare quanto fatto in modo da creare uno storico e avere così una visione temporaledei miglioramenti, dei problemi risolti e di quelli latenti che ancora sono in essere.

Chiudo sottolineando che Retrium, come qualunque tool, deve essere di supporto e facilitazione, e non deve mai mettere in discussione il primo Valore, né portare a delle disfunzioni regressive in cui il processo va ad imbrigliare l’agilità stessa dell’organizzazione. Ricordatevi sempre e comunque di fare in modo cadenzato almeno una retro tutti in presenza: ne vale 100 da remoto!

Stay tuned J

Come Agilisti siamo sempre presi dalla volontà di ridurre il più possibile le barriere comunicative interne alla nostra organizzazione, favorendo il più possibile una condivisione fluente delle informazioni, in modo che esse diventino conoscenza, ovvero specializzate rispetto al contesto. Spesso ci soffermiamo sulle azioni cross-team, oppure sull’abbattimento dei Silosche sono visti come uno dei fattori primari di insuccesso ed efficacia operativa. 

Il rischio però è quello di sostituire una “segmentazione” con un’altra (ad esempio un team Agile che lavora in modo isolato in una sorta di sand-box è a sua volta un elemento disfunzionale), senza tener conto dei possibili slicingche possono verificarsi.

Ognuno di essi da vita ad una ottimizzazione locale che ingabbia la comunicazione solo nelle aree relative, tenendo fuori tutto il resto e delegano il trasferimento di know-how a modelli e documentazione formale.

Lo scopo di una comunicazione agile è quello di trasformare l’intera organizzazione in un’Isola della Conoscenza, in cui i diversi modelli abilitanti creano un flow continuo e sostenibile di informazioni a disposizione di tutti.

In quest’ottica, un’azienda Agile riconosce l’importanza di diversi aspetti organizzativi ed operativi e mette in campo approcci, strumenti e soprattutto un Mindset che consante di trovare il giusto bilanciamento delle diverse esigenze al fine di ottemperare al primo valore:

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

Bisogna sempre essere attenti a non considerare lo strumento (Kanban, Trello, Jira, Azure DevOps, ecc) come “LA” soluzione per la comunicazione: rischiamo solo di trasformarlo nel depositario del processo e di fare le cose in modo automatico, pretendendo che gli altri estraggano informazioni dallo stato dei suoi elementi.

Se questo accade, è arrivata l’ora di fare un “back-to-basic” perché abbiamo perso la bussola della nostra agilità, allontanandoci sempre più dall’obiettivo principe:

“La nostra massima priorità è soddisfare il cliente rilasciando software di valore, fin da subito e in maniera continua.”

Abbiamo spostato l’attenzione sulla bravura nel “seguire i processi” … alias… siamo diventati dei burocrati!

Stray tuned J

Esiste una sorta di mito, di leggenda, che si annida tra i corridoi degli Agilisti: lo Sprint 0!

Come molti di voi sapranno, lo Sprint 0 (nella Scrum Guide) non esiste, ma è spesso un modo per giustificare la necessità di avere una fase/momento pre-Sprint 1 in cui si valutano gli aspetti cardini di una nuova iniziativa e si dà il benestare definitivo alla stessa.

L’utilizzo di “Sprint 0” è un tentativo di legare a Scrum una serie di attività che Schwabere Sutherlandnon hanno codificato direttamente nel loro framework, e la sua istituzione, più o meno formale, è un retaggio delle precedenti wavedell’Agile che tentavano di conformarsi a tutti i costi ad un modello, trovano dei workaround adattativi tutt’altro che chiari e trasparenti, in completa antitesi a quanto proposto dall’agile stessa che parla di trasparenza e continuo adattamento.

Generalmente, io preferisco esplicitare lo Sprint 0, anche noto come Lift-off/Kick-off/ecc, identificandolo come Inception della iniziativa, così come suggerito da Disciplined Agile. La cosa fondamentale è che in questa fase (si, ho detto fase J) ci si concentri su tutti quegli aspetti fondamentali e irrinunciabili per “partire con il piede giusto”.

DAD Inception Goals

Per esperienza diretta, così anche come raccontato da Amblere Lines(ma non solo, la letteratura è piena di casi concreti), gli 8 obiettivi riportarti in figura sono fondamentali: bisogna sempre prenderli in considerazione durante l’Inception, anche se, ovviamente, una parte di essi può essere derogata o assorbita perché, di fatto, già risolto. Si pensi ad esempio a “Form Team”: se la nostra organizzazione è basata su team stabili, che magari lavorano insieme da tempo, la questione si può spostare sull’individuare il team più adatto e/o disponibile, piuttosto che sul crearne uno nuovo e preparare il relativo ambiente.

Personalmente, quando affronto una fase di Inception, specialmente se all’inizio dove generalmente è presente solo un’idea di massima dell’iniziativa, utilizzo un mio framework attuativo composta da 4 step(Inception in Action) con cui supporto la room a supporto del progetto focalizzandoci su:

• Indentificare lo Scope Iniziale, in modo da mettere a fuoco il cuore stesso della nuova iniziativa
• Sviluppare una Visione Comune, per avere una condivisione dei goal, frutto di un’approfondita discussione e di un confronto trasparente, e produrre un primo draft del Product Backlog
• Identificare i Rischi, azione troppo spesso sottovalutata in Agile
• Sviluppo di un Piano iniziale di Release, fondamentale per inquadrare le attività nel contesto del portfolio aziendale

Inception in Action

Per ognuno degli step è possibile usare una serie di strumenti e tool a supporto, che aiutano la concentrazione dei presenti e supportano la sintesi dei risultati.

Inception in Action

A questo punto, non vi resta che sperimentare e costruire il vostro framework per una Inception trasparente e di valore.

Stay tuned J

Siamo tutti concordi che uno degli elementi portanti del mondo Agile sia la capacità di ottenere e fornire rapidamente feedbackinerenti le azioni in essere, abilitando così tutti gli attori coinvolti ad un rapido riallineamento basato sulle evidenze.

Ma se i feedback non arrivano, come possiamo “spingere” le persone, i team o l’azienda stessa a condividerli, polarizzandone l’essenza in azioni di miglioramento? Come possiamo, in qualità di Coach o facilitatori, ricomporre il puzzle e ottenere valore dalle singole indicazioni?

Tra i diversi modelli di azione, uno dei più semplici e diretto è il COIN Model, acronimo che sta per:

• C – The Context(What, Where, When, Whom)
• O– What I Observedwas…
• I– The Impactof that was…
• N– How do you want to handle that differently NextTime? (or this is how I want you to handle it Next Time)

L’idea di base è quella di costruire una domanda sinteticache l’osservatore(non per forza il Coach) può porre rapidamente ad una persona per farla riflettere su un fatto o su un episodio specifico.

Facciamo qualche esempio:

• “Mario, ieri serie arrivato per l’ennesima volta in ritardo al Daily Meeting. L’impatto è stato quello di non consentire un proficuo allineamento del team e generare un successivo ping-pong di domande. Come pensi di gestire questa situazione la prossima volta?”
• “Andrea, Marina è venuta a dirmi che le hai detto di ritenerla all’altezza del suo compito e che non sa fare il proprio lavoro. L’impatto è stato quello di dover spendere con lei più di un ora per rasserenarla. Come pensi di evitare questa situazione la prossima volta?”

Il cuore dell’approccio è quello di focalizzare sui comportamenti (behaviours) e andare puntualmente nello specifico, evitando di essere superficiali o troppo generalisti nelle domante e nelle riflessioni.

Il feedback è un diritto/dovere: è doveroso far sapere ai colleghi la propria opinione, così come è un diritto conoscere il parere degli altri. Compito di un Coach è quello di rendere questa situazione trasparentee alimentarnecostantemente la relativa fiammella, tenendo sempre presenti alcune indicazioni basilari:

• Chiedere prima il permesso,un semplice “posso darti un piccolo feedback?”preparerà mentalmente il destinatario al messaggio che sta arrivando
• Essere tempestivo, il feedback deve essere temporalmente vicino all’evento, altrimenti si tratta solo di un “risentimento” che può addirittura avere l’effetto contrario
• Trovare un luogo privato, per evitare di dare feedback in pubblico e mettere a disagio il destinatario
• Essere calmi, ma urlare o alzare la voce: se si perde la calma si fallisce in partenza
• Essere interessati, chi da il feedback deve darlo perché si sente coinvolto e tiene al destinatario. È fondamentale farlo capire
• Essere tranquilli e silenziosi, aspettando pazientemente, e con attenzione, la risposta al feedback stesso, in modo da poter dare suggerimenti migliorativi adeguati
• Feedback diretto (faccia a faccia), un feedback va dato sempre il modo diretto, evitando di utilizzare strumenti tecnologici o “ambasciatori” che aumentano la distanza tra le parti

Lo ripetiamo da sempre: i feedback sono fondamentali! Se qualcuno si preoccupa di darveli, con onestà e trasparenza, vuol dire che si sta preoccupando per voi e dovete essergli grato per la sua attenzione.

Stay tuned J

Abbiamo imparato con il tempo a conoscere, e quasi tollerare, l’eterno dilemma e dibattito della “terza wave” dell’Agilità: Scaling or not Scaling?

Ci sono discussioni aperte in questo ambito che, probabilmente, non avranno mai fine, a partire da quella che deriva dalla più classica delle domande: “Qual è il miglior framework di Scaling?” Domanda che, dopo anni di sperimentazione sul campo, mi permetto di dire essere essenzialmente sbagliatanella formulazione stessa.

Scaling Frameworks

Non si percorre un percorso di trasformazione Agile affidandosi ad un framework o ad una metodologia in modo dogmatico, imbrigliando così la nostra capacità di reagire alle evidenze ed imparare da esse nel contesto specifico. Giusto per provare a chiarire in modo semplice: un framework dà delle linee guida lasciando ampio spazio di manovra alla contestualizzazione, una metodologia cerca di descrivere passo passo le azioni da compiere per ottenere un risultato. Calato nel mondo Agile possiamo fare due esempi molto esplicativi: Scrum è un framework, eXtreme Programming è una metodologia (qualcuno potrebbe storcere il naso, ma questo è quanto esplicitamente evidenziato in “Extreme Programming Explained”).

Ora, qual è il concetto base di quando parliamo di Scaling? Al centro c’è sicuramente l’ampiamento dell’ambiente di riferimento, amplificando direttamente i problemi tipici che negli approcci base (come ad esempio Scrum) sono concentrati sul singolo team.

Cosa significa comunicare tra più team? Cosa significa condividere la realizzazione di un prodotto tra più team? Sono solo esempi di domande a cui è necessario rispondere.

Ricollegandoci al Metodo Montessori, la dualità che risulta evidente è l’estensione degli interessi che ogni bambino concretizza nel secondo piano di sviluppo (che va dai 6 ai 12 anni). In tale piano, in cui il bambino si avvia verso l’età adolescenziale, si sviluppano tre necessità essenziali:

• Ampliamento, ovvero confrontarsi con uno spazio di riferimento più ampio rispetto a quello familiare che, in precedenza, era al centro della propria esistenza
• Astrazione, grazie alla quale il bambino comincia a fattorizzare le esperienze e a sviluppare “pattern mentali” che consentono di riportare nuove esperienze a quelle già vissute, riducendo il rumore delle “piccole differenze”
• Etica, si sviluppano i concetti di “giusto” e “sbagliato” in relazione alla cultura e all’ambiento specifico

Ampliamento, Astrazione, Etica

La condizione essenziale per permettere questa crescita è quella della libertà d’azione in un ambiente che però sia predisposto per svolgere la propria attività con intelligenza.

E qui torniamo alla discussione iniziale con cui abbiamo aperto: un framework di Scaling può sicuramente essere utile, astraendo diversi aspetti specifici e suggerendoci un modo di procedere che possa essere adattato al nostro contesto. Lo stesso deve però lasciare ampio spazio alla personalizzazione e alla possibilità di valutare rapidamente i risultati, in modo da essere “il proprio framework” e non “quello di…”.

Scoprire la propria Way of Working, è questo il senso del discorso, perché

tutti i framework di Scaling (o le metodologie) sono utili, ma tendenzialmente sono tutti sbagliati, essendo ogni contesto unico!

Lo Scaling si focalizza sull’Ampliamento dello spazio di riferimento, però questo non vuol dire per forza che le azioni devono complicarsi, potendosi estendere in relazione ai nuovi fattori (è un po’ il concetto di De-Scaling spesso invocato dai fautori di LeSS, ad esempio). Per fare questo, il concetto di Astrazione, così come rappresentato in pieno in Disciplined Agile, aiuta a tenere il punto nei vari ambiti, pur consentendo di scegliere la soluzione contestuale opportuna e rivederla rapidamente se non produce i risultati sperati. Il percorso è accompagnato dallo sviluppo di un’Etica che permette di costruire la propria Agilità, individuando gli strumenti, le azioni e le relazioni che dimostrano concretamente di funzionare. Si pensi ad esempio alla strutturazione multi-team di SAFe con un unico Product Backlog (e specifici Team Backlog), spesso presa a modello anche da altri framework di Scaling anche se con nomi diversi.

Ecco, questo è il punto focale: avere una Vision definita che viene rafforzata da quanto accade concretamente sul campo, dimostrandosi pronti a sperimentare in chiave Validate Learning con Actionable Metrics.

Stay tuned J

Tutti siamo stati studenti e tutti sappiamo quanto sia frustrante, una volta tornati a casa, non poter godere di quel senso di libertà fugacemente assaporato, perché ci si deve mettere subito sui libri per i fantomatici compiti a casa!

È una situazione classica in cui si prova a tenere impegnata la persona (studente) per tutta la giornata, con la convinzione che il suo scopo naturale sia quello di essere il più produttivo possibile, indipendentemente da tutto.

Le scuole Montessoriadottano un principio diametralmente opposto: “no compiti a casa!”. 

Ai più potrà sembrare una cosa strana, poco comune, ma l’idea di fondo è che sono i bambini stessi, spontaneamente, anche se lontani da scuola, a volersi occupare di ciò che li interessa. In pratica, il processo di apprendimento si estende nel proprio ambiente naturale, dove gli spazi e i materiali sono ancora più personali e plasmati sull’IO del bambino. Questo accade però, solo se il bambino ha voglia di farlo, altrimenti è libero di utilizzare il proprio tempo per altro, per le attività che ritiene meritevoli della sua attenzione.

Di fatto, non viene esercitata alcuna costrizione o alcun aspetto obbligatorio, cosa che contraddistingue lo spirito del piacere di imparare intrinseco nell’approccio Montessoriano, mettendo al centro il bambino invece di renderlo schiavo di un modello di istruzione estremamente prescrittivo e generalista.

Cosa succede se proviamo a “forzare” tutto questo? Se costringiamo gli studenti a fare ore di compiti a casa? L’impegno profuso diminuisce costantemente, fino ad avere un picco di discesa definitivo che rende le attività svolte molto superficiali. Inoltre, lo stesso non riuscirà a “ricaricarsi” e questo si ripercuoterà inevitabilmente il giorno dopo a scuola, creando un circolo vizioso che trascinerà l’apprendimento nella direzione opposta rispetto alle premesse che lo ha generato.

Se ci catapultiamo nel mondo Agile, il riferimento che immediatamente salta all’occhio è l’ottavo Principio:

I processi agili promuovono uno sviluppo sostenibile.
Gli sponsor, gli sviluppatori e gli utenti dovrebbero essere in grado di mantenere indefinitamente un ritmo costante.

In pratica, dobbiamo essere in grado di identificare il nostro ritmo per poterci esprimere al massimo nelle attività che affrontiamo. Se, al contrario, proviamo a “spremere” continuamente tutte le nostre energie, ci ritroveremo ben presto ad osservare un inesorabile calo di produttività che avrà un effetto devastante su noi stessi, prim’ancora che sul nostro lavoro.

Productivity and Overtime

Come ripetiamo sempre, il cuore dell’Agilità è nelle evidenze e nei feedback, per cui i team provano continuamente a tarare il proprio ritmo, anche utilizzando strumenti o tecniche di cui spesso si dimentica la reale essenza. Si pensi al WIP limit (Work in Progress limit) di Kanban: il suo scopo nobile è proprio quello di trovare il ritmo di lavoro sostenibile dal team. Peccato, però, che spesso venga utilizzato per “valutare” il team dall’esterno, comparando, ad intervalli di tempo regolari, il numero di task attivi parallelamente: più task, più si è bravi. Niente di più errato e forviante può essere fatto… anzi si.. fare la stessa comparazione tra due team diversi!

Stesso discorso, spesso ancora più marcato, per la Velocity: “ma il Red Team ha una velocity più bassa del Blue Team, quindi sono più bravi!” nulla di più insensato! La velocity è del team per il team, da usare solo per Improvement e non per comparazioni relative. Se il team volesse fare il “furbetto”, basterebbe aumentare le stime e la situazione si ribalterebbe.

La realtà è che i “veri” team Agili guardano alla produttività, o meglio ancora al Valore generato, di qualità e sostenibile, altrimenti si rischia di spezzare quella “magia” che permette ad un team di essere il cuore pulsante di una organizzazione.

Stay tuned J