Author Archives: Felice Pescatore

2cents on Business Agility

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.

business agility icon

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.

AgileEngineering, l’Agile nell’Ingegneria dei Sistemi

AgileEngineering logo

agileconstellation.infoagileengineering.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.

v model

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: InceptionEngineering e Workout

agileengineering poster

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.

AgileBIM: dalla teoria alla pratica, il caso ArchLivIng

Nei precedenti post della serie sono stati raccontati gli elementi essenziali di AgileBIM, descrivendo come esso sia stato sperimentato e raffinato per poter rispecchiare il contesto specifico del mondo delle Costruzioni, restando però fedeli al mindset Agile, in particolare ai suoi Valori e Principi portanti.

Più volte è stato ribadito che si è trattato di una sperimentazione, per cui è interessante far riferimento al caso concreto di ArchLivIng in cui si è proceduti ad una riorganizzazione dei team di lavoro in chiave Agile

ArchLivIng è un’azienda con sede a Ferrara, leader, in particolare, nel campo del Design ed in forte espansione. Proprio in quest’ottica, ha deciso di rivedere il modo in cui i propri specialisti affrontano la gestione di un progetto, dal suo concepimento alla sua definizione esecutiva, offrendo inoltre servizi diretti di gestione dei cantieri laddove le attività in carico si estendano oltre la progettazione.

Il lavoro fatto in ArchLivIng è consistito proprio nell’andare a ripensare l’assetto organizzativo, partendo dai team, passando da un approccio più “tradizionale” per competenze (tutti gli architetti, gli strutturisti, gli impiantisti, ecc) ad un approccio “multidisciplinare” con team che comprendano gli esperti dei diversi domini afferenti ad un’opera. Tutto questo ispirato anche direttamente da quanto suggerito dal BIM, in relazione alla capacità di un gruppo di persone di realizzare tutto quanto annesso ad un progetto.

archliving portfolio board

Punto di forza dell’esperienza è stato il forte coinvolgimento di tutta l’azienda: dai fondatori, agli executive, fino agli ingegneri neoassunti. In pratica l’azienda era alla ricerca (dopo aver già provato qualche declinazione di scrum/kanban) di un approccio strutturato che gli permettesse di muoversi nel turbolento mondo delle costruzioni, caratterizzato da repentini cambiamenti normativi, oltre che di forti aspettative di innovazione da parte dei committenti. In questo è stato molto utile l’utilizzo la definizione e poi l’utilizzo dell’AgileBIM Portfolio Bard per allineare tutti sulle diverse iniziative.

archliving portfolio board 2

Una delle differenze sostanziali rispetto ad un approccio scrum-like puro, è stato quello di mantenere la figura del (Agile) Project Manager, in quanto si è dimostrata più consona al contesto: ad esempio il focus non è tanto su un backlog, sul suo ordinamento e valore dei singoli item (definiti spesso da capitolato e su cui si ha un minimo margine di azione), ma più incentrato sulla relazione con tutti gli stakeholder (tra i quali gli enti pubblici giocano un ruolo di forza) e l’allineamento costante degli avanzamenti, nonché della risoluzione di problematiche annesse alle specifiche lavorazioni.

Certo, si è lavorato molto sul concetto di Management 3.0 e Leadership, in ottica di avere un Agile Project Manager focalizzato sul creare un ambiente idoneo a consentire alle Persone di operare nel migliore delle condizioni, e non sul loro controllo in chiave di micro-management.

Durante il percorso, i team sono stati accompagnati da un AgileBIM Coach e da un Agile Master/PM interno(anch’egli ingegnere di settore) che hanno supportato il percorso nelle varie sfumature: dal Mentoring al Coaching, fino agli aspetti più pratici di dominio. 

Nel concreto sono stati inizialmente creati 6 team che hanno cominciato ad applicare il Fluid Process ed i tool che sono stati sviluppati, dalle varie Visual Board ai Canvas di progetto. In particolare, la Design Board, che ricordiamo essere la board che il team di progetto utilizza per la visualizzazione dell’avanzamento delle attività, è stata implementata grazie a Planner di Microsoft 365. Inoltre, i diversi team hanno preso confidenza con Miro per tutti gli aspetti di collaborazione e condivisione delle informazioni e delle attività.

archliving design board

Il percorso non è stato esente (e non lo è tutt’ora) da dubbi, perplessità, errori e qualche resistenza forte, ma, nel complesso, i team stanno reagendo in modo molto positivo allo sviluppo di un approccio che consente loro di avere una visione condivisa e allineata degli obiettivi di progetto, oltre che delle strategie aziendale.

Per avere un’idea di quanto fatto e di quanto si sta facendo, potete visionare il video di Andrea Mengarelli (l’Agile Master interno) che presenta il caso appena citato alla scorsa AgileBIM Conference https://www.youtube.com/watch?v=H1N49RJRX7c

Siamo giunti quindi alla conclusione di questo primo approfondimento dedicato all’Agile nel mondo delle Costruzioni, ma anche di riflesso all’Agile al di là del mondo del software. AgileBIM è un possibile approccio strutturato per supportare le aziende AEC nel loro percorso verso l’agilità, un punto di partenza per sperimentare nella propria organizzazione una declinazione dell’agile che tenga conto delle specificità del settore.

Il caso di studio accennato, dimostra che per avere successo in questo cambiamento è fondamentale che l’intera azienda ci creda, a tutti i livelli, e che si sviluppi non un cambiamento locale, ma si guardi a come ciò impatti a livello olistico, quindi sia strategico che tattico. 

Molto c’è ancora da fare, ma la strada è ricca di sfide e di opportunità, e AgileBIM può rappresentare un valido elemento di supporto, anche se al centro di tutto ci sono (e lo ripeteremo fino alla noi) le Persone, oggetto primario dell’attenzione di ogni approccio Agile.

 

A presto… stay tuned :)

AgileConstellation: AgileBIM Tool e Template

Nell’ambito di adozione dell’Agile nel mondo del BIM, e delle Costruzioni in generali, la sperimentazione fattiva in diverse realtà ci ha portato a realizzare, provare, modificare e finalizzare dei Template Standard. Il loro scopo è quello di aiutare a velocizzare l’adozione del Fluid Process e supportare direttamente le diverse metafasi.

AgileBIM propone una serie di strumenti per sviluppare la collaborazione tra tutti i membri del Metateam al fine di ridurre la burocrazia ed i ritardi nella comunicazione e nei processi.

Nello specifico si hanno 2 tipologie di tool:

  • Canvas, delle vere e proprie “tele” che servono per orientare e guidare la discussione, focalizzandosi su quelli che sono gli aspetti più rilevanti del dominio trattato;
  • Le Board(ispirate alla ben nota Kanban Board), supportano una rapida visualizzazione dello stato di avanzamento dei lavori.

Da un punto di vista più strategico incontriamo l’AgileBIM Portfolio Board, che permette una pianificazione generale, ovvero cross-project, in grado di creare una vista d’insieme di tutti i progetti e le iniziative in essere.

agilebim portfolio board

AgileBIM Portfolio Board

La Portfolio Board consente di avere prontezza di tutti i progetti in corso ed è governata (asse orizzontale) dall’avanzamento degli elaborati/lavorazioni relativi: se non avviene alcuna modifica nulla si muove su di essa.

Con riferimento allo specifico progetto, invece, è stato sviluppato l’AgileBIM Project Canvas che permette di condividere gli aspetti salienti del progetto, in modo che tutto il team sia allineato e possa rappresentare le proprie considerazioni in merito. 

agilebim project canvas

 AgileBIM Project Canvas

Questo strumento viene inizializzato nella fase di Inception per poi essere costantemente aggiornato e rivisto in modo da riflettere quanto emerso durante tutte le metafasi contemplate. 

E sempre in riferimento ad uno specifico progetto, sono state sviluppate due specifiche board per seguire l’avanzamento puntuale delle attività: l’AgileBIM Design Board e l’AgileBIM Construction Board.

La prima, l’AgileBIM Design Board, è lo strumento che consente di gestire le attività durante le metafasi di design. Sulla board sono riportati gli Elaborati da realizzare, consentendo di identificare rapidamente quelli in lavorazione, quelli candidati alla lavorazione e quelli eventualmente bloccati.

agilebim design board

Esempio d’uso dell’AgileBIM Design Board

Dualmente alla Design Board, l’AgileBIM Construction Board consente al Construction Metateam di avere costantemente prontezza delle lavorazioni in corso.

agilebim construction board

Esempio di uso della Construction Board

Questi template sono chiaramente un punto di partenza, da personalizzare rispetto al contesto, e sviluppano direttamente uno dei principi cardini di AgileBIM, ovvero: “Integrated Visual Management Environment”, che suggerisce di utilizzare strumenti Visual per avere sempre velocemente visibile ed evidente lo stato di avanzamento delle lavorazioni.

Il prossimo appuntamento chiuderà la trattazione di AgileBIM, raccontando un caso di applicazione concreta e le sfide affrontante.

 

 

Stay tuned 

AgileConstellation: AgileBIM, il Fluid Process

Nella nostra descrizione dell’approccio AgileBIM siamo arrivati al Fluid Process, il modello operativo dei metateam, ispirato all’approccio scrumban.

L’obiettivo è di focalizzarsi sul valore da realizzare rendendone sostenibile il carico, prediligendo sempre una qualità intrinseca di quanto realizzato. Tutto ciò favorendo la flessibilità di adattarsi alle esigenze degli stakeholder, nonché a quelle di produzione, senza essere vincolati da un framework troppo prescrittivo che costringa a trovare continui workaround per poter funzionare in apparenza.

Il processo è utilizzato sia dal design metateam che dal construction metateam, con opportune declinazioni specifiche, in particolare rispetto ai tool e alle metriche utilizzate. Nel prosieguo si farà riferimento in modo generico al metateam sottintendendo sia l’uno che l’altro.

agilebim fluid process

Fluid Process

Grazie al Fluid Process è possibile intervenire su quelli che sono i fattori primari annessi agli sprechi (MUDA), ovvero il sovraccarico (MURI) e la variabilità di un’operazione (MURA), due fenomeni che abbassano in modo evidente le performance del gruppo. Si vuole, ad esempio, evitare che le attività si accumulino in alcuni punti del ciclo di lavorazione (“colli di bottiglia”) o che parte del team sia completamente scarico (le “secche” a valle del restringimento).

agilebim muda

Eliminare gli sprechi, le 3M: MUDA, MURA e MURI

La dorsale operativa del Fluid Process è l’Iteration, ovvero una finestra temporale di lavoro che varia da 1 a 2 settimane, durante la quale si svolgono gli Eventi fondanti, supportati da Tool e Metriche.

In particolare, gli obiettivi chiave del Fluid Process possono essere così riassunti:

  • Lavorazioni svolte in maniera più rapida ed efficiente;
  • Identificazione dei colli di bottiglia nel processo, e relative azioni di rimozione e/o mitigazione;
  • Lavorare in modo ottimale senza frustrazione,grazie a team soddisfatti e motivati;
  • Essere in grado di reagire agli imprevisti, senza genere sovraccarichi.

Da sviluppare attraverso tre principi portanti:

  • Pull Principleogni membro del team sceglie da solo le attività da fare, tra quelle proposte dall’Agile Project Manager, e si impegna a completarle.
  • Activity Freeze(Blocco delle Attività) viene utilizzato quando si avvicina la scadenza del progetto. Il suo scopo è segnalare che il team si occuperà di completare solo le attività già in corso, bloccando l’avvio delle altre.
  • Triage, supporta l’azione diActivity Freeze nel caso in cui il tempo a disposizione si stia esaurendo e non tutte le attività siano completabili.

agilebim fluidprocess principles

Principi chiave del Fluid Process

pratiche attuative:

  • Iterazioni, finestre temporali definite, simili agli Sprintdi Scrum, che hanno l’obiettivo di fornire qualcosa di tangibile dopo il loro completamento.
  • React On-Deamand, il metateam reagisce on-demand alle condizioni emergenti, sia di blocco delle lavorazioni che di imprevisto. 
  • 3 Buckets Planning(letteralmente “tecnica dei 3 secchi”), prevede di suddividere le lavorazioni in funzione a tre segmenti temporali, in modo da avere sempre un set di lavorazioni da cui poter attingere.
  • Visual Board, che ha molte similitudini con la Kanban Board e, nella sua forma più minimale, è composta da tre colonne principali: To-DoDoingDone.

agilebim fluidprocess practices

Pratiche chiave del Fluid Process

Il ritmo di lavoro è scandito da una serie di eventi specifici, ben noti agli agilisti: l’Iteration Planning, il Daily Meeting, la Review, la Retrospective, e il Fluid Meeting dedicato al Triumvirate.

I metateam utilizzano, inoltre, una serie di tool per condividere informazioni e allinearsi costantemente: il Project Inventory, il Fluid Board, l’Artifact Card, la Definition of Done, e una serie di Template Standardche consentono al metateam di partire da soluzioni di riferimento, sperimentate in diversi contesti, in modo da supportare un avvio rapido delle lavorazioni.

Infine, non possono mancare specifiche metriche per valutare in modo oggettivo la crescita del metateam ed i vantaggi ottenuti introducendo delle modifiche al Way of Working: Lead Time, Work in Progress Limit Reworking Numbers.

Come ogni modello/approccio agile che si rispetti, il Fluid Process deve essere inteso come “ispiratore”, essendo compito dello specifico metateam, con il supporto dell’AgileBIM Coach, attuare le opportune contestualizzazioni per ottenere i migliori risultati possibili.

Il nostro percorso di scoperta di AgileBIM si avvicina alla conclusione. Nei prossimi 2 appuntamenti vedremo alcuni dei temaplate standard e faremo le conclusioni di merito.

 

Stay tuned J

AgileConstellation: i Metagoal

Continuiamo l’esplorazione dell’AgileBIM Poster concertandoci sui Metagoal

I Metagoal si basano su un presupposto fondamentale: se è vero che ogni progetto è tendenzialmente diverso dagli altri, è altrettanto vero che una parte importante delle attività che li caratterizzano sono spesso comuni, almeno fino alla parte esecutiva che potrebbe essere fatta in modi completamenti diversi.

Su queste considerazioni, AgileBIM fornisce una serie di Metagoal di riferimento, ovvero una knowledge baseda cui attingere per impostare una serie di attività standard all’interno delle diverse metafasi.

I metagoal sono rappresentati attraverso una mappa concettuale organizzata come segue:

agilebim metagoal structure

Struttura di un Metagoal

Ogni metagoal consta di più Aree di Intervento che vengono attuate da una serie di Attività. Non per forza tutte le aree devono essere coperte, così come non tutte le attività potrebbero essere necessarie.

Il valore di avere una serie di metagoal è quello di porre lo specialista di fronte alla necessità di consultare la mappa, valutare cosa fare e cosa non fare, evidenziando, eventualmente, perché alcune aree non sono utili nel progetto specifico.

Si pensi al caso pratico di inizio dei lavori in cantiere (metafase di Construction): il Direttore dei Lavori, partendo da una Construction Board vuota, valuterà i diversi metagoal da realizzare e potrà posizionare su di essa le attività relative necessarie su base temporale.

agilebim contruction metagoal

AgileBIM Construction Board e Metagoal

A titolo esemplificativo vediamo come di quali metagoal si compone la metafase di Construction:

agilebim contruction metagoal

Construction Metagoal

 e vediamo nel dettaglio il metagoal “Studio di fattibilità e ricerca eventuali agevolazioni per il progetto

agilebim metagoal fattibilita

Studio di fattibilità e ricerca eventuali agevolazioni per il progetto

Attualmente AgileBIM conta circa 30 metagoal di dettaglio, organizzati in relazione alle specifiche metafasi.

 

Nel prossimo appuntamento approfondiremo gli aspetti inerenti il Fluid Process.

Stay tuned J

AgileConstellation: AgileBIM Metateam

Cominciamo ad esplorare con maggior dettaglio i pillars dell’AgileBIM Poster. Come descritto nel post precedente, AgileBIM introduce il concetto di Metateam, specializzandolo in: Design Metateam e Construction Metateam.

agilebim metateam metaphases

AgileBIM Metateam

Si ricorda che il concetto di “Metateam” evidenzia come il focus sia sull’identificazione delle figure portanti dei due gruppi di lavoro, lasciando poi l’estensione ad altri membri in funzione delle necessità e del progetto specifico.

Prima di proseguire è fondamentale evidenziare che la discussione è nel merito dei Ruoli e non di Posizioni specifiche: non è detto quindi che uno specialista non possa ricoprire temporalmente, o in modo stabile, più ruoli, se le condizioni specifiche lo rendono necessario. 

A supportare il metateam nel suo complesso si hanno:

  • Agile Project Manager (APM). L’Agile Project Managerha l’obiettivo di mantenere saldi gli obiettivi di progetto in relazione alle risorse economiche e le persone disponibili. 
  • AgileBIM Coach. Compito dell’AgileBIM Coach è quello di aiutare il metateam nell’adozione di AgileBIM, supportando i membri del metateam nella sperimentazione continua di nuove opzioni di miglioramento.
  • Cliente. Il cliente, committente o referente diretto, deve sempre essere ingaggiabile per poter confrontare quanto ipotizzato e realizzato con le sue reali aspettative. 

Scendendo nei dettagli operativi, il Design Team si occupa primariamente della progettazione dell’opera, contemplando due insieme specifici ruoli:

  • Primary Roles (Ruoli Primari), sono i ruoli essenziali, sempre presenti in qualsiasi team, indipendentemente dalla dimensione della commessa;
  • Support Roles (Ruoli a Supporto), sono ruoli a supporto, quasi sempre trasversali a più team.

agilebim designteam

Design Team

I ruoli primari sono:

  • BIM Coordinator, ovvero ilresponsabile dei processi digitali e del supporto alla redazione dell’Execution Plan specifico. 
  • BIM Specialists, i diversi professionisti (ingegneri, architetti, ecc..) impegnati in particolar modo nelle prime 4 metafasi afferenti alla progettazione dell’opera. 

I ruoli a supporto sono:

  • BIM Manager, è il gestore dei processi digitalizzati a livello dell’organizzazione, ed ha la supervisione generale di più commesse. 
  • CDE Manager, è il gestore dell’ambiente di condivisione dati, e ha il preciso compito di garantire la correttezza e tempestività del flusso di informazioni tra le parti coinvolte. 

Guardando al Construction Team si incontrano gli Specialisti operante sul Cantiere (durante la metafase di costruzione) e basato sulle seguenti figure di riferimento:

agilebim constructionteam

 Construction Team

  • Direttore dei Lavori (D.LL.), il professionista, individuato dal committente (pubblico o privato), che ha il compito principale di assistere e soprintendere ai lavori.
  • Direttore di Cantiere (D.C.), (o Capo Cantiere) è il professionista incaricato dal costruttore/appaltatore, della gestione e della conduzione del cantiere. 
  • Coordinatore della Sicurezza in fase di Esecuzione (CSE),la figura incaricata di ridurre i rischi sul lavoro. 
  • Specialisti di Cantiere, sono i professionisti impegnati nella costruzione dell’opera. 

I Metateam sono coordinati da uno specifico AgileBIM Triumvirate che si occupa, costantemente, di definire le linee guida di riferimento per il team, andando a bilanciare le diverse anime costituenti.

Di base si hanno:

  • Design team triumvirate: APM, BIM Coordinator e BIM Manager
  • Construction team triumvirate: APM, Direttore dei Lavori e Direttore di Cantiere

agilebim triumvirates

AgileBIM Triumvirates

Si conclude qui l’overview dedicata ai Metateam di AgileBIM. Appuntamento al prossimo post dove continueremo ad esplorare il Poster.

AgileConstellation: AgileBIM Poster

Continuiamo il percorso di scoperta di AgileBIM descrivendo il relativo Poster di sintesi:

agilebim poster

AgileBIM Poster

In esso si evidenzia come il cuore operativo del toolkit è incentrato su quelle che vengono definite Metafasi, ovvero delle “fasi contenitore” di riferimento che permettono di raggruppare lo stato di avanzamento dei lavori per macro-obiettivo.

AgileBIM contempla 6 Metafasi Operative di riferimento:

  • http://www.felicepescatore.it/7c847534-19d6-44d3-842f-7f2747c39d0a” alt=”Immagine che contiene disegnando, segnale, orologio Descrizione generata automaticamente” width=”31″ height=”31″ />Fattibilità (Inception), consente di esplicitare gli obiettivi alla base del progetto stesso, individuandone gli aspetti cardine come l’opera da realizzare e i costi annessi.
  • http://www.felicepescatore.it/36ae04c4-220b-49b0-b405-ba5c7ab4213e” alt=”Immagine che contiene orologio, segnale, disegnando Descrizione generata automaticamente” width=”31″ height=”31″ />Preliminare (Concept Design), in cui viene redatto il progetto preliminareche ha il compito di definire le caratteristiche qualitative e funzionali dell’opera, individuando i bisogni da soddisfare e le funzioni che dovrà svolgere l’intervento. 
  • http://www.felicepescatore.it/1aef9fd0-0b70-4109-9eef-08534bb1954c” alt=”Immagine che contiene segnale, via, palo, disegnando Descrizione generata automaticamente” width=”31″ height=”31″ />Definitiva (Developed Design), in cui, sulla base delle indicazioni del progetto preliminare approvato, viene redatto il progetto definitivoche contiene tutti gli elementi necessari ai fini dei titoli abilitativi, dell’accertamento di conformità urbanistica o di altro atto equivalente. 
  • http://www.felicepescatore.it/881ee51f-eb8f-457b-a283-335411b4def9″ alt=”Immagine che contiene disegnando, cibo Descrizione generata automaticamente” width=”31″ height=”31″ />Esecutiva (Technical Design), in cui viene redatto il progetto esecutivo, in conformità al progetto definitivo, andando a determinare in ogni dettaglio i lavori da realizzare e il relativo costo previsto. 
  • http://www.felicepescatore.it/e65e8b07-dc52-42d2-a62b-36fb794a03f1″ alt=”Immagine che contiene disegnando, orologio Descrizione generata automaticamente” width=”31″ height=”31″ />Preparazione (Transition), è la metafase a valle della progettazione esecutiva ed è focalizzata sulla preparazione di tutto quanto necessario ad avviare la fase di costruzione dell’opera. 
  • http://www.felicepescatore.it/c8120b59-3139-4b1d-8c9a-cb8f02c8b2f8″ alt=”Immagine che contiene metro Descrizione generata automaticamente” width=”32″ height=”31″ />Costruttiva (Construction), è la metafase di costruzione dell’opera, in cui vengono ingaggiati, diretti e gestiti le ditte e i professionisti delle diverse aree di intervento.

Le metafasi di design sono focalizzate sulla realizzazione del Project Information Model (PMI) e dell’Asset Information Model (AIM), supportata dal Common Data Environment (CDE) che permette di raccoglieregestire e scambiare il modello, i dati non grafici e la documentazione, facilitando la collaborazione e aiutando ad evitare duplicazioni ed errori. Nello specifico, il CDE si compone di 4 stage (aree) specifichi:

  • Work in Progress, area di lavoro del singolo elaborato;
  • Shared, area di condivisione di quanto realizzato, non per forza in uno stato finale;
  • Published Documentation,deposito degli elaborati finali approvati dalla committenza: l’opera è pronta per essere realizzata;
  • Archive, in quest’area vengono conservati tutte le informazioni progettuali relative alla struttura realizzata.

agilebim metafasi cde

AgileBIM & CDE

Ad accompagnare operativamente le metafasi si incontrano i Metagoal, ovvero un insieme concettuale di lavorazioni standard che aiutano a focalizzare gli elementi essenziali e comunemente contemplati nella realizzazione di un’opera.

agilebim metagoal

Metagoal

Dualmente alle Metafasi e ai Metagoal, AgileBIM introduce il concetto di Metateam, ovvero un gruppo di lavoro multidisciplinare in grado di seguire l’intero ciclo di realizzazione dell’opera: dal concepimento alla costruzione. Si parla di Metateam perché la composizione del team è molto dinamica, fermo restando un nucleo portante comune ai diversi progetti.

In AgileBIM, il Metateam si specializza in relazione al compito specifico da perseguire, in particolare si ha il:

  • Design Metateam, focalizzato sulle prime 4 metafasi, dalla Fattibilità all’Esecutiva;
  • Construction Metateam, impattante in modo esclusivo sulla metafase di Costruzione.

Il passaggio delle lavorazioni dal Design Metateam al Construction Metateam avviene grazie alla metafase di Preparazione.

 

agilebim metateam metaphases

 AgileBIM Metateam

L’Agile Project Manager (APM) si occupa di mantenere una visione olistica del progetto, affiancando i diversi metateam ed i diversi professionisti nelle specifiche metafasi. A supportare l’intero metateam nello sviluppo del mindset Agile è chiamo l’AgileBIM Coach: il suo focus è nell’adozione pratica di AgileBIM e nello stimolo alla sperimentazione continua di nuove opzioni di miglioramento, sia di approccio che di prodotto.

Il Metateam organizza il proprio lavoro basandosi sul processo definito Fluid Process, che trova le proprie basi nell’approccio ibrido scrumban e si concretizza nel flow rappresentato nell’immagine seguente:

agilebim fluid process

Fluid Process

Gli aspetti salienti del Fluid Process si focalizzano sul:

  • Gestire e Visualizzare il Flusso, in modo da avere costantemente prontezza su quanto sta accadendo nel gruppo di lavoro; 
  • Limitare il Work in Progress, ovvero dimensionare il numero di lavorazioni sulle reali capacità operative del metateam; 
  • Lavorare in Cicli Brevi, che consentono di valutare lo stato di avanzamento delle lavorazioni e quello di miglioramento della sinergia del metateam;
  • Generare Feedback Multilivello, per stimolare vari momenti di confronto, anticipandoli il più possibile per ridurre gli impatti di eventuali impedimenti e problemi;
  • Migliorare e Sperimentare Continuamente, si tratta di sviluppare una visione condivisasugli obiettivi e sul come raggiungerli, nella logica della scelta per consenso, aiutando il metateam a migliorare continuamente il proprio Way of Working. Il tutto spinto dalla sperimentazione continua di nuovi modi di collaborare ed innovare nel proprio lavoro.

Il Fluid Process, grazie a specifiche declinazioni delle pratiche e dei tool, si adatta sia al Metateam di design che di construction.

 

Nei prossimi post analizzeremo con maggior dettaglio il Metateam, il Fluid Process e i Metagoal, descrivendone gli aspetti peculiari.

 

Stay tuned J

AgileConstellation: AgileBIM, la sfida di innovazione nel management delle costruzioni

Nel precedente appuntamento abbiamo caratterizzato il percorso che ha portato alla nascita di diversi filoni di sperimentazione fattiva dell’Agile in domini non software, o comunque in domini in cui, eventualmente, il software è solo una componente di un prodotto ben più articolato.

In particolare, nell’ultimo anno, questa declinazione si è focalizzata sul mondo delle costruzioni (AEC: Architecture, Engineering & Construction), andando ad intercettare una di quelle che è la più grande rivoluzione del settore negli ultimi decenni: il Building Information ModelingBIM.

bim weelSecondo la principale normativa di rifierimento, la ISO 19650, il BIM è definite come: “The use of shared digital representation of a built asset (including buildings, bridges, roads, process plants, etc.) to facilitate design, construction and operation processes to form a reliable basis for decisions”. 

Ma è possibile spingersi oltre andando a concentrarsi, in particolare sul significato della “M” che ha nel tempo ha attraversato tre diverse declinazioni: da un primo focus su Modellazione e Modello, alla tendenza attuale verso Management, cosa che sposta l’attenzione all’intero ciclo di realizzazione e di vita del “Building”. 

Ed è proprio qui che AgileBIM fa la sua comparsa, portando il mindset agile all’interno dei team di lavoro propri delle costruzioni, fornendo una filosofia operativa di supporto al BIM, ma consentendo anche a chi ancora non lo utilizza di ripensare i propri processi operativi in relazione a quelle che sono le nuove sfide progettuali e costruttive moderne.

In realtà, lo studio e le prime proposte di come trasformare la progettazione e costruzione di opere civili/edili parte quasi a ridosso della nascita del Manifesto Agile (agilemanifesto.org), con la pubblicazione di “Collaborazione, informazioni integrate e il ciclo di vita nella progettazione, costruzione e uso del costruito”(2004) in cui viene descritta una visione di come la progettazione debba cambiare il proprio flusso di lavoro. Questa nuova modalità viene illustrata mediante la cosiddetta Curva di MacLeany:

macleany

Curva di MacLeany

La curva è disegnata in un piano cartesiano con:

  • il tempo riportato in ascisse, che segna l’avanzare delle fasi progettuali;
  • l’efficienza dell’azione a parità di sforzo sulle ordinate.

Sono rappresentate quattro funzioni:

  • la prima curva può essere vista come la “possibilità di cambiare le funzioni a parità di costo”. Si vede come all’inizio, nella prima fase di progettazione, le possibilità di modifiche sono elevate ma che via via diventano sempre di meno con l’avanzare del progetto, fino a arrivare all’as-built, in cui il cambiamento funzionale è escluso se non ricorrendo a costi spropositati;
  • la seconda curva descrive “il costo di uno stesso cambio progettuale nelle varie fasi di progettazione”. È evidente come modificare il progetto prima della cantierizzazione comporti costi ridotti, mentre col procedere della realizzazione i costi siano sempre maggiori;
  • la terza curva descrive “gli sforzi compiuti nelle varie fasi di un processo progettuale tradizionale”. Secondo MacLeany è durante l’ultima fase, prima di cantierizzare l’opera, che si concentrano gli sforzi, poiché solo questa fase coinvolge tutte le discipline;
  • la quarta curva rappresenta la “progettazione collaborativa” e cioè una progettazione che coinvolga tutte le discipline fin dall’inizio, quando l’incidenza dei costi sui cambiamenti progettuali è minima e si ha ancora grande flessibilità progettuale.

Nella “Curva” si evidenzia l’importanza di anticipare gli sforzi alle fasi iniziali della progettazione, permetta di ottenere un controllo maggiore sulle funzionalità e costi dell’intero progetto.  Non si tratta, come è evidente, di ridurre gli “sforzi” progettuali, in quanto l’impegno non può che essere commisurato alla qualità di ciò che si intende realizzare (i punti di massimo delle due curve rappresentative dei processi BIM-oriented e tradizionale sono pressoché identici), ma di anticipare nel tempo tali sforzi.

Quando espresso da questo studio, e sintetizzato nella “Curva”, è fortemente in simbiosi con uno dei concetti portanti del mondo Agile: “lo shift-left” ossia anticipare tutte quelle azioni che consentono di avere una qualità intrinseca dei prodotti e promuovere feedback costanti per un adattamento continuo (pragmatismo).

agilebimAndando ad investigare nello specifico del BIM e comparandone le caratteristiche primarie con quelle più similari del mondo Agile, si hanno i seguenti punti di convergenza forte:

  • Coinvolgimento attivo dei clienti (Agile);
  • Team multidisciplinari con delega (potere) decisionale (Agile);
  • Requisiti che evolvono, ma in un tempo che è definito (Agile);
  • Requisiti espressi a diversi livellie in modo visuale(Agile);
  • Sviluppo incrementale ed iterativoa cicli ridotti (Agile);
  • Focus sul rilascio continuo (Agile);
  • Allineamentoriadattamentocontinuo (Inspect and Adapt, Agile);
  • Testcome parte integrante dello sviluppo (test early and often, Agile);
  • Approccio collaborativocooperativocon gli stakeholder (Agile);
  • Piattaforma online per la collaborazione, gestione e scambio dei dati (BIM);
  • Enfasi sulla Collaborazione del Team grazie alla centralizzazione delle informazioni (IFC, CDE – BIM);
  • Coinvolgimento dei clienti/stakeholder nel processo (accesso ad una o più delle 4 aree del CDE – BIM);
  • Gate di Valutazione per il flow ed il coordinamento delle informazioni (BIM).

Come si intuisce, molta enfasi è proprio posta sulla creazione di sinergia tra le persone coinvolte, mettendole nelle migliori condizioni operative possibili.

Da tutto questo nasce AgileBIM, ovvero un toolkit operativo sviluppato per approcciare al Building Information Modeling (BIM) con un mindset Agile e Lean, convogliando gli aspetti caratterizzanti di entrambi gli approcci:

  • collaborazione tra tutte le figure interessate nelle diverse fasi di realizzazione di un’opera;
  • condivisione digitale dei dati e interoperabilità mediante formati aperti;
  • capacità di miglioramento continuo;
  • propensione a sperimentare costantemente piccoli miglioramenti incrementali.

Prima di proseguire, è fondamentale ribadire nuovamente un concetto già esplicitato nel post precedente: AgileBIM (così come AgileIoT ed AgileConstellation) non è il tentativo di utilizzare un framework/metodologia del mondo Agile “software” (aka Scrum o Kanban) e utilizzarlo per cercare di sostituirsi damblè ai processi tipici del mondo AEC. Così come non si tratta di impattare esclusivamente sul software realizzato per il supporto delle costruzioni (es: plug-in o librerie delle piattaforme BIM).

AgileBIM è un vero e proprio approccio allo sviluppo delle costruzioni, che guarda l’intera opera e contestualizza il mindset agile rendendolo operativamente valido ed attuabile in un mondo caratterizzato da rigide normative, e modelli operativi decennali, ma che è affamato di innovazione.

Quindi il focus è sulla creazione di un approccio Agile+BIM alla gestione ed esecuzione dei progetti (perché qui si parla di progetti, mentre l’idea di prodotto è decisamente lontana da quella a cui si è abituati nel software o nella manifattura) che si fondi sul valore e sulla capacità delle persone.

Per far si che non si corra il rischio di creare un “manuale operativo”, ma invece si sviluppi un vero e proprio mindset Agile, si è proceduto a definire opportuni principi e pratiche di dominio che estendono e specializzano quelli dell’AgileConstellation Manifesto:

agilebim principi

AgileBIM Principi

  • Ispezione ed Adattamento(Inspect & Adapt). La filosofia di Ispezione ed Adattamentofa parte del DNA delle metodologie Agili, spingendo i gruppi di lavoro ad ingaggiarsi concretamente nelle specifiche lavorazioni e personalizzare il modello operativo in funzione di quelle che sono le evidenze che emergono dal campo.
  • Sperimentazione Continua (Continuous Experimentation). Un mindset orientato alla Sperimentazione Continuaporta il gruppo di lavoro a sperimentare nuove soluzioni, nuovi strumenti e modelli operativi al fine di migliorarsi costantemente e offrire servizi d’avanguardia.
  • Responsabilità delle Lavorazioni (Deliverable Ownership). Ogni professionista, parte del gruppo di lavoro, ha una delega operativa rispetto alle lavorazioni in carico, creando uno specifico ingaggio che gli consente di svolgere il compito nel modo migliore contestuale.
  • Confronto e Collaborazione (Discussion & Collaboration). I professionisti impegnati nelle lavorazioni si ritagliano il giusto tempo per discutere e collaborare con i propri colleghi, in modo da allinearsi costantemente e far diventare patrimonio comune quanto sperimentato.
  • Metriche Sostenibili (Actionable Metrics). Il gruppo di lavoro è supportato da metriche sostenibili che lo aiutano a migliorarsi e a capire se la strada intrapresa stia effettivamente generando un beneficio.
  • Focus on Value Stream. L’attenzione non è esclusivamente sulla singola lavorazione (tattica), ma principalmente sul valore complessivo da generare (strategica). In tale direzione è fondamentale impiantare le modalità operative considerando il value stream, ovvero il flusso di lavoro complessivo che genera il valore primario.
  • Integrated Visual Management Environment. Vengono utilizzate piattaforme integrate di lavoro, supportate da strumenti di Visual Management che consentono di avere sempre, e velocemente, sotto controllo lo stato di avanzamento delle lavorazioni.
  • Metateam Auto-organizzati e Multidisciplinari (Self-Organized and Multidisciplinary Teams). I gruppi di lavoro sono auto-organizzati e multidisciplinari, scegliendo autonomamente il modo migliore per svolgere il loro lavoro, piuttosto che essere costretti a seguire processi imposti da terzi, se non per vincoli normativi. La multidisciplinarietà garantisce che si abbiano tutte le competenze necessarie per svolgere il lavoro dipendendo il meno possibile da esterni.

Dualmente, sono state definite le pratiche portanti anch’esse specializzanti quelle dell’AgileConstellation Manifesto:

agilebim pratiche

AgileBIM Pratiche

  • Fluid Thinking. Questa pratica porta ad approcciare tutti gli aspetti caratterizzanti l’azione di lavoro in modo “fluido”, ovvero contemplando una collaborazione attiva e duttile tra i diversi professionisti coinvolti. L’obiettivo è quello di rimuovere la burocrazia derivante da una focalizzazione sul processo, spostando l’attenzione sulla comunicazione trasparente in tempo reale.
  • Common Environments. Le lavorazioni avvengono in un ambiente condiviso, sia fisico che digitale, prediligendo piattaforme integrate che supportano la sperimentazione di nuove soluzioni quando disponibili o necessario.
  • Extreme Building. Si tratta di considerare la realizzazione fisica dell’opera come un momento di validazione finale, e non come una passiva accettazione di quanto ipotizzato e redatto durante la fase di progetto. In tal modo sarà possibile intervenire più rapidamente e, con meni ostacoli, sugli imprevisti che inevitabilmente si presenteranno durante la costruzione vera e propria.

In aggiunta, la pratica di Fast Prototyping (ereditata da AgileConstellation) supporta la validazione della sostenibilità dell’opera e stimola feedback concreti rispetto a quanto ci si appresta a realizzare.

agilebim fastproto

Fast Prototyping for AgileBIM

Rispetto a quanto ereditato dalla pratica base, vengono aggiunti 3 nuovi aspetti (bubble) di riferimento:

  • Autorità (Authorities), ovvero gli enti e le autorità competenti a cui chiedere autorizzazioni e da cui si dipende per la realizzazione dell’opera;
  • Appaltatore (Contractors), professionisti, specialisti ed aziende terze di cui avvalersi nel progetto;
  • Vincoli (Constraints),i vincoli specifici di cui il gruppo di lavoro dovrà tenere conto in modo esplicito.

Il lavoro fatto in oltre un anno di sperimentazione ha dato vita ad una specifica Vision Operativa, ben sintetizzata dall’AgileBIM Poster riportato di seguito:

agilebim poster

 

Del Poster e dei relativi aspetti annessi parleremo nel prossimo articolo, dando concretezza ai principi ed alle pratiche in funzione di quanto sperimentato ed appreso fin ora.

 

Stay tuned :-J

AgileConstellation: l’Agile oltre il software, dall’IoT al BIM

Il mercato odierno è un mercato multidisciplinare in cui i confini che separano le diverse discipline organizzative ed operative sono sempre più labili. Le aziende si avvalgono in modo strutturale di diverse competenze per rafforzare la propria posizione di mercato o conquistare nuovi ambiti, e l’esigenza primaria diventa quella di sviluppare una modalità operativa che tenga conto delle specificità relative, pur trovando un punto di visione comune orientata ai prodotti ed ai servizi offerti.

multidisciplinarieta

Leggendo in questa direzione la capacità di un’azienda di sviluppare il proprio percorso di Business Agility, ossia la capacità di ripensarsi per accompagnare i cambiamenti di mercato, è sempre più frequente la necessità di rivedere le diverse declinazioni Agili che si è imparato a conoscere nell’ultimo ventennio, tenendo presente delle specificità dei domini interessati.

Questo è ancora più vero se si pensa che oggi, la maggior parte delle aziende, non è un’azienda di prodotto software, ma è un’azienda che vede tra i suoi asset portanti lo sviluppo e/o la personalizzazione di soluzioni software a supporto del proprio business: si sviluppa software non per venderlo, ma in quanto componente essenziale di un qualcosa che soddisfa le esigenze dei propri (potenziali) clienti.

Diventa quindi fondamentale concentrarsi sullo sviluppo di un mindset agile che si scrolli di dosso alcune convinzioni che negli anni si sono implicitamente trasformate in mantra, rischiando di limitare la capacità di contestualizzazione dell’approccio.

L’Agile trova la sua essenza nella capacità di far lavorare insieme le persone, individuando il modo più efficace di concentrarsi sui reali obiettivi di valore e scrollandosi di dosso aspetti burocratici ed inefficienze che distraggono da esso.

Un esempio per tutti: è convinzione comune che in un contesto Agile debba esiste il Product Owner e che ci sia poco spazio per il Project Manager. Nonostante sia un dato di fatto che il ruolo del Product Owner porti un indubbio valore in un contesto orientato al prodotto, permettendo di rendere efficace l’attenzione che il team ha verso gli stakeholder, è altrettanto vero che non sempre si tratta della soluzione ottimale in contesti che invece, ad esempio, sono orientati ai progetti. 

È un problema? Vuol dire che non si può essere agili in tali contesti? Assolutamente no! 

D’altronde, se proprio vogliamo essere pignoli, il ruolo dei Product Owner non è un ruolo dell’Agile (che non prescrive, per inciso, alcun ruolo) ma di Scrum. Basta dare un’occhiata ad AgilePM/AgilePF per vedere un approccio completamente diverso dell’implementazione di un processo agile all’interno di un contesto produttivo.

Il discorso, comunque, non è “PO sì o PO no” (e dualmente “PjM sì o PjM no”), ma è quello di avere la capacità di leggere il contesto ed avere una conoscenza di diverse soluzioni applicabili, senza obbligatoriamente forzare un’azienda ad andare in una direzione che non le appartiene, pur avendo ben chiari i miglioramenti che si vogliono raggiunge e i vantaggi/svantaggi nell’adottare una soluzione piuttosto che un’altra.

Partendo da queste considerazioni, nasce AgileConstellation (agileconstellation.org), una estensione del mindset agile, inteso nei suoi valori e principi costituenti, che si pone l’obiettivo fornire un punto comune di partenza per i contesti non software, ovvero quelli in cui la parte di sviluppo software è una delle componenti portanti.

AgileConstellation è il risultato dell’esperienze sul campo (personali e degli altri co-autori) nel supporto di aziende in cui è stato sperimentato ed applicata l’agilie al di là del software, situazione, come detto, sempre più frequente. 

È fondamentale sottolineare subito un aspetto: non si sta parlando di applicare un framework (aka Scrum), o metodologia che si voglia, all’interno del dipartimento software di un’azienda che si occupa di altro, ma piuttosto applicare un approccio agile alla realizzazione dei prodotti caratterizzanti il business di tale azienda, prodotti spesso caratterizzati da un insieme di aree e domini ingegneristici molto diversi tra loro.

AgileConstellation logo miniAgileConstellation va visto come un’estensione del mindset agile, inteso nei suoi valori e principi essenziali, e caratterizzato da una specifica filosofia operativa ispirata alla bottega rinascimentale, ovvero la cellula in cui veniva fatto tutto quanto necessario alla realizzazione di una nuova opera: dalla progettazione alla commercializzazione, passando per la formazione e la produzione. I membri del team sono spinti a comportarsi come gli artigiani rinascimentali che con estrema abilità utilizzavano materiali, tecniche e strumenti diversi per soddisfare il cliente che aveva commissionato l’opera.

AgileConstellation mette al centro il bisogno del cliente, armonizzando competenze, approcci e tecnologie differenti, grazie alla definizione di un set comune di strumenti che rendono economicamente sostenibile la creazione di soluzioni di mercato.

Nello specifico, troviamo quindi:

  • Filosofia, pensata per stimolareuna visione condivisa.
  • Principi, pensati per ispirarele azioni delle persone: 
    • Non si tratta delle singole parti, è l’insieme che va realizzato bene.Non si tratta di completare le parti costituenti e poi integrarle, bensì di realizzare una soluzione intelligente per risolvere un’esigenza in modo efficiente ed efficace.
    • Pensare meno e agire prima: ridurre all’essenziale il tempo dedicato alla fase di analisi in favore di un rapido avvio delle attività di sviluppo della soluzione.
    • Semplice è meglio: più semplice è la soluzione che si realizza, maggiori saranno le possibilità di farla evolvere in funzione delle esigenze degli stakeholder.
    • Se non puoi ricordarlo, non puoi migliorarlo: utilizzare strumenti di visual management per monitorare lo stato di sviluppo della soluzione.
  • Pratiche, pensate per guidarele azioni delle persone:
    • Fast Prototyping:ha lo scopo di validare la sostenibilità della soluzione.
    • Make-Measure-Learn: consente di sperimentare rapidamente le diverse ipotesi e le diverse assunzioni:
    • Flashback: porta il team a confrontarsi sull’avanzamento dello sviluppo, creando un’azione di allineamento rapido in cui è l’osservatore ad ingaggiarsi nell’osservare l’elemento in lavorazione.
    • Continuous Improvement: suggerisce di ridurre al minimo gli interventi sugli aspetti meno flessibili della soluzione, azione estremamente costosa e lunga.
    • Continuous Integration: spinge a integrare costantemente ed il prima possibile tutte le differenti anime della soluzione, in modo da rilevare quanto prima i difetti ed i problemi esistenti ed intervenire rapidamente per risolverli.
  • Star, pensate per adattare il tutto a domini specifici:
    • AgileIoT logo mini AgileIoT, pensato per le soluzioni incentrate sull’Internet of Things (agileiot.org)
    • AgileBIM logo mini AgileBIM, sviluppato per il supporto al mondo delle Costruzioni (agilebim.info

Gli elementi appena descritti sono riassunti graficamente dall’AgileConstellation Funnel:

it agileconstellation funnel

AgileConstellation Funnel

Nei prossimi articoli presenteremo la “star” AgileBIM, orientata al mondo delle costruzioni (AEC: Architecture, Engineering & Construction) per supportare la realizzazione di opere attraverso un mindset e un processo di realizzazione agile lungo l’intera catena di valore, dalla progettazione alla costruzione.

In particolare, AgileBIM propone delle soluzioni operative per approcciare al BIM sposando un mindset Agile, coniugando gli aspetti caratterizzanti di entrambi gli approcci:

  • la collaborazione tra tutte le figure interessate nelle diverse fasi del ciclo di vita di una struttura;
  • la condivisione digitale dei dati e l’interoperabilità mediante formati aperti.

 

Stay tuned :)