Agile working meets AI: Why traditional methods fail in automation

Perché Scrum e Kanban falliscono nei progetti AI

Scrum è stato creato per lo sviluppo software.

L’AI segue logiche completamente diverse.

Ignorarlo è l’errore più comune che vedo nei miei clienti.

Il problema degli sprint: L’AI non si sviluppa in modo lineare

Uno sprint dura 2 settimane.

Un modello di machine learning può aver bisogno di 3 settimane solo per produrre i primi risultati utilizzabili.

Cosa fai nella settimana 1 e 2? Presenti stiamo ancora addestrando come risultato dello sprint?

L’ho visto succedere.

Un team di sviluppo non è riuscito a mostrare nulla di concreto per 6 sprint nonostante il grande lavoro svolto.

Il problema: lo sviluppo AI segue cicli temporali diversi.

A volte la preparazione dei dati richiede 4 settimane, poi il primo modello funziona subito al primo tentativo.

Altre volte si testano 50 approcci prima che uno funzioni.

Non si adatta ai ritmi da 2 settimane.

Backlog in tilt: quando sono gli algoritmi a cambiare le priorità

Il backlog prodotto funziona bene per le feature.

Nell’AI le priorità cambiano con le nuove scoperte fatte sugli algoritmi e sui dati.

Esempio reale del mio lavoro:

Volevamo creare uno strumento di sentiment analysis sui feedback dei clienti.

Erano previsti 5 feature:

1. Classificazione positiva/negativa
2. Riconoscimento delle emozioni
3. Estrazione dei temi
4. Analisi dei trend
5. Dashboard

Dopo la prima esplorazione dei dati abbiamo scoperto che il 60% dei dati era inutilizzabile.

Improvvisamente la pulizia dei dati è diventata la priorità numero uno.

Ma non era da nessuna parte nel backlog.

Nei progetti AI molto spesso sono i dati a determinare i prossimi passi – non il Product Owner.

Daily Standup che diventano Weekly (e va bene così)

Cosa hai fatto ieri?

Ho ottimizzato gli iperparametri.

Cosa farai oggi?

Sto ottimizzando gli iperparametri.

Ci sono dei blocchi?

Il training durerà ancora 12 ore.

Ecco come appaiono i daily standup nei team AI.

Inutili.

Lo sviluppo AI ha cicli di feedback molto più lunghi.

Addestrare un modello può richiedere diversi giorni.

Analizzare un A/B test richiede una significatività statistica – spesso si parla di settimane.

Sincornizzarsi ogni giorno non ha senso se nulla cambia sostanzialmente di giorno in giorno.

Le tre differenze fondamentali tra sviluppo software e AI

Sviluppo software: sai cosa stai costruendo.

Sviluppo AI: sai cosa stai sperimentando.

Questa è la differenza cruciale.

Imprevedibilità invece che pianificazione

Nel software scrivi codice: funziona (oppure no).

Con l’AI addestri un modello, funziona al 73% – ma non sai perché.

Non per colpa del codice.

Ma per problemi inattesi nei dati o nelle performance del modello.

Non puoi pianificare quando il modello raggiungerà la accuracy richiesta.

Puoi solo sperimentare e iterare.

Questo rende impossibile una pianificazione classica del progetto.

Processo sperimentale vs. lineare

Lo sviluppo software segue un processo lineare:

Requirement → Design → Implementazione → Test → Deploy

Lo sviluppo AI è un ciclo di sperimentazione:

Ipotesi → Esperimento → Valutazione → Apprendimento → nuova ipotesi

L’80% del tempo su un progetto AI lo passo su esperimenti che non funzionano.

È normale.

Anzi, è un bene.

Ogni esperimento fallito ti avvicina alla soluzione.

Nello sviluppo software avere l’80% di codice non funzionante sarebbe inaccettabile.

In AI è la strada per arrivare al successo.

La qualità dei dati come fattore critico di successo

Il software gira anche con dati di test sintetici.

L’AI si regge – o crolla – sulla qualità (e quantità) di dati reali di valore.

Mi è capitato di vedere team che hanno scritto codice perfetto per 6 mesi.

Ma il modello risultava inutile.

Perché i dati non erano buoni.

In un progetto AI passi il 60-80% del tempo a lavorare sui dati:

• Raccolta dati
• Pulizia dati
• Labeling dei dati
• Validazione dei dati
• Creazione delle data pipeline

Questo non trova spazio in nessun piano sprint di sviluppo software.

Ma senza questi passi, l’AI non funziona.

AI-first: Le nuove modalità di lavoro dopo Scrum

Lavoro da 3 anni con diversi approcci per team AI.

Quello che segue funziona davvero.

Hypothesis-driven Development invece di User Story

Dimentica le User Story.

Come utente voglio… non funziona per l’AI.

Al loro posto: Hypothesis-driven Development.

Ogni fase di sviluppo parte da un’ipotesi misurabile:

Se integriamo la feature X, la accuracy del modello aumenta almeno del 5%.

Oppure:

Se usiamo l’algoritmo Y, riduciamo il tempo di training del 50%.

Ogni ipotesi deve avere:

• Una metrica misurabile
• Un valore-obiettivo
• Una stima temporale per l’esperimento
• Criteri chiari di successo/fallimento

Così ottimizziamo il modello diventa un esperimento concreto con un risultato chiaro.

Continuous Experimentation come processo chiave

Nel software sviluppi feature.

Con l’AI conduci esperimenti.

Il processo cruciale non è lo Sprint Planning, bensì il Design degli esperimenti.

Il nostro workflow standard di esperimento:

1. Definizione dell’ipotesi (1 giorno)
2. Setup dell’esperimento (2-3 giorni)
3. Esecuzione (variabile: da 1 giorno a 2 settimane)
4. Valutazione (1-2 giorni)
5. Decisione (proseguire/scartare/pivot)

Importante: ogni esperimento viene documentato.

Anche (soprattutto) quelli falliti.

Abbiamo un Esperiment Log con:

• Ipotesi
• Approccio
• Risultato
• Learnings
• Next Steps

Diventa la risorsa più preziosa del team.

Workflow data-centric per team AI

I team software si organizzano intorno alle feature.

I team AI devono organizzarsi intorno ai dati.

Il nostro workflow non parte da una kanban board, bensì da una Data Pipeline:

Ogni fase ha criteri di passaggio ben definiti.

Niente è finito senza qualità misurabile.

Best practice operative per i team AI nella pratica

Basta teoria.

Ecco le soluzioni che uso ogni giorno sul campo.

Il metodo delle 3 fasi per i progetti AI

Ogni progetto AI lo divido in 3 fasi:

Fase 1: Discovery (25% del tempo)

Obiettivo: capire cosa è davvero possibile.

Attività:

• Data exploration
• Proof of Concept
• Analisi di fattibilità
• Primi modelli baseline

Metrica chiave: il problema è realmente risolvibile con l’AI?

Fase 2: Development (60% del tempo)

Obiettivo: costruire il miglior modello possibile.

Attività:

• Miglioramento iterativo dei modelli
• Feature engineering
• Ottimizzazione iperparametri
• Cross-validation

Metrica di successo: accuracy obiettivo raggiunta.

Fase 3: Deployment (15% del tempo)

Obiettivo: mettere il modello in produzione.

Attività:

• Model packaging
• Sviluppo API
• Impostazione del monitoraggio
• A/B testing

Metrica di successo: modello stabile in produzione.

Nota bene: le fasi non sono lineari.

Si passa avanti e indietro tra Discovery e Development.

È assolutamente normale.

Agile Data Science: sprints ripensati

Usiamo comunque gli sprint – ma in modo diverso.

I nostri sprint AI durano 3-4 settimane (non 2).

Ogni sprint ha un obiettivo di esperimento, non di feature.

La pianificazione di sprint segue questo flusso:

1. Experiment Review: cosa abbiamo imparato negli ultimi sprint?
2. Prioritizzazione delle ipotesi: quali esperimenti sono più promettenti?
3. Allocation delle risorse: chi lavora su cosa?
4. Criteri di successo: come misuriamo il risultato?

Il nostro Sprint Review mostra risultati, non feature:

• Quali ipotesi sono state confermate o smentite?
• Quali nuovi insight abbiamo ricavato?
• Come si è evoluta la performance del modello?
• Quali sono i prossimi esperimenti logici?

Organizzare team AI cross-funzionali nel modo giusto

Un team AI ha ruoli molto diversi rispetto a un team solo software.

Il nostro setup standard per un progetto AI:

Importante: il Product Manager NON è lo Scrum Master.

Definisce gli obiettivi di business, non gli obiettivi degli sprint.

La priorità degli esperimenti viene decisa insieme da tutto il team.

Tool-stack e processi: cosa funziona davvero

Gli strumenti dei team AI sono diversi da quelli del software tradizionale.

Ecco la nostra stack collaudata.

Tool di project management per team AI

Jira va bene per il software.

Per l’AI usiamo una combinazione di strumenti:

Experiment Tracking: MLflow

• Tutti gli esperimenti vengono loggati in automatico
• Parametri, metriche e artifact in un’unica vista
• Confronto tra diverse versioni di modello

Task Management: Notion

• Backlog delle ipotesi
• Documentazione degli esperimenti
• Team learnings
• Dashboard qualità dati

Communication: Slack + report dati giornalieri

• Report automatici sulle performance dei modelli
• Alerts per issues sui dati
• Channel dedicato a ogni esperimento attivo

Lo strumento più importante però resta un Experiment Log condiviso.

Documentiamo OGNI esperimento – anche quelli falliti.

Versionamento di modelli e dati

Per il codice usi Git.

Ma e per modelli e dati?

Ecco la nostra strategia:

Data Versioning: DVC (Data Version Control)

• Ogni dataset ha una versione
• Pipeline dati riproducibili
• Tracciamento automatico della data lineage

Model Versioning: MLflow Model Registry

• Ogni modello viene versionato automaticamente
• Ambienti staging/production
• Rollback immediato in caso di perdita di performance

Code Versioning: Git + pre-commit hooks

• Code quality check automatici
• I metadata degli esperimenti vengono committati automaticamente
• Jupyter Notebook vengono puliti prima di ogni commit

Senza versionamento, lo sviluppo AI non è riproducibile.

E se non è riproducibile, non è nemmeno debugabile.

Testing e deployment in ambienti AI

I test di unità sui componenti AI sono diversi dal software tradizionale.

Non testi solo le funzioni, ma anche la qualità dei dati e la performance dei modelli.

Il nostro framework di test:

Data Quality Test

• Validazione schema (tutte le colonne presenti?)
• Data freshness (i dati sono aggiornati?)
• Test statistici (sono cambiate le distribuzioni?)
• Check di completezza (quanti missing values?)

Model Performance Test

• Test di accuracy minima
• Test di latenza
• Verifica uso memoria
• Test su bias

Integration Test

• Test end-to-end della pipeline
• Test della risposta API
• Test di carico

Il deployment avviene tramite blue-green deployment con rollback automatico.

Se la performance del modello cala di oltre il 5%, si torna subito alla versione precedente.

Errori comuni nel passaggio a modalità di lavoro AI-driven

Questi errori li ho visti quasi con ogni cliente.

Ecco i più frequenti – e come evitarli.

Da Scrum Master ad AI Product Owner (e perché non va bene)

Errore classico:

L’azienda vuole restare agile e trasforma lo Scrum Master in AI Product Owner.

Il problema: lo Scrum Master è esperto di processi, non di data science.

Non può prioritizzare esperimenti senza capire cosa è realizzabile.

Soluzione: l’AI Product Owner deve avere competenze tecniche.

Deve saper valutare:

• Come funziona il machine learning
• Cosa significa data quality
• Quanto dura l’addestramento di un modello
• Quali metriche sono rilevanti

Da noi l’AI Product Owner è sempre un Data Scientist o ML Engineer con competenze business.

Mai solo un project manager.

Perché la Definition of Done classica non funziona

Software: La feature funziona come richiesto = Done.

AI: Il modello raggiunge l’85% di accuracy = Done.

Ma se arriva solo all’84%?

Non è Done?

La Definition of Done classica porta nei progetti AI a loop infiniti di ottimizzazione.

La nostra soluzione: Definition of Done probabilistica.

Al posto di il modello deve raggiungere l’85% di accuracy definiamo:

Il modello raggiunge almeno l’80% di accuracy e supera l’approccio baseline usato finora.

Con un timebox:

Se dopo 4 settimane di ottimizzazioni non c’è un miglioramento significativo, il modello attuale è pronto per la produzione.

Così evitiamo il perfezionismo e favoriamo miglioramenti iterativi anche in produzione.

Change management per team tradizionali

La parte difficile non è la tecnica.

È il change management.

Gli sviluppatori sono abituati a costruire sistemi deterministici.

L’intelligenza artificiale è probabilistica.

Serve un cambio mentale.

Ecco cosa faccio sempre al passaggio:

1. Gestione delle aspettative

• Comunicazione onesta: l’80% degli esperimenti fallisce
• È normale ed è prezioso
• Il successo si misura in modo diverso

2. Pair programming per AI

• I Data Scientist senior lavorano accanto agli sviluppatori
• Trasferimento di conoscenze con code review
• Pianificazione esperimenti fatta insieme

3. Continuous learning

• Sessioni settimanali ML Learning
• Case study di esperimenti riusciti
• Post-mortem degli approcci falliti

Il passaggio richiede 3-6 mesi.

Mettilo in conto.

E celebra i piccoli successi – anche gli esperimenti falliti che portano insight preziosi.

Domande frequenti

Quanto dura il passaggio dalle modalità Scrum a quelle AI-driven?

Dalla mia esperienza, la transizione richiede 3-6 mesi. Il team deve apprendere nuove logiche e consolidare i nuovi processi. Importante cambiare step by step, senza rivoluzionare tutto in una volta.

Scrum e sviluppo AI sono davvero incompatibili?

No, ma Scrum va adattato molto. Sprint più lunghi (3-4 settimane), obiettivi di esperimento invece che di feature, e una pianificazione molto flessibile. L’implementazione pura di Scrum classico non funziona nei progetti AI.

Quali ruoli sono indispensabili in un team AI?

Minimo: Data Scientist, Data Engineer, ML Engineer. Nei team piccoli una persona può coprire più ruoli, ma tutte le aree devono essere coperte. Un Product Manager con competenze AI è fondamentale.

Come si misura il successo di un esperimento AI?

Con metriche predefinite e misurabili come accuracy, precision, recall o KPI di business. Importante: anche un esperimento fallito è di valore se porta insight. Documentiamo tutto in modo sistematico.

Le principali sfide nel passaggio all’AI?

Il change management è più difficile della tecnica. Il team deve imparare a gestire l’incertezza e pensare in termini probabilistici, non deterministici. Servono nuovi strumenti e strategie di versionamento per dati e modelli.

Quali tool sono fondamentali per i team AI?

MLflow per tracciare gli esperimenti, DVC per il versionamento dati, un cloud per la potenza di calcolo e un buon tool di documentazione come Notion. Solo Git non basta – servono tool specifici per Data Science.

Come gestire l’imprevedibilità dei progetti AI?

Con esperimenti a tempo fisso e criteri Go/No-Go chiari. Dai un limite temporale alle ottimizzazioni e definisci soglie minime di performance. Pianifica con margine e comunica sempre chiaramente l’incertezza agli stakeholder.

I tool classici di project management funzionano nei team AI?

Solo in parte. Jira va bene per i task, ma servono tool aggiuntivi per tracciare esperimenti e lineage dei dati. Noi usiamo una combinazione di strumenti specialistici diversi.

Come si organizzano i code review per il machine learning?

I code review AI sono diversi: non valuti solo la qualità del codice, ma anche l’approccio sperimentale, la qualità dati e la validazione dei modelli. Pair programming tra Data Scientist e sviluppatori software aiuta molto il trasferimento di conoscenze.

Cosa succede se un progetto AI fallisce completamente?

Capita nel 15-20% dei casi ed è normale. L’importante è accorgersene per tempo e cambiare strada in fretta. Documenta tutti i learnings: sono utilissimi per i progetti futuri. Un progetto fallito può far risparmiare errori agli altri.