Case study
Sei mesi tra approvazioni e cicli waterfall. Il cittadino aspetta, la PA continua il suo processo.
Un'agenzia pubblica aveva uno storico di cicli di sviluppo di sei mesi. Ogni rilascio doveva passare per cinque livelli di approvazione. Il cittadino che doveva ottenere un servizio online vedeva feature richieste un anno prima che diventassero disponibili. Il team interno non sapeva se quello che stava costruendo avrebbe mai incontrato un vero bisogno, perché il feedback arrivava solo a fine ciclo. Una trasformazione Agile era stata proposta, poi abbandonata per "non compatibile con i processi della PA".
Agenzia della Pubblica Amministrazione, team di 18 sviluppatori e analisti, incarico di gestire sei servizi digitali per cittadini. Cicli di sviluppo di sei mesi basati su waterfall, approvazioni disaccoppiate dal ciclo di sviluppo, feedback da cittadini solo a fine ciclo. Il progetto di trasformazione Agile ha durato cinque mesi: non era il metodo a cambiare, era il rapporto tra processi di approvazione e cicli di sviluppo.
Il ciclo di sviluppo durava sei mesi. Le approvazioni (direttore, responsabile servizio, compliance) avevano tempistiche proprie, disaccoppiate da quello che il team stava costruendo. Un rilascio poteva essere pronto ma attendere tre mesi di approvazione.
Se un requisito era stato male interpretato, lo scoprivi a fine ciclo. Ricominciare significava rifare sei mesi di lavoro. Nessuno osava cambiare idea a metà ciclo perché il costo era troppo alto.
La PA ha regole. Agile suona come "no regole". Il management vedeva Agile come improvvisazione, non come un modo di gestire il rischio. La consultazione era su tecniche Scrum, non su come la PA poteva mantenere controllo in cicli più brevi.
Le approvazioni restavano le stesse, ma il timing cambiava. Anziché approvare tutto a fine ciclo, si approvavano gli incrementi. Un team di approvatori veniva coinvolto a inizio planning e reviewava il lavoro ogni due settimane. Le regole della PA non cambiavano, solo il loro ritmo.
Sprint di due settimane, non di sei mesi. Demone di un feature completo ogni due settimane (anche piccolo). Feedback da cittadini ogni sprint, non solo a fine ciclo. Uno sprint non perfetto è meglio di un ciclo di sei mesi che scoppia a fine.
Un product owner che fosse sia dentro la PA che partner del team tecnico. Non il vecchio "business analyst" che raccoglie requisiti, ma qualcuno che ogni sprint dialoga con cittadini, regulatory, e team, per tenere il backlog sempre allineato ai rischi reali.
La PA ha bisogno di controllo. Agile permette controllo più frequente, non meno. Metriche settimanali: backlog health, sprint velocity, numero di difetti trovati in UAT (cala perché il feedback è più frequente), time-to-market di una feature (cala da sei mesi a tre settimane media).
Non "Agile è libertà", ma "Agile è frequenza di feedback e di controllo". Formazione su Scrum ceremony, ruoli, artefatti, e come ognuno mantiene la rigorosità che la PA richiede.
Time-to-market da sei mesi a tre settimane media. Numero di difetti in produzione calato del 60% perché il feedback era più frequente. Soddisfazione cittadino misurata su sondaggi post-feature: prima era data una volta all'anno, ora è data ogni due settimane e il trend è positivo. Compliance e audit trail non solo mantenuti ma migliorati: il controllo era più frequente, non meno. Il team ha detto che il progetto è più sostenibile: rilasciano più spesso, cambiano meno spesso direzione, hanno feedback su come va davvero.
Agile non è incompatibile con la PA. Quello che non funziona è l'Agile fumoso ("facciamo solo quello che ci piace"). Quello che funziona è l'Agile rigoroso: stesso disciplina della PA, frequenza di feedback più alta. Cambiano i tempi di ciclo, non le regole.
Audit di progetto Segnali precoci di un progetto in difficoltà Servizi
Agile e waterfall non sono opposti? No. Waterfall è ciclo lungo, Agile è ciclo corto. La PA ha bisogno di pianificazione rigida (waterfall) e di feedback frequente (Agile). Non è uno o l'altro, è come combinarli.
Come si mantiene il controllo con Agile? Più controllo, più frequente. Anziché una review a fine ciclo che scoppia, dodici review piccole durante il ciclo. Il rischio non cambia, il timing in cui lo vedi cambia.
Quanto tempo per che una PA si converta a Agile? Non è una conversione totale. È una progressione di cicli: da sei mesi a tre mesi, da tre mesi a sei settimane, da sei settimane a due settimane. Noi abbiamo fatto il passaggio a due settimane in cinque mesi.
Raccontami in breve: quanti cicli di rilascio all'anno, quanti livelli di approvazione, quale è il feedback dal cittadino. La prima conversazione serve a capire se ha senso continuare a parlarne.