14. _A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.
_
15. The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren’t resources and managers aren’t bosses.
Scrum è composto da tre elementi:
-
Artifacts
-
Accountabilities
-
Events
Events/Eventi e Artifacts/Manufatti sono quelli che, a causa della loro relativa tangibilità, si prendono la maggior parte dell’attenzione e delle critiche: per questo motivo si tende anche perdere molto tempo ed energie sulla meccanica di Scrum, a scapito di una scarsa attenzione nei confronti delle persone coinvolte.
Per accountabilities, invece, si intendono delle responsabilità delle persone. Come non manco mai di fare notare, è accountabilities, e non roles e non _job title_s.
Ogni tanto stupisco con una affermazione forte: è un errore, una sorta di peccato originale, che Product Owner e Scrum Master siano diventati ruoli formali in azienda e quindi oggetto di annunci di lavoro – Generare nuovi ruoli non è mai stato un obiettivo di Scrum.
Giova ricordare che inizialmente Scrum non prevedeva l’esistenza di un Product Owner, e che molte degli elementi e dei principi di Scrum sono stati presi evidentemente a prestito da Extreme Programming — un approccio che non prevede ruoli specifici al di fuori di quelli dei membri del team di sviluppo.
Ci sono almeno due affermazioni nella definizione delle responsabilità del o della Product Owner che fanno riflettere, la prima è:
How this [maximizing the value of the product resulting from the work of the Scrum Team] is done may vary widely across organizations, Scrum Teams, and individuals.
La seconda affermazione, in coda all’elenco delle quattro responsabilità del o della Product Owner:
The Product Owner may do the above work or may delegate the responsibility to others.
Non so voi, ma io leggo tra queste righe una sorta di lavarsi le mani riguardo al voler chiarire ruolo e rilevanza del o della Product Owner: se davvero è un ruolo così cruciale, perché sbolognarlo dicendo che come il ruolo viene interpretato “dipende” oppure che queste responsabilità possono essere delegate ad altri?
Quando parlo del ruolo del Product Owner mi piace sempre condividere questa tabella, che ho adattato dal libro “The Professional Product Owner”.
Questo fa parte di quella che chiamerei letteratura integrativa riguardo questo ruolo, per dare una forma al pensiero “non tutti e tutte le Product Owner sono uguali” e sfatare il mito della presunta onniscienza e onnipresenza del Product Owner.
Quella che viene percepita come una distinzione di ruoli in Scrum, non è una distinzione di ruoli: quelle di Scrum Master e Product Owner sono una serie di responsabilità che vanno ad integrarsi alle responsabilità esistenti del ruolo specifico che Scrum Master e Product Owner ricoprono all’interno della loro organizzazione.
È richiesto un cambiamento che può essere più o meno radicale a seconda del punto di partenza dell’organizzazione che adotta Scrum: come sottolinea il punto 15 di “Scrum is Hard and Disruptive”, chi ricopre posizioni di management dovrebbe infatti cambiare il proprio approccio, dal dire alla persone cosa fare, all’aiutare chiunque a fare del proprio meglio per raggiungere degli obiettivi e dei risultati.
Questa è una versione di leadership che per tanto tempo è stata chiamata servant leadership: se devo essere sincero ho notato che questo termine è stato utilizzato sempre meno negli ultimi anni.
Non credo sia un problema: da un lato parlare di leadership si riduce spesso, per citare Frank Zappa, a ballare di architettura, un modo come un altro per mantenere astratto e intangibile quello che dovrebbe essere concreto e applicabile.
Dall’altro lato è riduttivo e inadeguato pensare che uno specifico tipo di leadership sia efficace in ogni occasione.
Data la complessità delle organizzazioni e degli scenari in cui operano, anziché predicare una superiorità della servant leadership, è forse meglio esplorare le opportunità di una leadership adattiva e situazionale, in cui molteplici modelli e approcci sono conosciuti e impiegati.
Sì, sto dicendo chiaramente che ogni tanto alle persone va anche detto cosa devono fare: il rischio di non decidere e non essere espliciti in nome della fantomatica servant leadership può costare parecchio in termini di risultati non raggiunti.
Un ultimo, breve commento vorrei farlo sul ruolo delle persone a cui viene appioppato il titolo di stakeholder: questo ruolo non solo non viene particolarmente definito all’interno della Scrum Guide, ma si presuppone che quel cambiamento di cui sopra sia già avvenuto tra queste persone, spesso molto importanti nella loro influenza sul team Scrum.
Si dà quindi per scontato che tutti i nostri e nostre stakeholder siano perfettamente informati, competenti, pronti a contribuire costruttivamente al nostro Scrum.
Ma è davvero così? Quante volte mi sono trovato a fare corsi di formazione e coaching a Product Owner, Scrum Master e membri di team di sviluppo, solo per scoprire che il management si guardava bene dall’essere coinvolto? Tante volte.
Uno degli aspetti che più mi è piaciuto di questa lettura di “Scrum is Hard and Discruptive” è la natura estremamente pragmatica dei commenti: erano validi nel 2006, sono ancora validi nel 2024.
Su tutto, emerge un tema comune: l’adozione di Scrum deve essere uno sforzo collettivo, dell’intera organizzazione, management incluso. Non è uno strumento per aumentare l’efficienza di un singolo team o un gruppo di team.
People aren’t resources and managers aren’t bosses.
La mia rilettura di “Scrum is Hard and Disruptive” è finita, per il momento: ti invito a leggere e commentare a tua volta la lista completa di questi 15 punti perché credo nell’importanza del re-imparare, partendo dai cosiddetti first principles, mantenendo un pensiero critico.
Nel 2006 Ken Schwaber, co-creatore di Scrum, assieme a Jeff Sutherland, scrisse un elenco di affermazioni riguardo Scrum stesso: benché il framework fosse ancora “fresco”, questo elenco di affermazioni suonano come una sorta di avvertimento.
Negli anni a seguire l’utilizzo di Scrum si sarebbe diffuso a macchia d’olio, con una popolarità travolgente che probabilmente ha sorpreso a più riprese gli stessi creatori, come dimostrano anche gli aggiornamenti della Scrum Guide che si sono susseguiti negli anni.
“Scrum is hard and disruptive” è un elenco in quindici punti che, se già erano rilevanti per richiamare l’attenzione su potenziali abusi del framework già nel lontanissimo 2006, non possono che essere attuali ancora oggi.
Questa è la serie completa degli articoli che ho scritto: