Gestire gli Anti-Pattern Comuni

"Facciamo Scrum, ma..." di solito significa non fare davvero Scrum.

Varianti comuni:

• "Ma non abbiamo un vero Product Owner" (nessuna autorità, più persone)
• "Ma non possiamo fare Sprint di 2 settimane" ('Sprint' di 3 mesi)
• "Ma saltiamo le retro quando siamo occupati"
• "Ma la leadership stabilisce lo scope dello Sprint"

Approccio:

1. Capire perché si stanno discostando
2. Spiegare cosa stanno perdendo
3. Affrontare le cause radice (spesso organizzative)
4. Sperimentare facendolo "secondo le regole"

Seguire i movimenti senza lo spirito. Tutti gli eventi avvengono, ma nulla migliora.

Sintomi:

• Gli standup sono report di stato
• Le retro non portano a cambiamenti
• Gli Sprint Goal vengono ignorati
• Nessuno parla con gli stakeholder
• Il team non si preoccupa dei risultati

Trattamento:

• Riconnettersi allo scopo: Perché stiamo costruendo questo?
• Coinvolgere utenti/stakeholder reali
• Rendere le metriche visibili e significative
• Sperimentare con i formati per rivitalizzare

Scrum solo di nome, inserito tra fasi tradizionali.

Pattern:

• Fase dei requisiti (mesi) → Sprint "Scrum" → Fase di QA (mesi)

Perché fallisce:

• Nessun feedback fino alla fine
• L'output dello Sprint non è veramente "fatto"
• I team non possiedono il lavoro end-to-end

Approccio:

• Spingere per team cross-funzionali
• Espandere la Definition of Done per includere i test
• Ottenere il coinvolgimento degli stakeholder durante tutto il processo
• Iniziare in piccolo—una fetta veramente end-to-end

Usare la velocity per misurare la produttività o le performance degli sviluppatori.

Perché è dannoso:

• Incentiva a gonfiare le stime
• Scoraggia l'aiuto ai compagni di team
• Ignora il valore consegnato
• Crea paura e nascondimento

Approcci migliori:

• Usare la velocity solo per le previsioni
• Misurare i risultati, non l'output
• Monitorare il valore consegnato agli utenti
• Concentrarsi sulla salute del team, non sulle metriche individuali