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.

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 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, pensato per le soluzioni incentrate sull’Internet of Things (agileiot.org)
  •  AgileBIM, sviluppato per il supporto al mondo delle Costruzioni (agilebim.info) 

Gli elementi appena descritti sono riassunti graficamente dall’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