Category Archives: TFS

Nello scorso appuntamento abbiamo affrontato gli elementi caratterizzanti della fase di Inception, in cui il sistema da realizzare viene “inizializzato” con un approccio Lean like, avvalendosi di un approccio ispirato almetodo 3P (Production, Preparation e Process) che consente al team di lavoro di sviluppare quanto necessario per creare la dorsale della specifica soluzione

In questo secondo appuntamento della serie, inizieremo a parlare della fase di Engineering in cui il prodotto viene implementato nei diversi aspetti funzionali customer side, seguendo una logica più tipicamente Agile.

Questa fase viene guidata da un “albero funzionale”, elemento di output/outcome della precedente fase di inception, in cui sono state definiti, a livello medio-alto, le diverse componenti caratterizzanti il sistema.

Albero Funzionale

L’utilizzo dell’albero funzionale aiuta a focalizzarsi sulle funzionalità da realizzare in relazione alle necessità del cliente, favorendo l’organizzazione in team cross-funzionali. Si tratta di un aspetto molto delicato, soprattutto nell’ambito dell’ingegneria di sistema che, normalmente, si basa su una forte settorializzazione delle competenze e suddivisone delle attività in “working-package” affini (leggasi WBS).

L’albero funzionale è chiaramente accompagnato da una vista architetturale che aiuta a capire i componenti da utilizzare per l’implementazione delle funzionalità richieste, permettendo di fare una prima valutazione di fattibilità e sostenibilità, alla base anche delle attività di sviluppo della dorsale, già presentate nella discussione inerente la fase di Inception.

Tornando ai team, la loro composizione è un aspetto particolarmente delicato da curare: generalmente, si hanno più team concentrati su parti funzionali del sistema che però non hanno un contatto continuativo con il cliente finale, anche perché per quest’ultimo l’oggetto minimo da poter valutare è una Capability, che rappresenta un sotto-insieme funzionale (ma anche a livello di componenti) significativo. Tale Capability ha tipicamente un tempo di sviluppo ampio, che può superare anche l’anno, per cui bisogna trovare il modo di spostare il focus di review e allineamento quanto meno sulle Feature (che hanno ragionevolmente una declinazione temporale di qualche mese) .

Anche in questo caso, comunque, si hanno intervalli di tempo considerevolmente più ampi di quanto generalmente previsti nel mondo Agile (2, 3 settimane di media), cosa che porta a riconsiderare il ruolo di Product Owner di ogni team più in un ottica di Engineer Owner che aiuta il team nel dettaglio delle attività e nel coordinamento con gli altri team o aree di lavoro coinvolte. Viene quindi a configurarsi una “product ownership board” composta dagli Engineer Owner, generalmente uno per ogni team che, nell’insieme, si coordinano con il Product Owner (di prodotto) che li supporta nelle relazioni con il cliente e nella revisione dell’Agile Portfolio tramite il quale vengono definiti gli obiettivi nei diversi riferimenti temporali (Annuale, Quarter, Mensile, Iterazione, ecc), nonché i backlog operativi.

In particolare, la vista dei diversi backlog viene implementata tramite la cosiddetta Flight Level Architecture, in cui si passa dal livello Strategico a quello Operativo (e viceversa) per una completa visione di come sta progredendo lo sviluppo del prodotto.

The Flight Levels Architecture

Si ottengono quindi una serie di Backlog a diversa granularità e con ownership affidate a gruppi di coordinamento che partono dal basso (buttom-up) ma che sono supportati e coordinati da figure progressivamente più business/holistic related.

L’MBI, ovvero il Minimum Business Increment, riportato nel backlog centrale della figura precedente, rappresenta un elemento atomico che ha significato dal punto di vista del business, ovvero sia per il cliente ma anche per il business. Su di esso c’è il vero focus di sviluppo in chiave ross-disciplinare (software, elettronico, meccanico, chimico, ecc), grazie ad una sua progressiva scomposizione che da vita al backlog operativo (quello più a destra nella figura precedente) che va ad esplicitare gli interventi diretti da realizzare sul prodotto.

L’MBI viene scomposto in funcionality, a loro volta scomposte in work item (sempre cross-dominio), che vengono presi in carico da un team in grado di completarne tutti gli aspetti.

Un team che si ispira ad AgileEngineering è, quindi, un team composto da esperti dei vari settori afferenti che si coordinano tra loro per completare qualcosa di significativo funzionalmente parlando, abbattendo notevolmente la complessità di integrazione e di test che si riscontra quando lo sviluppo è invece centrato su componenti di dominio realizzati in modo indipendenti tra loro.

Nel prossimo appuntamento continueremo a parlare della fase di Engineering affrontando gli aspetti di integrazione, testing e il relativo supporto dagli specialist extra-team.

Stay tuned :-J

Nello scorso appuntamento abbiamo affrontato gli elementi caratterizzanti della fase di Inception, in cui il sistema da realizzare viene “inizializzato” con un approccio Lean like, avvalendosi di un approccio ispirato al metodo 3P (Production, Preparation e Process) che consente al team di lavoro di sviluppare quanto necessario per creare la dorsale della specifica soluzione

In questo secondo appuntamento della serie, inizieremo a parlare della fase di Engineering in cui il prodotto viene implementato nei diversi aspetti funzionali customer side, seguendo una logica più tipicamente Agile.

Questa fase viene guidata da un “albero funzionale”, elemento di output/outcome della precedente fase di inception, in cui sono state definiti, a livello medio-alto, le diverse componenti caratterizzanti il sistema.

Albero Funzionale

L’utilizzo dell’albero funzionale aiuta a focalizzarsi sulle funzionalità da realizzare in relazione alle necessità del cliente, favorendo l’organizzazione in team cross-funzionali. Si tratta di un aspetto molto delicato, soprattutto nell’ambito dell’ingegneria di sistema che, normalmente, si basa su una forte settorializzazione delle competenze e suddivisone delle attività in “working-package” affini (leggasi WBS).

L’albero funzionale è chiaramente accompagnato da una vista architetturale che aiuta a capire i componenti da utilizzare per l’implementazione delle funzionalità richieste, permettendo di fare una prima valutazione di fattibilità e sostenibilità, alla base anche delle attività di sviluppo della dorsale, già presentate nella discussione inerente la fase di Inception.

Tornando ai team, la loro composizione è un aspetto particolarmente delicato da curare: generalmente, si hanno più team concentrati su parti funzionali del sistema che però non hanno un contatto continuativo con il cliente finale, anche perché per quest’ultimo l’oggetto minimo da poter valutare è una Capability, che rappresenta un sotto-insieme funzionale (ma anche a livello di componenti) significativo. Tale Capability ha tipicamente un tempo di sviluppo ampio, che può superare anche l’anno, per cui bisogna trovare il modo di spostare il focus di review e allineamento quanto meno sulle Feature (che hanno ragionevolmente una declinazione temporale di qualche mese) .

Anche in questo caso, comunque, si hanno intervalli di tempo considerevolmente più ampi di quanto generalmente previsti nel mondo Agile (2, 3 settimane di media), cosa che porta a riconsiderare il ruolo di Product Owner di ogni team più in un ottica di Engineer Owner che aiuta il team nel dettaglio delle attività e nel coordinamento con gli altri team o aree di lavoro coinvolte. Viene quindi a configurarsi una “product ownership board” composta dagli Engineer Owner, generalmente uno per ogni team che, nell’insieme, si coordinano con il Product Owner (di prodotto) che li supporta nelle relazioni con il cliente e nella revisione dell’Agile Portfolio tramite il quale vengono definiti gli obiettivi nei diversi riferimenti temporali (Annuale, Quarter, Mensile, Iterazione, ecc), nonché i backlog operativi.

In particolare, la vista dei diversi backlog viene implementata tramite la cosiddetta Flight Level Architecture, in cui si passa dal livello Strategico a quello Operativo (e viceversa) per una completa visione di come sta progredendo lo sviluppo del prodotto.

The Flight Levels Architecture

Si ottengono quindi una serie di Backlog a diversa granularità e con ownership affidate a gruppi di coordinamento che partono dal basso (buttom-up) ma che sono supportati e coordinati da figure progressivamente più business/holistic related.

L’MBI, ovvero il Minimum Business Increment, riportato nel backlog centrale della figura precedente, rappresenta un elemento atomico che ha significato dal punto di vista del business, ovvero sia per il cliente ma anche per il business. Su di esso c’è il vero focus di sviluppo in chiave ross-disciplinare (software, elettronico, meccanico, chimico, ecc), grazie ad una sua progressiva scomposizione che da vita al backlog operativo (quello più a destra nella figura precedente) che va ad esplicitare gli interventi diretti da realizzare sul prodotto.

L’MBI viene scomposto in funcionality, a loro volta scomposte in work item (sempre cross-dominio), che vengono presi in carico da un team in grado di completarne tutti gli aspetti.

Un team che si ispira ad AgileEngineering è, quindi, un team composto da esperti dei vari settori afferenti che si coordinano tra loro per completare qualcosa di significativo funzionalmente parlando, abbattendo notevolmente la complessità di integrazione e di test che si riscontra quando lo sviluppo è invece centrato su componenti di dominio realizzati in modo indipendenti tra loro.

Nel prossimo appuntamento continueremo a parlare della fase di Engineering affrontando gli aspetti di integrazione, testing e il relativo supporto dagli specialist extra-team.

Stay tuned :-J

Uno dei dubbi che sorge immediatamente quando si parla di Agile applicato nell’ambito dell’Ingegneria di Sistema è come sia possibile sviluppare in modo iterativo un sistema complesso, spesso visto come un tutto o niente, e composto da elementi fisici la cui duttilità è tutt’altro che un elemento da sottovalutare.

Spesso, l’approccio seguito, è quello di concentrarsi sulla realizzazione di prototipi-successivi, in cui, di volta in volta, si raffinano aspetti specifici dei diversi componenti per poi arrivare al “Primo di Serie” e alla specifica definizione della Bill of Materials.

Per districarsi con questo aspetto, AgileEngineering individua una specifica fase di Inception, in cui vengono confutati gli aspetti primari della soluzione e realizzata la dorsale di sviluppo necessaria a dare lo start operativo di dettaglio.

In questa fase, un approccio Lean based risulta fondamentale, data la variabilità delle azioni da realizzare e la sperimentazione che generalmente caratterizza in questo frangente il prodotto in modo predominante.

Operativamente, ci si avvale di un approccio ispirato al metodo 3P (Production, Preparation e Process), fondato su un processo rigoroso e strutturato che consente alle organizzazioni di concentrarsi sulla riduzione dei rischi e incrementare la capacità di validare rapidamente le ipotesi inerenti ai propri prodotti e i processi.

Lean 3P

L’idea di fondo è quella di raffinare le assunzioni iniziali per poter raggiungere una condizione di progressiva confidenza “nel come” e “nel cosa” realizzare, con particolare riferimento ad un nuovo prodotto e alle attività di gestione annesse. Il tutto passa attraverso la creazione di una serie di “potenziali soluzioni” che permettono di diminuire le opzioni disponibili e concentrarsi, alla fine, solo su quella che, dati i vincoli, gli obiettivi, e l’organizzazione specifica, risulta più confacente. 

In tal modo i prodotti, dopo la fase di Inception, risultano meno complessi, più facili da produrre e, in ultimo, dovrebbero essere anche più facili anche da usare e manutenere.

A differenza dei metodi per il miglioramento continua a piccoli passi (Kaizen in primis), il 3P è orientato ad ottenere rapidamente miglioramenti su ampia scala, consentendo di migliorare le prestazioni ed eliminare gli sprechi a livello di sistema.

L’azione è affidata ad un gruppo eterogeneo di persone, un team (team 3P), che generalmente opera per più giorni con un focus su un compito specifico. L’obiettivo è proprio quello di sviluppare un design di prodotto che soddisfi al meglio le esigenze dei clienti in modo sostenibile.

In pratica è come se i principi Lean, generalmente pensati per l’ottimizzazione dell’as-is e la riduzione degli sprechi, subiscano un effetto di shift-left, agganciandosi allo sviluppo di nuovi prodotti e trovando applicazione nel momento in cui le decisioni possono avere la maggiore influenza sia sul prodotto che sul funzionamento.

Volendo guardare più nel dettaglio il metodo 3P, possiamo identificare una serie di passi caratterizzanti:

• Definizione degli Obiettivi: il “team 3P” cerca di comprendere le principali esigenze del cliente da soddisfare. Il team procede a scomporre la visione di alto livello nelle componenti primarie, in termini funzionali/tecnologici/di processo, per valutarne il contributo individuale;
• Definizione del Flusso Realizzativo: viene disegnato il flusso di realizzazione che porta dai requisiti di alto livello alla relativa implementazione. In questa fase si evidenziano anche le fasi di trasformazione dalle materie prime annesse. Il team 3P è quindi in grado di analizzare ogni diramazione del flusso e fare un brainstorming sui punti critici annessi;
• Ricerca delle Similarità: il team 3P osserva soluzioni simili, artificiali o naturali, per “assorbire” le soluzioni note e concentrarsi sulle vere innovazioni da attuare;
• Definizione e Valutazione del Processo: il flow realizzativo viene scomposto nei costituenti e vengono, eventualmente, creati nuovi team per approfondire i dettagli e identificare il set minimo di opzioni più plausibili;
• Definire un Piano di Implementazione: il team individua un piano di sviluppo di massima in modo da valutare i tipici constraints di tempo/budget ed identificare le figure personali richieste;
• Sviluppare gli Asset Portanti: il team può ora concentrarsi sullo sviluppo dei componenti portanti, sviluppando un set di varianti per assicurarsi di individuare quella che più soddisfa le aspettative.

Va sottolineato che tali passi non sono un “must”, ma vanno declinati in relazione al contesto e al progetto specifico.

L’insieme degli asset realizzati, unitamente al piano desiderato, costituiranno il passe-partout per passare alla fase di Construction, fase in cui il tutto verrà sviluppato nel dettaglio e rifinito in modo iterativo ed incrementale per ottenere il prodotto definitivo in grado di soddisfare l’utente e che sia, chiaramente, industrialmente sostenibile.

Il punto cardine del 3P è la capacità di generare know-how tra i membri del team e tra il team ed il cliente, spingendo all’innovazione sostenibile continua, così come ben riportato nel libro “The Lean 3P Advantage: A Practitioner’s Guide to the Production Preparation Process” di Allan Coletta che è tutt’ora di riferimento per la tematica.

Stay tuned

So, after different months of works, we are happy to announce DisciplinedAgile@University!

This is the first time that there is a real concrete opportunity for master’s degree students in Software Engineer to take an Agile Certification course (DASM) and become a PMI DA Certified Scrum Master. We will have onboard about 70students!

This designation will help them to have more opportunities to enter faster in the world of work, and improve their approach to problem solving in relation to complex situations.

This was made possible thanks to the collaboration with the Università degli Studi di Napoli Federico II (Naples, Italy), specially with prof. Anna Rita Fasolino, and the Project Management Institute (thanks Keren Moses Deront) that support us in this initiative and it’s actively part of it.

A great journey for new Agile passionate…. stay tuned for more information. We will start in the second half of may!

Scott W. Ambler, Mark Lines

#pmi #disciplinedagile Xebir Innovation

Riflettevo con alcuni colleghi di quanto ancora oggi si cerchi di inquadrare, sempre e comunque, la capacità di innovare in un “metodo” o in una “ricetta” da seguire pedissequamente.

La realtà dei fatti è che le organizzazioni, i team, le persone sono spesso molto diversi tra loro e l’idea di legarsi in modo dogmatico ad un unico strumento è, di per sé, la negazione stessa dell’Agile in quanto approccio adattativo che fa dell’empirismo la sua migliore arma.

Negli anni si sono diffusi molti bias a riguardo: “questo è meglio di quello”, approccio “tradizionale” o approccio “moderno”, “buoni” e “cattivi”, in realtà ogni evoluzione è spesso la sintesi di sperimentazioni trasversali, di tentativi di individuare possibili soluzioni allo stesso problema che partono da prospettive diverse e ne colgono sfumature che aiutano a comporre il quadro generale.

L’approccio di apertura e di contestualizzazione permette effettivamente di incamminarsi lungo il sentiero della Business Agility in modo efficace, riconoscendo che ci saranno sempre degli ostacoli lungo di esso e che bisognerà fermarsi, capire come superarli, e fare diversi tentativi, ricorrendo alle proprie esperienze e a quanto si è appresso.

Ogni ostacolo superato è un nuovo traguardo nel proprio viaggio che porta a sperimentare e rimettersi continuamente in gioco.

Ecco l’essenza della Business Agility, ovvero la capacità di non “imbrigliare” le persone, e di conseguenza le organizzazioni, in una rete, ma di sviluppare un Clima Organizzativo in grado di stimolare una innovazione continua e dare l’impulso alla strutturazione di una Cultura Organizzativa che renda il tutto “the new normal” da cui ripartire.

agileconstellation.info – agileengineering.info

Il mondo dell’Ingegneria dei Sistemi è continuamente alla ricerca di nuovi modelli operativi che consentano di innovare rapidamente i propri prodotti, efficientando al contempo la filiera produttiva.

Tipicamente, in essa, si adotta un lifecycle lineare che segue degli step sequenziali ben definiti e rappresentato nel cosiddetto modello a V caratterizzato da 2 flussi:

• Flusso di Specifica, che si esplica nelle attività a sinistra
• Flusso di Prova, che si sviluppa lungo la direttrice destra 

I due flussi sono collegati dall’implementazione, dove gli artefatti vengono realizzati.

Questo modello è, però, scarsamente flessibile, con una netta divisione tra progettazione/pianificazione ed implementazione, rendendo costose le modifiche e l’adattamento alle esigenze emergenti.

Resta quindi intrinseca la fragilità dovuta al dettaglio dei requisiti, che si scontra con la realtà dove i clienti riescono a capire ciò che realmente vogliono solo nelle fasi più avanzate di realizzazione del prodotto, proprio dove i costi del cambiamento diventano spesso proibitivi. 

Inoltre, i progetti sono spesso di lunga durata (più anni) e impattano su molti domini differenti, il che enfatizza fortemente l’importanza e la complessità della governance generale e dell’integrazione dei vari elementi costituenti afferenti.

Questi elementi sono fortemente radicati nell’ambito dell’ingegneria dei sistemi e l’Agilità si concretizza nel metaforico azzeramento dell’angolo della V, azione grazie al quale il flusso di specifica e il flusso di testtendono a sovrapporsi completamente, sposando al loro interno le attività di sviluppo, senza inoltre ricorso a team esterni. Ciò permette di velocizzare il sistema dei feedback, in particolare quelli provenienti dai clienti, in modo da catturare gli immancabili cambiamenti da apportare quando ancora il prodotto è in una fase “grezza”, dove i costi annessi sono meno dirompenti.

AgileEngineering supporta operativamente questi aspetti, stimolando i team di ingegneria nell’adozione di una logica “fail fast” (o succeeding fast) su sviluppi coesi, orientati ad obiettivi specifici che si sviluppano su elementi validabili di breve, medio e lungo termine.

Essendo i prodotti dell’ingegneria di sistema dei “manufatti tangibili”, AgileEngineering suggerisce di dividere le fasi operative di sviluppo in tre momenti specifici: Inception, Engineering e Workout. 

In particolare, nella fase di Inception viene realizzato quanto necessario per validare il sistema che ci si appresta a realizzare, focalizzandosi sullo sviluppo di quei componenti abilitanti che ne costituiranno l’infrastruttura portante. In tal modo si ha una fase di “discovery”, spesso caratterizzata da un approccio Lean-based, che consente confronti rapidi con gli stakeholder.

Si adottano, quindi, metodi di rapid prototyping, sfruttando tecnologie emergenti (come, ad esempio, Stampa 3D e Realtà Mixata) in modo da ridurre i costi e consentire di sviluppare rapidamente nuovi prototipi tangibili con cui ingaggiare gli utenti e raccogliere feedback. In questo ambito il ricorso all’MVP (Minimum Viable Change), inteso nella sua corretta accezione di strumento per l’apprendimento, è fondamentale e supporta il tutto in modo concreto.

Quando si è raggiunta una condizione di relativa stabilità, si procede all’Engineering delle parti più malleabili (ovvero le componenti più facilmente evolvibili), apportando gli opportuni sviluppi di consolidamento su quelle meno duttili (ad esempio, la componentistica standard acquisito dal mercato).

Infine, la fase di Workout si occupa di gestire la produzione industriale (di serie) del tutto e di governare gli aspetti di delivery, nonché quelli di esercizio.

L’operatività nelle diverse fasi è affidata a team multidisciplinari, ovvero team composti da un mix di esperti nelle discipline coinvolte (elettronica, meccanica, chimica, software, ecc), che portano avanti le diverse attività necessarie per implementare le capability che caratterizzano il prodotto. 

La sfida di AgileEngineering è quella di utilizzare tutte le tecniche note del mondo Agile e Lean, per favorire la comunicazione nei team e tra i team, in cui, come detto, ci sono esperti di domini diversi spesso abituati a lavorare in relazione ai propri skill più che in funzione di un obiettivo di prodotto che guardi al cliente finale. A tal fine, per favorire la creazione di una “lingua comune”, è fondamentale il ricorso agli strumenti di Visual Management, come task board o, nei casi più evoluti, un vero e proprio approccio Kanban-like che consenta di massimizzare sia la trasparenza sullo stato delle attività, sia l’individuazione dei colli di bottiglia su cui intervenire il prima possibile.

Grazie ad AgileEngineering è possibile ridurre i rischi di diventare non competitivi, andando a stimolare un approccio adattativo in grado di ridurre il lead time e generare soluzioni innovative mantenendo fermi gli standard di qualità di riferimento. Infatti, non bisogna sottovalutare l’impatto che le normative di rifermento hanno sul processo generale, essendo spesso vincolanti e non derogabili per la commercializzazione e l’uso del prodotto stesso.

In conclusione, è possibile affermare che i principali vantaggi che si osservano nell’adozione di AgileEngineering sono:

• Riduzione del Lead Time, del Time to Market e del Time to Value, grazie all’introduzione di strumenti di fast prototyping e l’utilizzo organico dell’MVP
• Miglioramento dell’efficienza dei processi o workflow, sfruttando soluzioni ispirate all’Agile e a Lean, unitamente alla loro visualizzazione esplicita.
• Riduzione del gap comunicativo tra i team di ingegneria e gli stakeholder, grazie allo sviluppo di feedback rapidi e momenti di allineamento costanti.
• Miglioramento della qualità, sia “reale” che “percepita”.

Alcune declinazioni specifiche dell’ingegneria di sistema riguardano, ad esempio, l’Automotive, l’Aerospace, le aziende Missilistiche, le aziende dei Medical Device e così via.

Ognuno di questi domini può trarre vantaggi evidenti da quanto evidenziato fin ora, declinando ulteriormente le specificità nel proprio contesto e identificando gli strumenti espliciti che meglio supportano la visione complessiva e l’operatività corrente.