La metodologia Agile promette di garantire maggior flessibilità, più elevata qualità e più velocità nel rilascio delle applicazioni, ma senza un approccio olistico alla trasformazione gli sforzi potrebbero risultare vani. Non è sufficiente adottare pratiche Agile; serve un approccio end-to-end lungo tutta la catena del valore del rilascio applicativo: è necessario abbattere tutte le barriere, da quelle architetturali a quelle organizzative e di processo. Inoltre, non può essere un percorso “one-shot”: la metodologia Agile dovrebbe essere calata in un contesto di continua trasformazione dell’organizzazione; dovrebbe essere il punto di riferimento per misurare, conoscere/evolvere e adattare l’ambiente di lavoro coinvolto della catena di delivery delle soluzioni software. A dirlo è Forreseter Research che in recente white paper intitolato “Make software delivery more responsive to the business” evidenzia quali siano gli “atteggiamenti” corretti per calare la metodologia Agile all’interno delle organizzazioni e per far sì che questa produca risultati concreti sul piano del business, intervenendo quindi anche nell’ambito dei processi.
Il mondo moderno, si legge nel documento realizzato dagli analisti Mike Gilpin e Dave West, richiede un delivery applicativo che non deve solamente guardare all’efficienza ma anche a elementi quali velocità di rilascio, flessibilità ed efficacia sul piano del business. Quella proposta da Forrester, infatti, è una vera e propria guida di “Agile And Lean Transformation” che fornisce una soluzione end-to-end per creare e migliorare le capacità di delivery applicativo delle organizzazioni secondo nuove logiche di “Agile and Lean”.
Le applicazioni guidano la business revolution
Secondo la società di analisi americana, il software sta assumendo un ruolo sempre più determinante rispetto all’abilità del business di rilasciare nuovi prodotti e servizi o di espandersi in nuovi mercati, trovare nuove vie di innovazione ecc. Questa correlazione, dice Forrester, ha “offuscato” la linea che demarcava l’innovazione di business e quella tecnologica: mentre prima la tecnologia “serviva” l’organizzazione, oggi ne è un partner di business, almeno in quelle organizzazioni che, a livello mondiale, stanno evolvendo per rispondere efficacemente a un contesto globale caratterizzato da incertezza, dinamicità e complessità. Per l’It, “salire sul palcoscenico centrale del business” è certamente una sfida “eccitante” ma, avvertono gli analisti di Forrester, i rischi sono molteplici. “Le aspettative del business sono elevate – scrivono Gilpin e West – e le software delivery operation dovranno imparare, in fretta, che le forze che incidono maggiormente sulla business technology sono tutt’altro che di natura tecnologica”.
Di queste forze, Forrester ne identifica alcune:
1) I consumatori hanno voce e possibilità di scelta: i canali sociali via web stanno assumendo un ruolo determinante nelle scelte dei consumatori e nell’influenzarne il comportamento di acquisto. I processi di sviluppo delle applicazioni devono tenerne conto; non è sufficiente creare un software correttamente; è fondamentale che rispecchi le esigenze del business e tutti gli stakeholder con cui l’azienda ha relazioni.
2) La tecnologia sta cambiando i modelli di business: le nuove tecnologie (social, mobile, tecnologie Internet based) stanno guidando la creazione di nuovi mercati e modificando il panorama dei servizi aziendali, interni ed esterni. Mentre le applicazioni tradizionali avevano come obiettivo automatizzare i processi di business model esistenti, oggi, i nuovi business model esistono solo grazie alla tecnologia. È evidente che parliamo quindi di un completo cambio di prospettiva: il software è più che mai “essenziale” per la competitività e l’innovazione di business.
3) L’ecosistema software gioca un nuovo ruolo cruciale: le esigenze di flessibilità e velocità del business spingono i processi di delivery a essere altrettanto flessibili e veloci. Il risultato è che nei processi applicativi entrano sempre più in gioco componenti di sviluppo esterni (esternalizzazione di parti di processi di sviluppo, come il testing, utilizzo di piattaforme via cloud ecc.) aggiungendo alla catena ulteriori elementi di complessità. È evidente che si rende necessario un nuovo approccio di software delivery, che tenga conto dell’intero ecosistema che ruota attorno all’applicazione (compresi i fruitori che sono gli user aziendali, ma anche i clienti, i fornitori, i partner ecc.).
4) Gli utenti hanno più potere, si sono innovati e hanno aspettative elevate: sono gli utenti stessi che si aspettano di poter guidare l’innovazione di business attraverso la tecnologia. Gli utenti aziendali hanno ormai buone conoscenze informatiche, utilizzano apps di derivazione consumer quotidianamente e si aspettano di avere a disposizione strumenti professionali che siano altrettanto efficaci, semplici e veloci da ottenere.
5) La real-time business data analytic guida le smarter apps: esattamente come il business cattura molti tipi di dati e li sfrutta per svolgere analisi in real-time, anche le nuove smarter apps possono essere abilitate grazie alla business intelligence (BI). Si sta già parlando, infatti, di connessione tra BI e apps che consentono al business di sfruttare la real-time analytic per effettuare analisi e prendere decisioni, che si riflettono immediatamente sul mercato o solo su alcuni determinati clienti attraverso una smarter app che, per esempio, consente agli utenti di avere uno sconto sull’acquisto di un prodotto o servizio.
Serve un programma di “Agile and Lean Transformation”
Figura 1: The Impact of Unknowns on Process Fonte: Forrester Research, Inc.
È evidente che in un contesto globale di enorme cambiamento come quello che stiamo vivendo da qualche anno, anche l’approccio allo sviluppo e al rilascio delle applicazioni deve evolvere. Gli approcci standard e l’adozione di stringenti modelli di governance aiutano ad assicurare la qualità del software e la compliance. Tuttavia, gli approcci tradizionali oggi potrebbero risultare fallimentari: il focus su processi, risorse ed efficienza sono indispensabili, altrimenti aumenta la complessità (figura 1), ma non più sufficienti. Serve un vero e proprio programma di “Agile and Lean Transformation”, dice Forrester.
In sostanza, la società di analisi americana, suggerisce alle aziende di introdurre le pratiche metodologiche Agile per lo sviluppo all’interno di un più ampio processo di lean transformation (trasformazione “snella”, intesa quindi come processo di semplificazione, riduzione della complessità).
Figura 2: The Agile and Lean Playbook Fonte: Forrester Research, Inc.
Per trasformare l’intera catena del valore del delivery software, come già anticipato, è fondamentale, per Forrester, adottare un approccio olistico, disegnando sia le pratiche Agile sia quelle Lean e tagliandole su misura rispetto all’ambiente It e al contesto aziendale all’interno delle quali verranno calate (figura 2).
Il programma proposto da Forrester è abbastanza complesso e prevede quattro differenti ambiti operativi e organizzativi: Prepare/Discover, Plan, Execute/Act, Optimize.
1) Prepare/Discover for Agile and Lean
Questo primo step risulta fondamentale perché consente alle organizzazioni di comprendere quale potrebbe essere il loro futuro adottando un programma di trasformazione dei processi di delivery del software, quali sono gli impatti di business e come procedere attraverso un adeguato framework di assessment.
1a) Fondamentale in questa prima parte di programma, suggerisce Forrester, avere ben chiari gli obiettivi e, quindi, trovare le giuste motivazioni per il cambiamento (che non è “gratuito” ma richiede investimenti economici, di risorse tecnologiche e di persone).
1b) In secondo luogo, è indispensabile conoscere a fondo lo stato attuale dell’organizzazione per capire quali evoluzioni e innovazioni apportare al portafoglio applicativo (si diceva, infatti, dell’importanza dell’assessment).
1c) Non ultimo, collegare la trasformazione dei processi applicativi alle strategie di business, affinché si possa veramente parlare di business technology.
2) Plan for Agile and Lean
La seconda parte del programma riguarda la pianificazione: è fondamentale identificare il proprio piano di cambiamento rispetto alle strategie di business e definire una roadmap che faccia da guida nel percorso di trasformazione. L’obiettivo primario è trasformare l’organizzazione dedicata al delivery software (dove per organizzazione si intende persone, processi, tecnologie) rispetto al modello di business e ai requirement dell’azienda.
2a) Primo passo da compiere, per poter pianificare il percorso di cambiamento, è stabilire uno “strategic change team”, identificando executive sponsor, change leader e change agents che possano correttamente trasferire i piani lungo tutti i livelli organizzativi.
2b) Secondo step, costruire un software development life cycle (Sdls) e renderlo centrale non tanto per guidare le pratiche di software delivery quanto, piuttosto, come strumento di analisi e mitigazione dei rischi.
2c) Pianificare quali team assoggettare alle pratiche di Agile and Lean Transformation e identificare come tali team possano indirizzare gli obiettivi di flessibilità e velocità richiesti dal business.
2d) Capire e stabilire quali pratiche e processi necessitano di tool tecnologici a supporto per gestire il lavoro, automatizzare determinati processi, velocizzare la costruzione e la realizzazione di queste practice.
3) Execute the Agile and Lean program
Il programma suggerito da Forrester, necessita dell’adeguato supporto sia in termini di persone sia di investimento economico per poter risultare efficace. Eseguire questo programma, sottolineano i due analisti, richiede un cambiamento della struttura organizzativa e del modello di governance. Ecco allora alcuni utili suggerimenti affinché il programma possa essere messo in atto adeguatamente:
3a) Non ci si deve dimenticare di far sempre riferimento alle pratiche di change management, dato che stiamo parlando di un importante programma di trasformazione.
3b) Non rimanere confinati ai modelli organizzativi esistenti. In molte realtà la metodologia Agile viene applicata solo ad alcuni team che rischiano quindi di diventare isole di self-organization all’interno della più ampia organizzazione di delivery del software. Secondo Forrester, il programma di cambiamento proposto dovrebbe, al contrario, essere pervasivo e coinvolgere tutta la struttura preposta al delivery applicativo, a tutti i livelli.
3c) Rivalutare i propri partner esterni e definire nuovi modelli di partnership con vendor che riescano ad accompagnare l’organizzazione nel percorso di trasformazione e condividere la vision e gli obiettivi (dato che da questo ne nascerà anche un nuovo ecosistema software)
3d) Creare dei coach, ossia del team leader che sappiano guidare i team nel percorso di trasformazione e sappiano “tenere alta” la motivazione e l’entusiasmo (come già accennato, la sfida è eccitante, ma i rischi non sono banali).
3e) Anche in questo caso, identificare i tool tecnologici che possono essere di supporto nel rendere eseguibile il programma di cambiamento.
4) Optimize the Agile and Lean program
Il programma proposto da Forrester rappresenta le fondamenta per costruire un sistema di software delivery che sia in grado di evolvere e migliorare di continuo. Capacità di misurazione e controllo, nonché trasparenza dei processi e delle informazioni sono dunque dei requisiti fondamentali, affinché il programma risulti modellabile e adattabile nel tempo.
L’ottimizzazione del programma richiede dunque un impegno particolare per:
4a) misurare il successo del cambiamento: identificare metodi di misurazione che consentano di valutare l’efficacia del business case introdotto (di Agile and Lean program) rispetto agli obiettivi di business. Questo assicura la possibilità di trovare, nel top management, supporto e fondi per programmi futuri.
4b) risultare trasparente e consistente: il sistema di misurazione e controllo deve essere trasparente e coerente con le strategie It e di business; l’ideale sarebbe estendere gli strumenti di misurazione dello sviluppo applicativo a un livello più elevato, controllando, per esempio, il valore di business prodotto con il rilascio delle applicazioni non solo dopo la messa in produzione, ma anche durante i vari cicli di sviluppo.
4c) incoraggiare il Kaizen (composizione di due termini giapponesi: Kai, cambiamento, miglioramento; Zen, buono, migliore – ndr): tutti sono responsabili della riuscita del programma, scrivono i due analisti di Forrester. È fondamentale che siano coinvolti ma, soprattutto, che capiscano il perché del cambiamento.
4d) costruire un ambiente che supporti il cambiamento: sempre sul tema del coinvolgimento delle persone, Forrester suggerisce, da ultimo, di creare delle community interne che facciano da catalizzatore per condividere idee e stimolare la collaborazione tra team. È fondamentale, comunque, che all’interno di queste community siano “rappresentate” tutte le discipline che ruotano attorno al delivery software: project management, testing, business analysis e development management.
