Category Archives: Visual Studio

Agile Montessori, l’armonia della perfezione

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).

agilemontessori bimbo puliza

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.

agilemontessori kotter

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.

agilemontessori mngt30

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 :)

La dissipazione dei bug

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)

bugs remove asap

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à 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à 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

Reduce your build time with parallelism in Azure DevOps

A faster CI process with parallelism in Azure DevOps.

Continuous Delivery e Continuous Deployment, proviamo a fare chiarezza

Termini come Continuous IntegrationContinuous DeliveryContinuous DeploymentDevOps, 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 compilazionetestdeployconsente a tutti gli attori coinvolti di stabilire se è possibile approvare un rilascio immediato in qualsiasi ambiente
  • L‘automazione del processo di buildtestdeployè 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, affidabilielastiche, 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:

cd ci old

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:

 

cd ci

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

Stay tuned J

La dissonanza dogmatica della distanza

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 1

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

retrium 2

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 3

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.

retrium 4

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

La rotta comunicativa per l’Isola che non c’è

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.

islands

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 sostenibile di informazioni a disposizione di tutti.

knwoledge island

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

La negazione dell’evidenza iniziale

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 SchwaberSutherlandnon 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 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 2019

DAD Inception Goals

Per esperienza diretta, così anche come raccontato da AmblerLines(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 1

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 2

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

La polarizzazione dei feedback paganti

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:

  • – 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)

coinmodel

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 trasparentealimentarnecostantemente 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

DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 01 – development (part 1)

Intro As a consultant, life could be difficult when it comes to manage platform like Vertica, a columnar RDBMS by MicroFocus. Speaking about DevOps, database management systems like this one neither is well supported by built-in tools nor by any third party suites. In my experience, which is focused on the Microsoft SQL Server world, … Continue reading DevOps journeys series – Vertica release pipeline with Azure DevOps – Ep. 01 – development (part 1)

Agile Montessori, ampliare l’ambiente

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.

agilemontessori scaling

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 frameworkeXtreme 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

agilemontessori astrazione ampliamento sensomorale

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