📚 Introduzione
A quasi 4 anni dalla certificazione come Scrum Master e consigliato da un collega che ricopre questo ruolo da diversi anni ho deciso di leggere questo libro scritto a quattro mani da uno dei creatori del metodo Scrum e promotore del manifesto Agile.
Il libro racconta di come l’autore in seguito ad alcuni vissuti ha costruito il framework Agile. Framework che ormai ha 30 anni ma che in Italia non è ancora così diffuso come ci si possa aspettare nell’industry dello sviluppo software.
Nel mio percorso lavorativo ho vissuto la maggior parte dei miei progetti con metodologia waterfall, vivendo sulla mia pella tutti i difetti di questo metodo che si applica bene per i progetti complicati ma con poca incertezza, a differenza dello sviluppo software per progetti custom che spesso sono molto incerti. Henry Gantt nel 1910 ha sviluppato il diagramma omonimo che è diventato lo strumento principe della metodologia waterfall non sapendo quanti project manager e PMO avrebbero pianto su quei fogli sviluppando software…
🚀 Cosa mi porto a casa da questa lettura
Per un dettaglio del framework Scrum penso che sia più che esaustivo quanto scritto in PSM-I Certificazione Scrum Master livello 1. Qua voglio appuntarmi alcuni spunti.
-
Quando si deve gestire molta incertezza è meglio non pianificare tutto al dettaglio ma affrontare prima le cose che portano più valore al cliente seguendo il principio di Pareto 80/20, 80% del valore si consegna con il 20% delle funzionalità richieste.
-
Il team nel suo complesso è il vero motore dello sviluppo. Solo in team si può costruire l’ambiente per il miglioramento continuo di ogni individuo. Il team deve essere cross funzionale e accrescere le proprie compentenze se necessario. Le caratteristiche sono:
- Transcendent
- Autonomous
- Cross-Functional
-
Non indovinare cosa fare ma applica alla base il ciclo di Deming PCDA:
- Plan
- Do
- Check
- Act
-
Il lavoro dovrebbe piacere e dovrebbe essere espressione di un obiettivo più grande. La felicità nel lavoro rende le scelte più facili e le soluzioni dove necessario più creative.
-
Ispeziona il lavoro, rendilo trasparente, adattalo al cambiamento se è il valore che guida.
-
Fallisci velocemente così puoi recuperare in tempo. Il tempo è una risorsa finita e non va sprecato. Procedi per sprint time boxed e fa una cosa alla volta e falla subito giusta.
-
Pianifica cose realizzabili e raggiungibili. Pianifica solo quello che serve. Non pianificare anni avvenire, concentrati sul breve periodo e alimenta il backlog.
-
Lo spreco è un crimine:
- Muri – waste through unreasonableness
- Mura – waste through inconsistency
- Muda – waste through outcomes
-
Completare un task a metà e non averlo completato affatto.
-
Scrivi le user stories. Le narrazioni raccontano meglio le funzionalità: As an X, I want Y, so that Z.
Come partire da zero 101
Questo il processo base per partire in azienda con il framework:
- Identificare un Product Owner.
- Prendere un team.
- Identificare uno Scrum Master.
- Costruire e prioritizzare un Product Backlog.
- Rifinire e stimare a taglie il Product Backlog.
- Sprint Planning.
- Daily Stand-up or Daily Scrum.
- Sprint Review or Sprint Demo.
- Sprint Retrospective.
🍷 Conclusione
Il libro mi è piaciuto nel suo complesso e potrei consigliare di leggerlo prima di prepararsi alla certificazione o al mero studio del framework perchè permette di capire e sentire l’entusiasmo e lo spirito con cui stato disegnato. Gli aneddoti sono molto interessanti e di sicuro immagino che nel 1995 questo modo di lavorare sia stato visto come dirrompente e assolutamente disruptive. Dalla lettura mi porto a casa alcuni spunti che applicherò a lavoro e di sicuro lo spirito di fondo del framework.
🤓 Riferimento
Jeff Sutherland, Jeffrey Victor Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time, Currency, 2014. Amazon.
“Working Too Hard Only Makes More Work.” (Jeff Sutherland)