Agile e TBM: trasformare in meglio il business dell'IT

*Dean Leffingwell è il creatore dello Scaled Agile Framework (SAFe) e co-fondatore di Scaled Agile, Inc. Lavora con aziende che stanno scalando Agile da pochi team a decine, e persino centinaia, di team che creano sistemi e soluzioni software su larga scala. 

Un analista IT lo ha riassunto alla perfezione: "Solo pochi anni fa, le aziende facevano un po' di Agile e spendevano dai 5 ai 10 milioni di dollari in programmi Agile. In termini di investimenti e governance, non importava come si spendeva e per cosa. È stato un esperimento interessante e i risultati sono piaciuti. Ma ora stanno valutando programmi che richiederanno da 50 a 100 milioni di dollari o più di investimenti e saranno realizzati con Agile. Questo cambia tutto".

Questo aspetto attira l'attenzione dei vertici aziendali poiché i CIO e i CFO, in particolare, si rendono conto di non poter più ignorare Agile: sta per superare la maggior parte dei processi aziendali. Se non implementano ora nuovi modelli finanziari e di governance, saranno travolti.

Oggi, le prestazioni delle aziende che hanno scalato con successo lo sviluppo Agile sono evidenti nei rilasci più frequenti, i tempi di immissione sul mercato più rapidi, la maggiore qualità e il migliore coinvolgimento dei dipendenti. La produttività può aumentare in modo significativo, magari dal 30% al 50%, riducendo il time to market in genere di due o tre volte o più. Il coinvolgimento dei dipendenti aumenta perché vedono che il loro codice viene immesso sul mercato più rapidamente e ricevono feedback più rapidi dagli utenti.

Il fatto è che Agile non è una moda passeggera. È un megatrend che sta trasformando il business (e il business dell'IT) in meglio.

Agile richiede attualmente un diverso tipo di coinvolgimento con l'azienda. In passato, il team IT avrebbe potuto dire: "Ok, ecco cosa hai chiesto". L'azienda potrebbe rispondere alla consegna (un anno dopo) e dire: "Non è proprio quello che è stato richiesto e, a proposito, le esigenze dell'azienda si sono evolute e richiedono ora qualcos'altro".

L'IT aveva tradizionalmente una buona logica: collaborare con gli analisti aziendali, annotare le specifiche, elaborare il business case, creare la soluzione e poi passare ad altro.

In realtà, non funziona così. Dal punto di vista dell'IT, la realtà è questa: la tua soluzione è buona solo quando i proprietari del business dicono che è buona. Non importa se l'hai creata secondo le specifiche. Importa solo se il proprietario del business afferma che risolve il suo problema e vuole continuare a collaborare.

È qui che entra in scena Agile. Le persone delle linee di business che beneficiano da queste applicazioni devono partecipare e rimanere coinvolte nello sviluppo della soluzione. Non esiste un metodo "scrivi le specifiche, fai un assegno e vattene". Ora, l'impatto sull'azienda è significativo, ma anche il livello di coinvolgimento richiesto è più elevato. L'unico modo per creare una soluzione è costruirla insieme.

Il modello Agile scalabile coinvolge direttamente il proprietario del business nel feedback, nel processo decisionale informato, nella continua definizione delle priorità del lavoro e in tutto ciò che è necessario per assicurarsi che il risultato soddisfi le esigenze attuali. Il tradizionale passaggio di consegne è cambiato. Lo sviluppo di soluzioni Agile non è una funzione isolata o una serie di specifiche. Non si tratta di un caso aziendale che dimostra un punto in via teorica; piuttosto, si tratta di persone che lavorano insieme in modo collaborativo durante l'intero periodo dello sviluppo.

Purtroppo, i tradizionali modelli di finanziamento basati su progetti non funzionano con Agile. Questi progetti creano "lavoro temporaneo per persone temporanee" e, sebbene sia un modo pratico per organizzare il tuo pensiero intorno al nuovo lavoro, non supporta un flusso continuo di valore.

Con Agile, gestisci il lavoro in modo diverso. Non è in base alle singole attività e all'utilizzo del tempo, bensì attraverso piccoli segmenti di valore che desideri veder fluire nel sistema in tempo reale. L'impatto è immediatamente visibile quando qualcuno afferma che la propria azienda è organizzata in modo funzionale, avvia progetti e misura gli utilizzi.

Il mantra Agile è: prodotti, non progetti. Ciò rappresenta un cambiamento significativo nel modo in cui l'organizzazione pensa agli investimenti, alle finanze e ai rendimenti e richiede strumenti basati sul valore anziché sulle attività. Gran parte di ciò che esiste ora nella contabilità tradizionale in relazione al lavoro basato su progetti (timesheet, registrazioni e acquisizione di dati) rappresenta un enorme ostacolo al flusso di valore.

Agile significa rispondere al cambiamento anziché seguire un piano. E ciò richiede un passaggio alle prove oggettive: feedback rapidi, indicatori precoci e prevedibilità. I team Agile hanno fatto ciò che avevano promesso di fare in un determinato periodo di tempo? Se un imprenditore vuole fare qualcos'altro, i team Agile possono cambiare rotta?

Nel complesso, il modello passa dal ROI allo sviluppo basato su ipotesi e al minimal viable product (MVP). La nozione teorica del ROI è allettante tanto quanto un numero concreto, tuttavia il ROI è solo un'ipotesi su quale potrebbe essere il rendimento se le cose andassero secondo i piani. E raramente le cose vanno secondo i piani. Anche quando ciò avviene, i dati non sono disponibili finché non è troppo tardi, perché il ROI non fornisce alcun feedback durante lo sviluppo.

Per comprendere l'efficacia di Agile, cerchiamo invece indicatori precoci e le cosiddette misure contabili dell'innovazione. Definiamo i predittori di un buon valore, e questi predittori vengono molto prima del ROI. Di fatto, i sistemi devono essere progettati non solo in base ai costi, ma anche in base al valore che ne traggono gli utenti.

La discussione iniziale sull'investimento riguarda prima l'ipotesi e poi come dimostrarla. E, naturalmente, quanto costa arrivare a quel primo punto. In genere, è una frazione dell'investimento complessivo perché i team possono ricevere il feedback sull'MVP entro un periodo di tempo concordato (ad esempio alcune settimane o mesi). Alla fine, si discute se procedere con l'investimento o se passare a qualcos'altro.

Il beneficio è che questo modello snello è in gran parte immune ai costi irrecuperabili. Nel mondo tradizionale, se hai già fatto un investimento da 5 milioni di dollari, questo investimento deve ripagare. Gli stakeholder non amano chiamarlo spreco o sperimentazione. Alcuni meccanismi di difesa potrebbero avere effetto, come l'approvazione di altri 10-20 milioni di dollari per mantenere vivo il sogno, indipendentemente dal fatto che ci sia o meno del valore.

L'impresa Agile non fa questo. Finanziamenti a ondata continua, MVP, ignorare i costi irrecuperabili e prendere decisioni su misure oggettive basate sulla contabilità dell'innovazione: è così che l'azienda Agile svolge il suo lavoro, un'ipotesi alla volta.

Nello sviluppo Agile non si aspettano anni per nulla. Se stai valutando un programma importante, le prove compaiono entro le prime sei-dodici settimane. Dopo alcuni incrementi del programma, le prove indicheranno se procedere lungo quella strada più lunga o meno.

Le metriche indirette e dirette possono aiutare a misurare il valore dei prodotti forniti attraverso Agile. Indirettamente, si può misurare la velocità o il numero di storie o di punti di storia che i team possono realizzare in un'unità di tempo. Invece di guardare la struttura di ripartizione del lavoro, puoi valutare come un lavoro simile in passato abbia utilizzato quella capacità.

È importante prima cercare la prevedibilità: hai fornito il valore per cui ti sei impegnato nel lasso di tempo previsto? Quindi puoi adattarti e iniziare a parlare del motivo per cui questo obiettivo è molto più importante degli altri. È anche semplice controllare qualcosa come un punteggio NPS per valutare i risultati con gli imprenditori. Che livello di fiducia hai? Raccomanderai ad altri i team valutati?

Il passaggio dalla metodologia a cascata ad Agile sfida il modo tradizionale di trattare CapEx e OpEx. Le regole del FASB dicono che, al momento della comprovata fattibilità e dell'approvazione della gestione, è possibile capitalizzare la manodopera e ammortizzarla nel corso della vita utile del progetto, il che influisce sulle entrate.

Nel modello a cascata, dopo che i requisiti e la progettazione sono stati determinati e approvati, puoi capitalizzare. In Agile non esiste questo processo stage-gate. Si costruisce la soluzione un pezzo alla volta, ma si può comunque capitalizzare.

C'è ancora molto lavoro da fare nell'innovazione, nella ricerca, nell'infrastruttura e in tutto ciò che non riguarda direttamente l'aggiunta di caratteristiche al sistema. Su questo ancora non si capitalizza. Tuttavia, in Agile ci sono delle “storie” che implementano nuove caratteristiche. Se si dispone di una storia per una funzionalità come un nuovo meccanismo di Single Sign-On, è possibile capitalizzare. E potresti non avere nemmeno bisogno di timesheet per farlo. Ma la capitalizzazione richiede una spiegazione, una conversazione che deve avvenire.

Oggi, Agile su larga scala ha un impatto sugli stakeholder responsabili della governance e degli investimenti. Poiché i reparti IT spesso operano ancora con una trasparenza dei costi limitata, la percezione della gestione finanziaria dell'IT può essere: "Ecco il nostro grande centro di costo. Ecco la spesa e, nel tempo, otteniamo vari risultati aziendali e abbiamo davvero difficoltà a correlarli all'investimento. Ripartiamo i costi".

Per dimostrare il valore che apportano, la trasformazione Agile richiede che i leader IT capiscano come misurare l'impatto finanziario e il valore dello sviluppo continuo, quando capitalizzare la manodopera e come fornire visibilità alle iniziative finanziate. Necessiti del giusto livello di trasparenza per determinare se stai investendo nelle cose giuste e nel modo giusto nell'IT. È qui che i responsabili IT ricorrono alla gestione della tecnologia aziendale (TBM).

Il TBM è una disciplina che migliora i risultati aziendali offrendo alle organizzazioni un modo uniforme per tradurre gli investimenti tecnologici in valore aziendale. Il TBM definisce gli strumenti, i processi, i dati e le persone necessari per gestire il business della tecnologia. È supportato da una tassonomia TBM standardizzata e da un framework che struttura i problemi che i leader di tecnologia e business stanno cercando di risolvere, incluso il finanziamento di Agile su larga scala.

Il TBM prevede una tassonomia e una reportistica standardizzate, indipendentemente dai modelli a cascata o Agile. Queste caratteristiche aiutano le imprese a fornire visibilità sulle metriche finanziarie per lo sviluppo di applicazioni basate su Agile e a organizzare risorse e risultati in attività specifiche del flusso di valore. I risultati sono l'allineamento con i risultati aziendali e l'aumento del valore aziendale.

Alcune delle più grandi aziende del mondo hanno circa 10.000 addetti IT e forse 5.000 o 6.000 di questi lavoratori stanno sviluppando applicazioni, una spesa significativa. Si tratta di un centro di costo o di un centro di investimento? È una questione di prospettiva, ma è necessario sapere come monitorare lo sviluppo Agile se si vuole capire come vengono spesi quei soldi. Il processo richiede di pianificare come avviare, finanziare e misurare i prodotti Agile.

Per essere visti come un partner a valore aggiunto, è necessario comprendere il flusso di valore e la spesa per i dati e la comunicazione. Queste preoccupazioni sono importanti, ma la conversazione si sta spostando maggiormente su come competere con nuove soluzioni.

È naturale volere che tutto sia predittivo, mappato su un piano e correlato ai budget futuri, ma insieme alle spese, è limitante.

Sì, vuoi sapere in anticipo cosa non si può conoscere e garantire il ROI in base a questo, ma non è realistico. Quando puoi stare al fianco degli stakeholder aziendali di livello C nel consiglio di amministrazione e spiegare gli investimenti e i risultati attuali, invece di impegnarti in piani pluriennali, puoi essere competitivo.

La buona notizia è che Agile sostituisce tutta quella speculazione sul ROI con prove oggettive in tempo reale. Invece di lavorare con i requisiti attuali per due anni, si elabora il primo pezzo e lo si consegna. Adesso.

Il più grande punto di forza di Agile è la capacità di prendere quell'iniziativa di massa, dividerla in parti e fornire valore quasi immediatamente. Il vantaggio è che scopri se sei sulla strada giusta prima piuttosto che dopo.

Il rapido ritmo della tecnologia significa che più aziende devono adottare metodologie Agile, come lo scaled agile framework (SAFe), per rispondere rapidamente ai modelli di business, ai mercati e alla tecnologia in evoluzione. Di conseguenza, devono gestire la spesa sempre più alta per la tecnologia e ottenere trasparenza sui costi dell'IT. Le organizzazioni possono utilizzare TBM e SAFe insieme per offrire più valore, con maggiore trasparenza, per ottenere una maggiore agilità aziendale e collaborare con l'azienda.