Da Self-Organizing a Self-Managing: l'evoluzione della responsabilità in Scrum 2020
Scopri la differenza fondamentale tra team auto-organizzati e team auto-gestiti nella Scrum Guide 2020 e come questo cambio di paradigma aumenta l'autonomia.
Un cambio di vocabolario che cambia tutto
Nella versione 2017 della Scrum Guide, lo Scrum Team e i Developers venivano definiti come Self-Organizing (auto-organizzati). Con la revisione della Scrum Guide 2020, questa definizione è stata sostituita da Self-Managing (auto-gestiti).
A prima vista potrebbe sembrare una semplice sfumatura linguistica, ma rappresenta in realtà una delle evoluzioni concettuali più significative dell'intero framework.
Il passaggio all'auto-gestione non è un vezzo terminologico: ridefinisce i confini dell'autonomia e della responsabilità di tutto il team.
La differenza concettuale: Chi, Come e COSA
Per comprendere appieno la differenza, occorre osservare quali decisioni vengono delegate allo Scrum Team.
- Self-Organizing (Vecchio modello): Il team decide chi fa il lavoro e come svolgerlo, ma il cosa fare viene spesso calato dall'alto o gestito in modo isolato dal Product Owner o dal management.
- Self-Managing (Modello Scrum 2020): Lo Scrum Team decide in totale autonomia chi fa il lavoro, come svolgerlo e partecipa attivamente a definire cosa fare.
L'auto-gestione non significa fare ognuno quello che si vuole, ma avere la piena responsabilità di gestire il proprio lavoro all'interno dei confini tracciati dal Product Goal e dallo Sprint Goal.
Chi decide cosa? Il confronto
| Dimensione | Team Self-Organizing (2017) | Team Self-Managing (2020) |
|---|---|---|
| Chi fa il lavoro? | Deciso internamente dal team | Deciso internamente dal team |
| Come svolgere il lavoro? | Deciso dai Developers | Deciso dai Developers |
| Cosa sviluppare? | Stabilito dal PO / Management | Co-definito dallo Scrum Team |
| Focus principale | Esecuzione tecnica | Consegna di valore di business |
Come si traduce concretamente nell'operatività quotidiana?
Passare a un approccio Self-Managing ha impatti diretti sulla dinamica di lavoro dello Scrum Team:
1. Coinvolgimento attivo nello Sprint Planning
I Developers non sono più meri "esecutori" di una lista di task preparata dal Product Owner. Nello Sprint Planning, i Developers collaborano alla selezione degli elementi del Product Backlog e alla definizione del Perché questo Sprint è di valore (lo Sprint Goal).
2. Eliminazione della micro-gestione
Nessun manager o figura esterna assegna i task ai singoli membri del team. È lo Scrum Team a gestire internamente la propria capacità e l'avanzamento verso lo Sprint Goal.
3. Più responsabilità sulla qualità e sui tempi
Maggiore autonomia comporta una responsabilità diretta (accountability). Se il team ha il potere di decidere come e cosa fare entro i confini dello Sprint Goal, diventa anche il diretto responsabile del rispetto della Definition of Done.
Il ruolo del Product Owner e dello Scrum Master nel Self-Management
L'auto-gestione non riduce l'importanza del Product Owner o dello Scrum Master, ma la valorizza:
- Product Owner: Mantiene la responsabilità di prioritisare il Product Backlog e definire il Product Goal, ma si affida alla competenza del team per capire cosa è realizzabile.
- Scrum Master: Agisce come un vero leader (True Leader), creando l'ambiente organizzativo affinché lo Scrum Team possa esercitare la propria auto-gestione senza interferenze esterne.
Conclusione
La transizione verso team Self-Managing responsabilizza gli sviluppatori, trasformandoli da semplici esecutori di codice a veri e propri partner di prodotto. Comprendere questa differenza è fondamentale per chiunque voglia applicare Scrum nella sua versione moderna e orientata al valore.