Far funzionare l’Agile con Metagility (con David Bishop di Agile Worx)

Leggi la trascrizione:

Stiamo sperimentando la trascrizione dei nostri podcast tramite un programma software. Perdonaci per eventuali errori di battitura: il bot non è accurato al 100% delle volte.

Ben Aston: Lascia che indovini: lavoravi in modalità Waterfall, e non ha funzionato, poi hai provato Agile e, beh, neanche quello sta funzionando davvero.

Ora stai mischiando e combinando. Hai un po' di Agile e un po' di Waterfall e stai cercando di trovare la giusta "spolverata" da aggiungere sopra. Continua ad ascoltare il podcast di oggi su metagility. Potresti imparare qualcosa su come utilizzare un playbook Agile per combinare il meglio di entrambi i mondi.

Grazie per averci seguito. Sono Ben Aston, fondatore di The Digital Project Manager. Benvenuto nel podcast DPM. La nostra missione è aiutare i project manager a ottenere successo, aiutare chi gestisce progetti a consegnare meglio. Siamo qui per aiutarti a portare la gestione dei tuoi progetti al livello successivo. Dai un'occhiata a thedigitalprojectmanager.com per scoprire tutti i corsi e le risorse disponibili per i membri. Questo podcast è presentato da Clarizen, Leader nel Software di Project e Portfolio Management per l'Enterprise. Visita Clarizen.com per saperne di più.

Oggi sono qui con David Bishop, il Dott. David Bishop è un tecnologo. È consulente, imprenditore nella ricerca e docente con oltre 25 anni di esperienza in ambiti Telco, trasporti, enti pubblici e utility. È CEO e fondatore di Agile Worx, LLC. Puoi dare un'occhiata su Agile-worx.com. Offrono strumenti per la gestione di programmi e progetti, formazione e servizi di consulenza. È anche autore di Metagility: Gestire lo Sviluppo Agile per un Vantaggio Competitivo. Grazie mille per essere oggi con noi, David.

David Bishop: Grazie a voi per avermi invitato.

Ben Aston: Vorrei entrare nel merito dell’idea di costruire un framework da zero. Puoi raccontarci un po’ del tuo percorso, di come sei arrivato a pensare che il mondo avesse bisogno di un nuovo framework? Che esperienze ti hanno portato fino a quel punto?

David Bishop: Certo. Sono nel settore dello sviluppo tecnologico da circa venticinque anni, e per lo più come architetto e ingegnere di sistemi, sviluppando soluzioni con nuove tecnologie. Nel business IT, nell’ambiente IATA, nella telefonia mobile e tutto il resto. Come hai detto prima, circa dieci anni fa ho iniziato a lavorare in un’azienda molto attiva nell’IoT industriale e una delle cose che cercavano disperatamente di fare era adottare metodologie Agile.

Ben Aston: Certo.

David Bishop: E il motivo era che i loro clienti lo richiedevano, perché erano su un mercato nuovo. Nuovo per la tecnologia, non per l’industria: cercavano di integrarsi in quel settore. C'era molta concorrenza che sviluppava questa nuova tecnologia smart grid con tutte le diverse comunicazioni RF.

Questa era la base tecnologica di tutto. Hanno provato più volte ad adottare Agile, perché era fondamentale per portare i prodotti sul mercato il più rapidamente possibile. Hanno provato spesso, affidandosi a molti consulenti costosi, riscontrando fallimenti ripetuti. Ho preso parte a questa sfida, aiutando a sviluppare prodotti e supportandoli nell’adozione Agile. Ho pensato: ci dev’essere un altro modo per farlo.

Perché questi consulenti così brillanti hanno fatto così fatica? Ho realizzato che Agile, pur avendo avuto molto successo e essendo una grande idea, presenta criticità. Una di queste riguarda i team distribuiti o di grandi dimensioni, ma anche ambienti di sviluppo molto complessi o con prodotti complicati. Sono sfide enormi per chi tenta di adottare metodologie Agile nella loro forma più pura.

Ben Aston: Sicuramente. Raccontaci qualcosa delle tue esperienze su questi progetti. Mi incuriosisce il lato pratico. Capisco la visione globale e le sfide nell’implementazione Agile, ma quotidianamente, in concreto, come era la situazione? Quali sono stati i segnali d’allarme per capire che qualcosa non stava funzionando?

David Bishop: C’è stata una resistenza enorme da parte di alcuni team. Non parlo della solita reticenza, ma di vera opposizione con lamentele sul fatto che il processo proprio non funzionava e non poteva funzionare. Era un ambiente a sistemi embedded: sviluppavano prodotti IoT industriali, quindi non era solo software ma anche dispositivi fisici, con hardware, firmware e software sviluppati da team (o reparti, o aziende) diversi.

A un certo punto però, tutti questi componenti devono essere testati e rilasciati come un unico prodotto. È questo che rende il contesto di oggi così interessante: qui nasce l’innovazione. Anni fa, quando è uscito il Manifesto, si parlava soltanto di software. Oggi riguarda dispositivi, smart device, contatori intelligenti, auto smart, il tuo cellulare… quasi tutti sono sistemi embedded.

Queste aziende hanno le maggiori difficoltà con l’agilità, per la complessità dei loro prodotti. Quotidianamente, lavorando con i consulenti, ci siamo detti: bene, i team software fanno sprint di due settimane e stand-up giornalieri, ma non riusciamo a coinvolgere i team hardware, che non lo ritengono necessario.

Ben Aston: Certo.

David Bishop: Lo stesso per i team firmware: non funzionava per loro e avevano ragione, poiché il software avanzava velocemente seguendo approcci iterativi di sviluppo incrementale, ma l’hardware aveva cicli di rilascio da 12 a 18 mesi.

Serviva molto tempo per integrare e testare a fondo un chipset nell’hardware… e soprattutto, in questi settori embedded, spesso soggetti a regolamentazione e controlli governativi…

Se pensi a contatori intelligenti, utility, auto smart, avionica: qui, il rischio di perdita di vite o guasti catastrofici è talmente alto che devi mantenere standard di qualità e performance molto più elevati rispetto ad un’applicazione software o un sito ecommerce.

Ben Aston: Giusto.

David Bishop: I settori che hanno adottato l’Agile più rapidamente sono proprio quelli dove il rischio era minore, quindi era più facile adottare metodologie Agile.

Ben Aston: Se vuoi leggere di più sulla genesi di Metagility, c’è un post su thedigitalprojectmanager.com dove si racconta la storia che ha portato alla creazione del libro. Ora però vorrei andare oltre e parlare del framework vero e proprio, vedere se ci sono spunti applicabili ai nostri progetti. Credo sia rilevante, perché molti di noi hanno provato elementi Waterfall (si fanno processi sequenziali quando richiesto dagli stakeholder o dalla struttura dei progetti), ma tentano anche approcci Agile, con collaborazione e iterazioni. Prendiamo quello che ci serve: filosofia, iterazione, valore rilasciato spesso, costruire, testare, imparare… però a volte bisogna operare anche in modo sequenziale. Parliamo di metagility e di come applicarla nei nostri progetti.

La realtà è che le metodologie Agile sono popolari e ampiamente accettate nella gestione dello sviluppo software, ma il loro significato è aperto all’interpretazione.

Come abbiamo visto, rappresentano una sfida reale per molte aziende. Questo approccio ibrido, anche se spesso non considerato la soluzione migliore, è in realtà il risultato più comune per molti, che tentano di mettere insieme framework e metodi diversi per adattarli ai vincoli organizzativi. L’hardware richiede cicli più lunghi rispetto al software, il middleware è una via di mezzo.

Serve coordinare i rilasci con lo stesso ritmo. Lo vediamo anche nello sviluppo web: UX e design procedono veloci, lo sviluppo richiede più tempo. Parliamo delle limitazioni delle pratiche Agile attuali che descrivi nel libro.

Quando individui queste limitazioni rispetto agli attuali metodi Agile? Puoi entrare più nel dettaglio? Confrontaci, ad esempio, tra il livello alto (SAFE) e il livello operativo (Scrum). Quali limiti vedi?

David Bishop: Quando si parla di framework come Scrum, Kanban, e molti altri (DSDM, LeSS, DA-Disciplined Agile, ora acquisito dal PMI), si affrontano problemi da diverse angolazioni.

Ben Aston: Sì, io non compro framework. Fa piacere.

David Bishop: Sì... Ognuno prova ad attaccare il problema con logiche proprie. C’è grande attenzione oggi nell’introdurre l’Agile per migliorare la collaborazione nei team, per far lavorare meglio le persone insieme, fare leadership migliore o migliorare efficienza. Tutto ottimo.

Ma il vero scopo di Agile era ed è la competizione: essere i primi sul mercato. Il Manifesto Agile deriva direttamente dal lean manufacturing Toyota, introdotto attraverso principi sviluppati nel 1979 da due ricercatori giapponesi. Cosa ha prodotto per Toyota? Da costruttore di auto di bassa qualità, li ha portati a diventare il leader nel settore automobilistico.

Tutta l’agilità mira a replicare quel successo per dominare il proprio mercato. Questi framework spesso se ne dimenticano: SAFE ad esempio guarda l’azienda a 30.000 piedi, punta a “agilizzare” tutti i reparti aziendali (HR, legale, ecc.), sperando in miglioramenti incrementali… rischia però di diventare troppo processuale e similare ai vecchi sistemi SOP documentali, contrari allo spirito Agile.

Ben Aston: Giusto

David Bishop: Metagility invece si concentra sulla parte centrale: dove SAFE opera su scala aziendale e Scrum sui team, Kanban sul processo, metagility punta al motore dello sviluppo prodotto, ossia product management, project management, sviluppo, test, gestione delle richieste utente, collaborazione col cliente, qualità finale.

Se vuoi vincere una gara, costruisci il motore, il cambio, la trasmissione: non punti agli optional. Molti framework si concentrano sui dettagli invece che su ciò che serve davvero per arrivare primi. Metagility si fonda su ricerche: analizza casi reali che hanno raggiunto altissimi livelli di adattamento agile fino a dominare il proprio mercato, ne sistematizza le prassi efficaci così altre organizzazioni possono replicare quei risultati.

Ben Aston: Lo definisci come un approccio completo per gestire una nuova ed efficace tipologia di identità. Cos’è precisamente metagility? Un framework di delivery? Una metodologia? Un playbook?

David Bishop: Lo definisco come un framework. La prima fase di metagility, ad esempio, consiste nello stabilire che tipo di adozione Agile perseguire. Ma prima ancora il libro insegna a pensare diversamente, scegliendo metodologie scientifiche per le decisioni aziendali e spiegando come il Manifesto Agile sia cambiato coi risultati della ricerca.

Arrivati alla trasformazione Agile, la prima domanda è: quale tipo di implementazione scegliere? Pura Agile, ibrida, o forse rimanere su Waterfall? Esistono molte ricerche peer-reviewed su questo. Un ricercatore, Barlow, ha pubblicato un lavoro che guida questa decisione. L’ho inclusa nel libro come tabella: la scelta dell’approccio dipende dalla complessità delle dipendenze/prodotti e dalla dimensione dei team.

Spesso, quando si hanno prodotti complessi, team distribuiti e molte interdipendenze, non si può adottare un puro approccio Agile: serve un’ibrida, che, se progettata consapevolmente, porta ottimi risultati.

Nel settore, spesso l’ibrido gode di cattiva fama perché considerato sinonimo di fallimento delle trasformazioni Agile. Questo vale quando l’ibrido deriva da improvvisazione. Ma se nasce da una scelta ragionata, secondo ricerca scientifica, allora si procede nella giusta direzione.

Ben Aston: Per chi non ha letto il libro, in cosa consiste il framework metagility? Come funziona, quali sono le sue componenti?

David Bishop: Nel libro troverai una tabella dettagliata di tutti gli elementi. Essenzialmente, la prima parte è la scelta della strategia di trasformazione.

Ben Aston: E come la si valuta?

David Bishop: Grazie al diagramma di Barlow (presente nel libro): valuta team e complessità del prodotto, le interdipendenze, quanti team devono lavorare insieme e coordinarsi. Questo permette di capire se serve un approccio ibrido o meno.

L’approccio ibrido, descritto da metagility, definisce concretamente come allineare i tempi: team software con sprint di 2 settimane e stand-up giornalieri, firmware 30 giorni e stand-up settimanali, hardware con cicli di 12–18 mesi e, se serve, poche cerimonie Scrum. Gli hardware possono adottare tecniche di prototipazione rapida per mantenere il passo e fornire ciò di cui i team hanno bisogno senza blocchi. Serve mantenere il flusso di tutto il processo.

Il framework definisce anche l’adozione dei “gates” waterfall come checkpoint di controllo nell’approccio ibrido, per mantenere sincronizzati i team con velocità diverse.

Vengono anche specificati i diversi tipi di metriche e le interazioni fra i team. In Agile si parla molto di “persone e interazioni sopra processi e strumenti”, ma cosa sono di fatto queste interazioni? Nel libro sono suddivise in sei categorie, basandosi sui casi di successo, e vengono dettagliate per facilitare l’applicazione pratica.

Ben Aston: Come si determina il giusto mix agile tra team? Come capire quando lo status quo è accettabile e quando invece serve un’evoluzione o rivoluzione nel processo?

David Bishop: Serve seguire il metodo scientifico e la ricerca sul campo (engaged scholarship). Troppo spesso le decisioni si basano su intuito, best practice o interviste. Non c’è niente di sbagliato, ma per trasformazioni Agile, DevOps o digitali occorre un approccio più rigoroso. Come quando ti ammali: puoi curarti a casa, ma se peggiora, serve il medico.

Questo pattern di fallimento ricorrente nasceva dal fatto che i consulenti tentavano di applicare quello che aveva funzionato altrove. Ma le ricerche nei sistemi informativi dimostrano che ogni contesto aziendale è molto specifico. Solo con case study, etnografia e metodo scientifico puoi capire cosa è generalizzabile da un'organizzazione all’altra.

Ben Aston: Quindi non è un framework "taglia unica" ma personalizzabile. Ma come si valuta se una implementazione è veramente metagility? Come si misura il successo?

David Bishop: Ottima domanda. Metagility include anche la teoria della "vorticity Agile". Insieme ai concetti di ibrido Agile e le interazioni, questa teoria (nata da analisi qualitativa) risponde alla domanda: quanto è Agile la tua organizzazione? Dopo tanti sforzi, come sai se la trasformazione Agile ha prodotto risultati? Come sai dove migliorare?

Non esistevano prima metodi di misurazione. Agile Vorticity risponde proprio a questo, spiegato in dettaglio nel libro e nei paper. Quindi metagility fornisce finalmente un modo concreto per misurare il successo.

Ben Aston: Che impatto hai visto nelle organizzazioni che hanno adottato il framework? C’è stato il raggiungimento del market leader?

David Bishop: Molti case study sono nel settore embedded, il più sfidante. Le aziende che hanno abbracciato le pratiche metagility sono spesso divenute leader o comunque tra i primi del mercato… In pratica, questo significa più dispositivi sul campo, più smart devices nelle mani degli utenti rispetto ai concorrenti: questo è il successo.

Chiunque abbia un nuovo prodotto o sia una start-up deve assicurarsi quella fetta critica di mercato prima degli altri, grazie all’innovazione e commercializzazione rapida. Agile, e in particolare metagility, è il modo migliore di riuscirci: ridurre i tempi ciclo, mantenere qualità e soddisfazione cliente, conquistare quota di mercato quando fa la differenza.

Ben Aston: Dove invece hai visto fallimenti? Quali sono stati gli ostacoli all’implementazione?

David Bishop: Due aspetti critici: il primo, senza supporto e coinvolgimento degli executive l’iniziativa non va lontano. Chi decide deve sapere cosa si sta cercando di raggiungere e perché. Sta a noi proporre un business case efficace che dimostri il valore economico e i benefici concreti.

Il secondo: gestione carente dei requisiti. Ci si concentra troppo spesso sul set-up dei team e sull’implementazione tecnica, trascurando requisiti e analisi di business (prodotti, PO). Spesso il BA passa a fare da PO, ma non cambia il modo di sviluppare i requisiti: in Waterfall si "raccolgono", in Agile si "sviluppano" costantemente con il cliente. Se non si cambia questo modo di lavorare, si produce un’esplosione di requisiti, impossibile da prioritizzare, con release che si riempiono di funzioni inutili e aumento del debito tecnico… così falliscono tutte le trasformazioni Agile, anche quelle con metagility. Serve coaching anche sul ruolo del PO nelle pratiche Agile.

Ben Aston: Concordo: se la fase di analisi requisiti dura troppo, non si esce mai dal "come dovrebbe essere". Se sono nuovo a metagility, qual è il primo passo da compiere in azienda per ottenere benefici?

David Bishop: Il primo vero passo è creare nuove relazioni di collaborazione col cliente. Uno dei principi del Manifesto cita la collaborazione col cliente più importante del contratto. In realtà, le due cose sono un tutt’uno: la negoziazione accade a tutti i livelli. Bisogna coinvolgere il cliente nel test del prodotto innovativo. Le aziende di maggior successo che abbiamo studiato avevano una chiara visione e selezionavano i clienti giusti, anche rifiutandone alcuni.

Non si tratta solo di fare cassa immediata ma di scegliere gli interlocutori disposti a partecipare a processi collaborativi e a sostenere la nostra direzione strategica.

Ben Aston: Parole sagge. Spesso prendiamo quello che arriva, invece occorre scegliere partner con cui davvero possiamo collaborare per produrre valore reale. Modello di collaborazione solido, fiducia e trasparenza sono la base, più che contrattazione a oltranza. Grazie David per questa chiacchierata su metagility!

David Bishop: Grazie a voi.

Ben Aston: Fateci sapere se avete letto il libro Metagility e cosa ne pensate — scrivete nei commenti, mettiamo il link alla fine della trascrizione. David, dove si può saperne di più?

David Bishop: Cercando "metagility" su Google troverete tante risorse, oppure visitate Agileworx.com (Agile-worx.com) per scoprire la nostra azienda e i servizi offerti (corsi normalmente in presenza, rimandati in autunno, da agosto a novembre, o eventualmente convertiti in virtuale). Su metagility.technology trovate sempre il calendario aggiornato. Potete scrivermi a David@agileworx.com (Agile-worx.com), rispondo sempre.

Ben Aston: Perfetto. E se volete migliorare e progredire nel vostro lavoro, iscrivetevi alla Membership DPM: thedigitalprojectmanager.com/membership. Avrete accesso al nostro team Slack, template, workshop, AMA, office hours, e-book e altro! Se vi è piaciuto questo episodio, iscrivetevi e restate in contatto su thedigitalprojectmanager.com. Alla prossima, grazie per averci ascoltato.