Category Archives: TFS

Agile e Robotic Process Automation (RPA), parte 3 – Flow Chart Mapping

Ci eravamo aggiornati lasciando in sospeso la discussione sul risultato del primo Sprint. 

Ebbene vediamo com’è andata.

Il team ha lavorato molto bene, sviluppando una prima timida sinergia che, anche in relazione alla composizione dello stesso (che vi ricordo era fatta di Persone afferenti a 4 player diversi), di per sé è già un buon risultato che merita dei kudo.

Se veniamo invece alle Technical Story (TS), la situazione si è rilevata un po’ più difficile da comprendere: infatti, se è vero che la maggior parte delle TS sono state completate, è anche vero che è risultato abbastanza difficile rappresentare il valore reale di quanto realizzato. Questo perché le Storie sono subito apparse come “isolate” e, rappresentando tasselli di un flow di esecuzione automatizzato, non è stato possibile valutare nessuna esse in senso atomico e da un punto di vista esplicitamente funzionale.

[Terza Considerazione] Abbiamo quindi appreso una nuova lezione: la review tradizionale non è particolarmente utile nell’accezione comunemente nota. Dimostrare il valore di una TS in modo isolato non ha un grande valore, inoltre il PO, Process Owner (come detto nel post precedente), accompagna il team giornalmente nell’analisi degli elementi di dettaglio del processo, per cui alla fine avrà già una visione completa di quanto realizzato.

Quello invece che è risultato interessante è stata la visualizzazione del data-set ottenuto dall’esecuzione del primo flow parziale realizzato. In pratica si è costruita una semplice vista che, evidenziando di volta in volta il passaggio completato, metteva a confronto lo stato in ingresso con quello in uscita, consentendo al PO di valutare la correttezza del risultato e ponendo le basi per una successiva validazione automatizzata (un RPA dell’RPA J).

A questo punto si è tenuta la prima retrospettiva (classico Strafish) e la problematica primaria affrontata è stata quella di capire come rappresentare in modo più efficace la visione d’insieme e le diverse specializzazioni verticali. In pratica, come riuscire a sfruttare un tool tipo User Story mapping, che però risultava poco efficace rispetto alle più volte sottolineate caratteristiche delle Tecnical Story. La soluzione individuata è stata quella di ricorre ad una rappresentazione grafica del processo, attraverso uno dei più classici strumenti che si conosca: un flow chart.

flow chart mapping

Questo strumento è stato introdotto nel planning dello Sprint 2, consentendo al team di discutere visivamente del processo e andare a esplicitare i 5 elementi di riferimento di ogni Technical Story: Sottosistemi coinvolti, Dati in ingresso attesi (tipologia e set campione per il test), Dati in uscita attesi (tipologia e set campione per il test), Gate di ingresso e Gate di uscita.

 [Quarta Considerazione] Alcuni strumenti comunemente utilizzati per il mapping delle Storie, vanno opportunamente rivisti, considerando gli aspetti tecnici delle storie. In particolare, l’uso del Flow Chart Mapping (FCM) rende subito visibile il flusso dati e i gate di input/output di ogni storia, consentendo una facile valutazione dei risultati.

L’FCM ha permesso al nostro speciale PO, Process Owner, di descrivere il sotto-flow atteso per lo sprint, in funzione dei dati di input di start e quelli di output in end. A questo punto il team si è rituffato nello sviluppo!

Nel prossimo post, che chiuderà la serie, vedremo come sono andati gli sprint successivi e faremo una serie di considerazioni finali.

 

 

Stay tuned J

Agile e Robotic Process Automation (RPA), parte 2 – Il ruolo del PO

Ed eccoci arrivati allo start del primo Sprint!

Dopo aver dedicato alcuni incontri a parlare di Agilità, soffermandoci sui Valori e sui Principi, e aver illustrato il framework Scrum (come detto scelto a livello Corp), il team è pronto per iniziare a sperimentare sul campo e costruire il primo draft di Product Backlog.

Bisogna dire che l’obiettivo complessivo era quello di automatizzare tramite RPA 6 processi con diversi livelli di complessità e che, mediamente, essi interessavano almeno 3 sistemi di gestione differenti. Il grande vantaggio nella fase di Inception è stato quello di avere un neo-PO estremamente esperto di ogni singolo processo, in grado di descrivere in modo minuzioso ogni step relativo e il set di dati fondamentali.

[Prima Considerazione] Ecco quindi una prima considerazione rispetto al tradizionale ruolo di PO: essendo l’obiettivo dell’RPA l’automazione della mimica relativa ad un processo, non si ha nella sostanza un utente utilizzatore, ma solo un “committente” che si aspetta un lavoro finito.

po role reponsability

La validazione di quanto realizzato può essere fatta confrontando i risultati di ogni step con quelli analoghi fatti da un operatore umano (subFlow), o valutando l’intero flow.

Il PO, in questo scenario, non si occupa di formalizzare needs funzionali (sotto forma di Storie o altro), ma, più che altro, è un esperto di processo/dominio/data in grado di descrivere una sorta di flow chart (activity diagram) che consente di suddividere adeguatamente i passi costituente del processo.

Potremmo dire che è più un Process Owner che un Product Owner.

po rpa

Tornando al nostro Product Backlog, è stato deciso di identificare ogni processo da automatizzare come “prodotto” differente, dotato quindi di uno specifico Product Backlog. Per ogni prodotto sono state create una serie di Technical Story (lo so, qualcuno storcerà il naso, ma noi abbiamo ritenuto giusto così) in relazione agli step di avanzamento del processo, individuandone gli aspetti caratterizzanti primari:

  • Sottosistemi coinvolti
  • Dati in ingresso attesi (tipologia e set campione per il test)
  • Dati in uscita attesi (tipologia e set campione per il test)
  • Gate di ingresso 
  • Gate di uscita

Quando la prima versione del Product Backlog è stata completata, il team si è trovato difronte alla necessità di scegliere su quali Tech Story ingaggiarsi nel primo Sprint. In questo caso, non avendo una “storia passata”, si è optato per lasciare allo stesso la scelta di un numero di storie che ritenevano “aggredibili”, senza impiegare tempo in stime o pesi che non potevano avvalersi di alcuna esperienza pregressa e rimandando la “prima pesatura” a consuntivo.

Ogni Tech Story è stata suddivisa, durante il successivo Sprint Plannig, in Task di dettaglio, in cui sono state esplicitate le attività di implementazione e le differenti aree di sviluppo tecniche interessate. Quest’ultimo aspetto è stato fondamentale per gestire la pluralità del team (come descritto nel primo post della serie) e calibrare la loro permanenza in-house, non necessariamente di 5gg a settimana.

Completato il tutto, il team ha cominciato a lavorare sulle singole Technical Stories, adottando la strategia Serial-and-Parallel: il team avvia la prima Storia e lavora in parallelo sui Task di dettaglio e solo in caso qualcuno sia scarico si avvia la successiva Storia, altrimenti ci si concentra sul finirne una alla volta. In tal modo si riduce sensibilmente il rischio di avere troppe Storie avviate e finite solo parzialmente a fine Sprint.

Anche qui è stato riscontrato subito un punto dolente: il rispetto delle priorità indicate dal Product Owner (e implicitamente dal processo). I membri del team hanno ritenuto opportuno rivederle più volte per sbloccare situazioni di stallo dovuto a condizioni tecniche abilitati.

[Seconda Considerazione] Da qui una seconda considerazione operativa: la priorità delle Technical Story è implicitamente dettata dal flow del processo e deve essere possibile rivederla liberamente senza vincoli, in funzione delle esigenze di sviluppo. Quindi non è più utile che sia nelle more del PO!

Detto questo, il team ha utilizzato le canoniche due settimane, allineandosi giornalmente nel classico Daily, per completare quante più Technical Story possibili, con una presenza attiva del PO per rispondere a problematiche di processo/sistema/dati.

Volete sapere com’è andata? Beh.. non vi resta che attendere il prossimo post della serie.

Stay tuned J

Two tech events in Parma, the city of food

SQL Saturday Parma, six years in a row. DevOpsHeroes, four. Parma has been a great place to reach, also for technical events. I’ve started organizing the first SQL Saturday in my birthplace in November 2014. After two years I tried to create a brand-new event, when the DevOps culture started to grow and when the … Continue reading Two tech events in Parma, the city of food

Agile e Robotic Process Automation (RPA), parte 1

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.

rpa process mimic

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.

rpa board1rpa board2

(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

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