Muoversi velocemente, rimanendo al sicuro: essere "agili" nella pubblica amministrazione

Questo articolo è stato scritto da Paul Craig, Senior Developer, CDS Platform Team presso il Canadian Digital Service (CDS). Questo articolo è stato pubblicato per la prima volta sul blog di CDS, che collabora con i dipartimenti federali canadesi per creare servizi digitali più semplici e fruibili.

È un ottimo momento per lavorare nei dei servizi digitali perchè le persone sono più connesse che mai. Allo stesso tempo, lo sviluppo "agile" - che consiste nel costruire e testare prototipi in poche settimane piuttosto che dedicare anni alla pianificazione - ha guadagnato un'ampia accettazione.

In qualità di Technical Lead presso il Canadian Digital Service (CDS), ho visto molti dei problemi in cui incorrono i nuovi team, derivanti da uno scontro culturale tra coloro che utilizzano metodologieagili che privilegiano il “codice” e i processi a cascata ad ampio utilizzo “cartaceo”. I dipartimenti vogliono che anche i team agili lavorino con i gruppi di approvazione, il che significa, in ultima analisi, trovare una collocazione all'interno delle culture dipartimentali esistenti e far completare il lavoro come qualsiasi altro team.

La metodologia Agile dà priorità al coinvolgimento degli utenti dall’inizio. Il feedback degli utenti non solo fornisce indicazioni per migliorare il prodotto, ma funge anche da documentazione interna che aumenta la vostra credibilità.

In un team agile, il punto di forza è la capacità di prototipare rapidamente e di parlare con gli utenti, ma il punto debole è la percezione che queste pratiche introducano rischi eccessivi. È fondamentale trovare un equilibrio tra la rapidità con cui si arriva al lancio del prodotto e alla stesura della documentazione richiesta dai processi di lancio tradizionali. I team agili di successo devono muoversi velocemente ed essere sicuri.

Muoversi velocemente: il vantaggio della metodologia agile

I team agili sono davvero preziosi. Alcune delle più grandi aziende di oggi sono arrivate dove sono perché i flussi di lavoro agili sono molto efficaci nel fornire rapidamente valore, battendo aziende più affermate con modelli di realizzazione più lenti.

In generale, come parte di un team agile, si desidera definire il proprio MVP (minimum viable product) e poi testarlo con gli utenti il prima possibile. La pianificazione a cascata non risponde bene alle "esigenze degli utenti". La metodologia Agile dà priorità al coinvolgimento immediato degli utenti. Il feedback degli utenti non solo fornisce indicazioni per migliorare il prodotto, ma funge anche da documentazione interna che aumenta la vostra credibilità.

Una volta sicuri che il vostro prodotto funziona, concentratevi su ciò che dovete fare per lanciarlo. È molto meglio avere un servizio "alfa" lanciato che un prototipo interno altamente perfezionato. Naturalmente, il prezzo della "velocità" è convenzionalmente un compromesso con la sicurezza, quindi è necessario bilanciare la "velocità" con la "sicurezza".

'Essere sicuri' con la metodologia agile

Per i team agili, ci sono 4 modi principali in cui lo sviluppo agile è più sicuro del tradizionale sviluppo di prodotti a cascata.

1. La metodologia Agile riduce gli errori esistenziali nella progettazione di un servizio: il coinvolgimento precoce degli utenti attenua il rischio di lanciare un servizio poco performante.
2. La metodologia Agile riduce il costo degli errori: l'iterazione frequente comporta cambiamenti minori e più frequenti, il che significa che gli errori tendono a essere inferiori e più veloci da riparare.
3. La metodologia Agile riduce la probabilità di errori grazie a un maggiore uso di processi automatizzati. Oltre a questi argomenti agili ortodossi, c'è un ultimo punto più filosofico da considerare.
4. La metodologia Agile è soprattutto un approccio flessibile che si adatta rapidamente. I team agili sono pragmatici nel risolvere i problemi degli utenti.

Abbiamo già parlato della prima risposta in altri post (si vedano i post nei blog Imparare dalle persone che vogliono usare il nostro servizio di reporting e Test di convalida: un modo per mettere in discussione le vostre ipotesi), quindi diamo un'occhiata agli altri.

La metodologia agile riduce il costo degli errori

Cercare di prevenire i problemi aggiungendo comitati può creare un circolo vizioso. Tutti questi livelli di governance sono stati creati per evitare errori costosi, ma gli errori sono spesso onerosi a causa di una governance eccessiva.

Al contrario, lo sviluppo agile dei prodotti riduce il costo degli errori. I team che effettuano lanci quotidiani possono correggere i bug nel giro di poche ore, mentre nei team più tradizionali si possono avere "finestre di lancio" di 3-12 mesi.

La metodologia Agile riduce la probabilità di errori

La tradizionale governance a cascata si affida all'uomo per verificare i prodotti prima del loro lancio.

Ciò è costoso da gestire e difficile da scalare 1. Per muoversi al doppio della velocità, è necessario assumere il doppio del personale. Al contrario, lo sviluppo agile del software cerca di sostituire questo collo di bottiglia con test automatizzati che un computer può eseguire, di solito, in pochi secondi. È molto comune che la documentazione sulla sicurezza non sia aggiornata - una volta scritta, descrive come funzionava il sistema - mentre i test automatizzati (creati attraverso l'auditing guidato dall'uomo) eliminano la necessità di documentazione e sono aggiornati per definizione.

Agile significa flessibile

Il secondo principio del Manifesto per lo sviluppo agile del software è "un software funzionante piuttosto che una documentazione esaustiva", e questo sembra un approccio piuttosto valido: concentriamoci sulla costruzione del prodotto piuttosto che sulla stesura di lunghi documenti Word o presentazioni PowerPoint. Tuttavia, il primo principio è "individui e interazioni più che processi e strumenti", e purtroppo la governance attuale prevede che questi team richiedano una documentazione completa. I team di supervisione tradizionali chiedono ai team di prodotto un'ampia documentazione scritta sul funzionamento e la gestione del sistema. Se non la fornite, ci sono poche possibilità che il vostro progetto venga approvato. Come team agile del governo, il vostro principio è "software funzionante" e "documentazione completa".

Muoversi più velocemente o essere più sicuri?

Riassumendo, le due considerazioni importanti per i team agili nelle grandi organizzazioni sono:

1. Fornire valore rapidamente, il che significa portare rapidamente qualcosa nelle mani degli utenti, senza spendere anni nella pianificazione.
2. Gestire il rischio (percepito), il che significa difendersi dagli errori e compilare i documenti.

I team che si muovono rapidamente ottimizzano la velocità. I team che sono sicuri si concedono del tempo, concentrandosi sulle pipeline di test e talvolta scrivendo ingente documentazione.

Questi due punti sembrano essere in tensione l’uno con l'altro. Se volete la massima velocità, non scrivete test. Scrivete solo il codice, speditelo e testatelo in produzione facendo trovare i bug agli utenti reali. D'altra parte, se volete la massima sicurezza, non lanciate mai nulla. Un software che non viene mai lanciato non verrà mai violato.

Quindi, dove bisogna posizionarsi nel continuum "veloce" vs. "sicuro"? Per rispondere a questa domanda, è necessario capire con cosa si ha a che fare. Se le tempistiche tipiche di sviluppo di un prodotto prevedono 2-3 anni per il lancio, cercate di ottenere un servizio alfa in 6-9 mesi.

Conclusione

In qualità di professionisti agili, l'opportunità che esiste nella pubblica amministrazione è chiara: i progetti di IT tradizionali della pubblica amministrazione spesso non riescono a fornire prodotti che mettano gli utenti al primo posto o che soddisfino le loro aspettative.

Alla luce di questi problemi sistemici, sembra un gioco da ragazzi passare a un modello di realizzazione di progetti di grande successo che dia priorità a un feedback rapido e a un ritorno anticipato sull'investimento. I team agili riescono a fare di più con meno spese e, facendo test con gli utenti, sono più sicuri di ciò che stanno creando.

Tuttavia, i team agili del governo canadese operano in condizioni piuttosto difficili, dovendo in genere cercare di adattarsi a una cultura esistente caratterizzata da un'estrema avversione al rischio. Il punto di forza dei team agili è l'attenzione alla produzione rapida e al miglioramento incrementale, ma è necessario mettere qualcosa nelle mani degli utenti. Per questo motivo, è estremamente importante bilanciare l'impegno per la sicurezza con il desiderio di arrivare rapidamente a un lancio.

La fusione di due approcci opposti presenterà sempre delle difficoltà, ma è importante restare concentrati sulla realizzazione di un valore reale per i cittadini. Alla fine della giornata, dovrete dimostrare che il vostro approccio è efficace facendolo funzionale. Scegliete un prodotto, tenete sotto controllo la finalità, mettetelo nelle mani degli utenti e raccontate la vostra esperienza. La velocità mostra le potenzialità, mentre la sicurezza garantisce la fattibilità, che è la chiave per l’apprendimento e l’innovazione.

👋 Puoi scrivere un articolo come questo! Condividi i tuoi pensieri con una comunità di dipendenti pubblici. Saperne di più

(Image Credit: Unsplash)