Category Archives: Visual Studio

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

Deploy a new IIS Web Site with Azure DevOps Pipelines

I was experimenting with deploying a completely new Web Site to a machine with a brand new IIS installation to see what are the required parameter to do a basic deployment.I share here my findings. The best approach is to deploy with a deployment group job. This way can use the IIS tasks that Microsoft… Continue reading Deploy a new IIS Web Site with Azure DevOps Pipelines

Agile Montessori, attività sostenibili

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!

agilemontessori homework

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

agilemontessori overtime productivity

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.

agilemontessori velocity wrong

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