In questa miniserie di articoli, ho provato a condividere alcune riflessioni sull’ultima versione della Scrum Guide (pubblicata nel 2020); a distanza di quasi quattro anni, ho voluto condividere le mie osservazioni personali su come aziende e organizzazioni abbiano accolto queste novità (e se di fatto possiamo notare qualche differenza rispetto al passato).
Nella puntata precedente mi sono soffermato sulla filosofia di base relativamente alle modalità di conduzione di alcune riunioni e delle connessioni con le figure di Product Owner e Scrum Master.
In questa puntata vorrei proseguire a parlare di come siano cambiati Product Owner e Scrum Master e delle connessioni con le modalità di ingaggio (contratti) delle persone coinvolte nello sviluppo dei progetti.
Il Product Backlog e Product Goal
Partiamo dal Product Backlog: la guida a tal riguardo ci dice che:
“The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.”
In quelle organizzazioni in cui l’adozione delle metodologie agili è parte di una trasformazione culturale più ampia, il processo descritto in genere viene seguito abbastanza fedelmente. Quando i principi agili sono compresi e valorizzati, il cosiddetto Product Backlog Refinement (PBR) viene svolto in modo collettivo e costante grazie a una costante e stretta collaborazione tra Product Owner e Sviluppatori; il Backlog viene visto prima di tutto come un insieme ordinato e dinamico di elementi corrispondenti ai bisogni degli utenti del prodotto.
Dove è forte la cultura della collaborazione e dell’innovazione il Priduct Backlog diventa quindi il punto centrale di una collaborazione continua e costante basata su confronto e interscambio.
La versione 2020 della guida sposta ulteriormente il focus dal concetto di progetto in favore del prodotto, grazie ad alcuni piccoli ma importanti cambiamenti e innovazioni. Uno di questi è legato all’introduzione ufficiale del concetto di Product Goal che assume il ruolo fondamentale di guida per il lavoro dello Scrum Team nella realizzazione di un prodotto che soddisfi utente finale.
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
Ma non sempre questo accade: in quelle aziende in cui persiste l’abitudine a puntare il focus sul progetto (ovvero sul lavoro da fare) e non sul prodotto (ovvero sul rilascio di un qualcosa di valore che risolva i bisogni dell’utilizzatore finale), il PBR finisce per diventare un momento di ascolto della voce del Product Owner che redige un elenco statico di compiti, una sorta di documento di requisiti da assegnare agli sviluppatori in base alle competenze dei singoli.
La nuova versione della guida non fa altro che evidenziare quanto questo approccio sia distante da un modo di lavorare che possa trarre benefici dai principi dell’agilità alzando il livello di impegno richiesto alle aziende.
Sprint Backlog e Sprint goal
Analogamente anche lo Sprint Backlog non è più solo un elenco di cose da fare, ma:
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
Come in passato lo Sprint Backlog è quindi una serie di user business needs da risolvere e un insieme di dettagli (i task operativi) che descrivono il come questo lavoro viene svolto. Ma a differenza del passato, adesso nel backlog di sprint prende posto anche un goal che ne diventa un elemento fondante:
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
Il goal guida il lavoro del team per svolgere un lavoro che sia coerente con il resto del prodotto che si sta sviluppando:
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
Il Product Owner non è quindi più il solo responsabile della creazione di questo incremento di valore, ma lo sono tutti i membri del team. Il lavoro viene quindi pianificato tutti insieme e tutti insieme si lavora per capire come il lavoro nello sprint possa contribuire a definire questo valore.
Si noti questo passaggio:
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind.
Quindi vuol dire che il Product Owner arriva con una bozza o un’idea di massima dello sprint Goal, ma poi tutto il team lavora per completare quello che che servirà da obiettivo per il lavoro durante lo sprint. Inoltre:
If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
Tutti questi passaggi sono legati fra loro da un aspetto comune, quello del lavoro collaborativo di gruppo, aspetto che può essere ostacolato se non si comprende il senso profondo della filosofia alla base di Scrum. Nella puntata precedente abbiamo visto per esempio come una “concezione a tempo” o per “obiettivi” (esempio limitatamente al progetto da realizzare) possa essere un reale impedimento per favorire tale comprensione.
Un altro fattore che influenza la collaborazione è collegato alle regole di ingaggio delle persone coinvolte nel progetto di sviluppo del prodotto.
E’ uso comune, specie nelle aziende di medie e grandi dimensioni, “affittare” persone per la formazione di team ibridi in cui parte del personale è fornito dal cliente (tipicamente il Product Owner) e parte dal fornitore che offre i Developers. Lo Scrum Master è tipicamente messo a disposizione dal fornitore ma a volte anche dal cliente stesso.
Questi schemi contrattuali rendono difficile la creazione di una collaborazione in linea con lo spirito agile, dove prima di tutto il lavoro orientato alla generazione di valore.
I contratti più comuni si basano su accordi a corpo o time&material: nel primo caso il fornitore viene pagato se produce un tot di funzionalità entro una certa data (e spesso deve pagare in caso di ritardi); nel secondo ogni giornata viene contabilizzata e retribuita in base agli accordi.
Quasi mai, in nessuno dei due casi, c’è spazio per discutere su quale sia il modo migliore per produrre il maggior valore possibile.
Si pensi infine a questo passaggio preso dalla guida in cui si parla del ruolo del Product Owner:
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, which includes:
-
- Developing and explicitly communicating the Product Goal;
- Creating and clearly communicating Product Backlog items;
- Ordering Product Backlog items;
- Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
Quando ci sono i contratti e gli accordi di cui sopra che si mettono nel mezzo fra cliente e fornitore, questo mix di delega e responsabilità diventa difficilissimo.
Lo Scrum Master appaltato
L’approccio ibrido complica non poco il lavoro dello Scrum Master, specialmente se lo si guarda con l’occhio delle nuove indicazioni della guida 2020:
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
Scrum Masters are true leaders who serve the Scrum Team and the larger organization.
[…]
The Scrum Master serves the organization in several ways, including:
Leading, training, and coaching the organization in its Scrum adoption;
Planning and advising Scrum implementations within the organization;
Helping employees and stakeholders understand and enact an empirical approach for complex work […]
Lo Scrum Master è quindi un “vero leader” che si muove in tutti i livelli e reparti dell’organizzazione.
Cosa diciamo adesso a tutte quelle aziende che “affittano” gli Scrum Master come parti integranti di un team che deve realizzare prodotti?
Giovanni Puliti ha lavorato per oltre 20 anni come consulente nel settore dell’IT e attualmente svolge la professione di Agile Coach. Nel 1996, insieme ad altri collaboratori, crea MokaByte, la prima rivista italiana web dedicata a Java. Autore di numerosi articoli pubblicate sia su MokaByte.it che su riviste del settore, ha partecipato a diversi progetti editoriali e prende parte regolarmente a conference in qualità di speaker. Dopo aver a lungo lavorato all’interno di progetti di web enterprise, come esperto di tecnologie e architetture, è passato a erogare consulenze in ambito di project management. Da diversi anni ha abbracciato le metodologie agili offrendo ad aziende e organizzazioni il suo supporto sia come coach agile che come business coach. È cofondatore di AgileReloaded, l’azienda italiana per il coaching agile.