Agile

In questa fase non entreremo nel dettaglio; prima di illustrare efficacemente la metodologia Agile è necessaria un’ampia introduzione, partendo proprio dai concetti base definiti nella LezioneZERO.

Quindi ci limiteremo fornire i presupposti di massima per comprendere la necessità di cambiare registro e cominciare a pensare il mondo dell’impresa in maniera più simile a quella dei mercati vincenti. Per farlo affronteremo un approccio alla progettazione e organizzazione del business, partendo dalla filosofia che lo ha generato, quella che, appunto, viene chiamata Agile.

Partiamo dal termine, che significa esattamente quello che vuol dire anche in italiano. La sua radice, però, è anglosassone e quindi la pronuncia corretta sarebbe agiail. O. per chi conosce l’alfabeto fonetico, ˈædʒaɪl/.

In un modello Agile si prende atto di un eventuale cambiamento in qualsiasi ambito, quindi si modifica la strategia e si aggiornano le azioni, con una ottimizzazione delle performances ed un controllo più accurato di costi e flussi di cassa.

La metodologia agile nasce nell’ambito della progettazione software. L’ipotesi era quella di trovare un’alternativa al project management a cascata (waterfall), che struttura un progetto in una serie di sequenze lineari e sequenziali. I dati dicevano che oltre il 70% dei progetti strutturati in questo modo non riusciva a rispettare le premesse (in parte o in toto). Partendo da questo, un gruppo di sviluppatori software ha delineato un nuovo metodo, redigendo il Manifesto per lo sviluppo agile di software. In questo documento gli sviluppatori propongono un nuovo approccio (in quel momento limitato allo sviluppo del software) descrivendo 4 aspetti chiave che a loro parere devono avere la priorità su altri. Secondo loro, i membri di un team agile dovrebbero dare priorità a quanto segue:

Individui e interazioni rispetto a processi e strumenti
Un software efficiente rispetto a una documentazione esaustiva
La collaborazione con il cliente rispetto alla negoziazione dei contratti
La preparazione ad affrontare il cambiamento rispetto all’esecuzione di un piano

Da questi 4 pilastri vengono elaborati 12 principi che definiscono il quadro nei dettagli. Gli autori chiariscono comunque che tutti gli aspetti indicati sopra sono importanti, ognuno a suo modo, ma dare la priorità agli aspetti a sinistra (in grassetto) rispetto a quelli a destra può portare ad approcci migliori per lo sviluppo del software. Il Manifesto non determina una serie di pratiche da seguire, ma è da intendere come una guida verso un nuovo modo di pensare alla progettazione ed alla programmazione.

Dopo i primi passi questo approccio, oggettivamente funzionale e particolarmente adatto alla vorticosa velocità dei tempi dettati dalla digital disruption, l’approccio agile comincia ad allargarsi in tutti i settori e a declinarsi in diversi modelli.

Infatti, il termine più adatto al nostro approccio è quello, nato più recentemente, di Agile Umbrella. Come si può intuitivamente comprendere, l’Agile Umbrella raccoglie diverse metodologie e framework che, per quanto diversi tra di loro, si richiamano tutti esplicitamente ad i principi chiave dell’agilità. Le nostre proposte formative seguiranno questa visione e si raccoglieranno tutte all’interno di questa metodologia.

I dettagli dell’approccio Agile li affronteremo nella fase finale di Digital GAP e rappresenteranno una buona metà di ToolBox, il passo finale del percorso che abbiamo ipotizzato per il modello formativo targato T-Campus.

A proposito di Agile: lo Scrum

La filosofia Agile è un approccio ai processi di produzione che si concretizza in una serie di applicazioni, chiamate framework. Spiegare il significato di questo termine ci aiuterà a capire molto di come funziona questo modello e, dopotutto, abbiamo più volte ribadito l’esigenza di un vocabolario condiviso che eviti fraintendimenti.

Il termine framework nasce nella programmazione del software e rappresenta una sorta di meta-linguaggio di sviluppo, un ambiente fatto di “pezzi di codice” e strutture già organizzate da modulare per realizzare nuovi programmi, ma è spesso utilizzato anche all’infuori del linguaggio informatico.

Lo si usa, specie nelle materie economico-gestionali, per esprimere il concetto di una modalità strutturata, pianificata e permanente, che supporta una prassi, una metodologia, un progetto, un sistema di gestione. In italiano corrisponde alle parole: architettura, struttura, quadro strutturale e simili (mentre intelaiatura sarebbe poco adatta a spiegare il concetto, sebbene sia il significato letterale del termine).

Tra i framework del modello Agile, abbiamo scelto di privilegiare Scrum e anche qui il nome spiega molto della logica operativa di questo approccio. Il termine scrum, infatti, indica la mischia iniziale tipica del rugby, il momento in cui i giocatori si riuniscono dopo un’interruzione e proprio da quel punto procedono compatti, portando la palla sempre in avanti, come prevedono le regole.

Risulta interessante soffermarsi sull’analogia con il rugby: un team di persone con le qualità giuste ed una serie di schemi preordinati (la squadra) si riunisce per lo scrum (la mischia) e si lancia verso l’obiettivo finale (la meta). Ognuno conosce il proprio ruolo e sa esattamente cosa deve fare, ma quello che conta, in quel momento, non è giungere alla meta: il reale obiettivo è conquistare terreno, migliorare costantemente la propria condizione, puntando alla meta finale attraverso incrementi successivi (la conquista delle yarde).

Perché il cuore della metodologia Scrum (e sostanzialmente di tutti i framework dell’Agile Umbrella) è quello di operare attraverso continui incrementi organizzati all’interno di un percorso delineato per grandi obiettivi piuttosto che codificato su stretti binari di programmazione.

Piccoli passi, più semplici da gestire rispetto un’interminabile e sfiancante cavalcata. La differenza è che mentre nel rugby la meta è stabile, nel business, proprio per il caos che attraversa i nuovi mercati, l’obiettivo cui puntare può cambiare e i dati ci dicono che cambia spesso.

Scrum è un modo di applicare la filosofia Agile e punta a facilitare i rapporti tra management, stakeholders, team e cliente finale, tenendo presente i feedback del mercato proprio attraverso il rilascio continuo di incrementi misurabili che possono rappresentare la base per le scelte.

Ogni passaggio, però, deve essere codificato per gestire al meglio il flusso operativo e d’informazioni all’interno di una organizzazione. Scrum abbraccia questa visione, proponendo un modello organizzativo che sta funzionando in vari ambiti, dalla programmazione, al copywriting, alla gestione di aziende e territori.

L’adeguamento è fatto di tecnologia e conoscenza, perché è chiaro come tutto questo deve necessariamente essere organizzato attraverso un metodo che risponda alle nuove dinamiche e consenta una velocità effettiva di adattamento al cambiamento, garantendo una misurabilità delle azioni e dei progressi per influenzare efficacemente le scelte del management. Se la tecnologia e la conoscenza sono il software che muove il nostro modello di business, la gestione del flusso di lavoro rappresenta sicuramente il nostro hardware.

Nessun software, per quanto avanzato e performante, potrà mai funzionare efficacemente se l’hardware non è pienamente compatibile.

Lo schema sottostante illustra sommariamente un progetto Agile su base Scrum: il management fa delle richieste (Request) al Team operativo; queste possono essere di sviluppo e produzione o, magari, relative alla necessità di acquisire dati e report sul mercato. Il Team processa la richiesta all’interno di cicli iterativi (chiamati Sprint) rilasciando quello che viene definito MVP, Minimum Viable Product o prodotto minimo funzionante che può essere un sito web, una pagina Facebook, una campagna di comunicazione o anche una specifica feature, una modifica strutturale o di contenuto, un nuovo prodotto o anche un report su una determinata azione.

In ogni caso, alla fine dello Sprint vengono generati una serie di Report che serviranno principalmente per verificare la “tenuta” del progetto ed a supportare nuove Request.

Perchè è importante

Questa domanda mette in primo piano il problema centrale ed il motivo alla base della nascita del modello T-Campus. I modelli Agile prevedono anche delle strutture rigidamente formalizzate e procedure minuziose che, ad uno sguardo frettoloso, possono apparire inutili o, peggio, stupidamente burocratiche.

La cosa più grave, però, è che, se utilizzati in maniera approssimativa, senza comprenderne le motivazioni reali e l’impatto sull’organizzazione, tendono a diventare realmente inutili e burocratiche. Si tratta di una sorta di profezia auto avverante: se utilizziamo questi strumenti soltanto formalmente ci restituiranno un risultato altrettanto formale.

Quello che stiamo per definire può apparire come un circolo vizioso e, in parte, lo è. Ma stiamo provando a spezzarlo.

Abbiamo voluto una premessa all’accesso ai corsi di T-Campus, dove si affronta il modello operativo connesso ad Agile ed a tutti i framework di quella che viene definita Agile Umbrella, il complesso sistema di idee ed approcci che si richiamano a questa filosofia base.

Questa premessa è il percorso che parte con LezioneZERO (cosa ci serve per comprendere la nuova normalità), prosegue con DigitalGAP (i meccanismi base del mondo digitale) e si conclude con ToolBox (le premesse di Agile e i nuovi modelli organizzativi e di business).

Per spezzare il circolo vizioso vogliamo partire dai fondamentali e illustrare le sostanziali differenze tra il mondo pre-digitale e quello attuale, comprendere in profondità cosa s’intende con il termine nuova normalità e perché alcuni modelli del passato non sono letteralmente applicabili al nuovo scenario.

Vuoi saperne di più?

Lasciaci la tua mail. La useremo esclusivamente per inviarti le informazioni che hai richiesto e nessun’altra mail sarà inviata senza un esplicito consenso.




    Vai alla barra degli strumenti