Il Product Owner deve partecipare al Daily Scrum?

I Product Owner dovrebbero partecipare al Daily Scrum? Questa domanda viene posta regolarmente.

Rispondiamo quindi ufficialmente a questa domanda. Cominceremo esaminando la Guida a Scrum, poi andremo in profondità in modo pragmatico attraverso delle esperienze sul campo. Infine, chiuderemo con un'analisi di come la presenza del Product Owner può dirottare il Daily Scrum e come rendere invece la sua presenza un'esperienza che lo arricchisce.

Guida a Scrum: Le regole del gioco

La Guida a Scrum aggiornata al 2020 afferma chiaramente quanto segue: "Il Daily Scrum è un evento di 15 minuti per gli Sviluppatori dello Scrum Team. Per ridurre la complessità, si tiene alla stessa ora e nello stesso posto ogni giorno lavorativo dello Sprint. Se il Product Owner o lo Scrum Master stanno lavorando attivamente sugli elementi dello Sprint Backlog, partecipano come Sviluppatori".

Secondo quanto appena letto, non è che il Product Owner debba o non debba partecipare - è che non ne ha bisogno, a meno che, ovviamente, non stia lavorando sul Product Backlog come Sviluppatore. Quindi, visto che quanto appena letto è così chiaro, perché c'è confusione sulla sua partecipazione?

Se andiamo avanti nella lettura della Guida a Scrum possiamo trovare altre informazioni che porterebbero alla necessità della presenza del Product Owner. Più avanti nella stessa sezione, dice:

"I Daily Scrum migliorano la comunicazione, identificano gli impedimenti, promuovono un rapido processo decisionale, e di conseguenza eliminano la necessità di altre riunioni".

Promuovere un rapido processo decisionale è una ragione essenziale per tenere i Daily Scrum.

Come rivelano i dati dal Chaos Report dello Standish Group, la latenza decisionale (il tempo necessario per prendere una decisione) è un fattore chiave per il successo di un progetto. Visto che queste decisioni implicano il cambiamento delle priorità del Product Backlog o l'interruzione del lavoro priorizzato nello Sprint Backlog, allora l'intervento del Product Owner potrebbe essere richiesto al Daily Scrum.

Ci sono altre parti della Guida a Scrum che forniscono ulteriori chiarimenti. In una parte precedente, spiega:

"Lo Scrum Team è responsabile di tutte le attività relative al prodotto, dalla collaborazione con gli stakeholder, alla verifica, alla manutenzione, al funzionamento, alla sperimentazione, alla ricerca e sviluppo, e qualsiasi altra cosa che potrebbe essere richiesta." e "L'intero Scrum Team è responsabile della creazione di un Incremento utile e di Valore ad ogni Sprint".

Quindi, queste due parti prese insieme potrebbero spiegare razionalmente perché i Product Owner potrebbero voler partecipare al Daily Scrum.

Dopo tutto, se l'intero Scrum Team è responsabile dell'Incremento, e l'intero team è responsabile di tutte le attività relative al prodotto, e visto che il Product Owner è parte dello Scrum Team, allora dovrebbe essere presente al Daily Scrum!

Testimonianze dal campo

Ora mettiamo da parte la Guida a Scrum e la teoria, ed esaminiamo ciò che abbiamo imparato sul campo. Ho intervistato un gruppo di professionisti esperti di Scrum. Ecco cosa hanno detto:

‍

"Il Product Owner partecipa al Daily Scrum. L'assenza di una singola persona ci dice che NON fa parte del team. Il Product Owner non dovrebbero usarlo per chiedere aggiornamenti o dirigere la riunione. Dovrebbe ASCOLTARE ciò che il team ha da dire e OFFRIRE un proprio aggiornamento. Se questo evento è usato per imporre direttamente o indirettamente un senso di importanza o di gerarchia, perde drammaticamente il suo valore". - Toby Johnson, Senior Product Manager

‍

"I ruoli interni di Scrum dovrebbero dissiparsi temporaneamente per sfruttare uno spazio di sicurezza psicologica, poiché il Daily Scrum ci permette di controllare il polso del "Team". Anche se questo non è un evento per soddisfare o fornire un aggiornamento di stato al Product Owner, può comunque partecipare ma come membro del Team, togliendosi il "cappello da Product Owner". - Roy Nanku, ex formatore militare di Scrum di NavalX e attuale consulente di Scrum Inc.

‍

"Nella mia esperienza, il Product Owner deve essere presente al Daily Scrum perché ci sono sempre cose che saltano fuori e che appartengono alla sfera del 'Cosa'. " - Jessica Crowley, ex Project Controller per un grande produttore di freni per treni ed Enterprise Agile Coach, attuale consulente di Scrum Inc.

‍

Sembra proprio che questi dati ci dicano che il Product Owner dovrebbe partecipare a questo evento, ma comunque, la sua partecipazione può portare delle complicazioni. Quali sono i comportamenti di un Product Owner che possono "dirottare" un Daily Scrum? Elenchiamoli e poi esaminiamo come correggerli

Dirottamento! (E ritorno in pista)

Secondo la Guida Scrum, "lo scopo del Daily Scrum è di ispezionare i progressi in relazione all'obiettivo dello sprint e di adattare lo Sprint Backlog come necessario, adeguando il successivo lavoro pianificato". La comprensione dello stato dei lavori e quali sono gli impedimenti che non fanno andare avanti è l'ingrediente principale per adeguare il successivo lavoro pianificato. I compagni di squadra che si attivano per aiutarsi a vicenda (a volte chiamato "Swarming") è un modello benefico che speriamo di vedere in ogni Daily Scrum. Alla fine della giornata, è tutta una questione di comportamenti. Chiunque può far deragliare il Daily Scrum e renderlo improduttivo o degradarlo ad una semplice riunione sullo stato dei lavori. Lo stato dei lavori è importante che tutti lo sappiano,  ma ciò che è più importante per il team è trovare dei modi per portare tutto il lavoro a termine. Quali comportamenti del Product Owner possono far deragliare un Daily Scrum? E come possiamo evitarli o rimediare ad essi. Ecco le cinque principali categorie (con esempi) che si trovano comunemente e vediamo come risolverle.

1. Micro-management: il comportamento più debilitante che vediamo è quando i Product Owner entrano in ogni piccola cosa che lo Scrum Master o gli sviluppatori fanno. Un esempio di questo è quando iniziano ad occuparsi del "come" invece del "cosa" a discapito dell'innovazione. Un secondo esempio è quando si comportano come i tradizionali Project Manager e assegnano il lavoro alle persone. Un terzo esempio è quando sono eccessivamente concentrati sulle metriche di output del team, come la velocità, e si chiedono costantemente perché gli elementi del backlog non si muovono. Soluzione: Rimanere fuori dal COME! Tutti sanno gli imput richiesti dal Product Owner ma è meglio lasciare che il team ti abbagli con la sua genialità. Invece di dettare come le cose dovrebbero essere fatte, parla per ultimo, e usa le domande per esporre i difetti in un modo positivo, oppure aiuta il team a pensare ulteriormente fuori dagli schemi. Questo è particolarmente difficile quando il Product Owner è anche uno sviluppatore, quindi siate consapevoli di questo. Non assegnare il lavoro agli sviluppatori. Lasciate che scelgano quello che vogliono fare e di cui hanno la capacità. Coordinare questo è il loro lavoro facilitato dallo Scrum Master e non dal Product Owner. Rimanete concentrati sulle metriche di risultato e lasciate che il team sia guidato dalle metriche di output (es. velocità, il rapporto plan/do, ecc.). La capacità del team di autogestirsi è importante per creare una cultura di autonomia e di responsabilità.
2. L'amore per ii riflettori: Ci sono tre versioni comuni di questo comportamento. La prima è dirigere la riunione. Questa è un'espressione di micro-management. Nello specifico l'evento viene gestito in modo da far passare agli Sviluppatori le informazione che "vuole" il Product Owner invece delle informazioni di cui hanno bisogno per massimizzare la probabilità di raggiungere lo Sprint Goal. Il secondo è agire come un pubblico di una sola persona a cui i membri del team devono presentare ciò che hanno fatto. Il terzo è essere visti come (e accettare il ruolo di) unica fonte di risposte. Soluzione: Uno, non facilitare il Daily Scrum. A meno che non sia il tuo turno secondo un accordo di lavoro o qualche altro accordo. Lascia che lo Scrum Master aiuti il team a capire chi dovrebbe farlo se non è lo Scrum Master stesso. Due, non lasciare che gli sviluppatori parlino solo con te. Incoraggiateli a parlare con tutto il gruppo; lasciate che si sentano a loro agio e voi intervenite solo se è necessario. Cercate di includere coloro che sono più in disparte. Tre, sii consapevole che i membri del team ti trattano come un'enciclopedia. Favorite le conversazioni tra i membri del team con risposte come: "Grazie per avermelo chiesto. Prima di rispondere, mi piacerebbe sentire anche gli altri ".
3. Tempistica inappropriata delle nuove richieste: Naturalmente, il team ha bisogno di sapere delle nuove richieste, ma devono saperlo oggi? Mettere nuove richieste sul piatto per sentire le idee del team, solo per farglielo sapere, può essere molto dirompente per il lavoro corrente.  Mette i loro cervelli in una modalità di risoluzione dei problemi per le cose nuove e distoglie la loro attenzione dai loro impegni attuali. Soluzione: Introdurre nuove richieste al momento giusto. Se è veramente un'interruzione importante, allora il Daily Scrum è perfetto per questo. Se no, allora il momento migliore per introdurle è al Backlog Refinement. Come piano di riserva, potrebbe essere fatto come parte di una Sprint Review. In ogni caso, siate giudiziosi sul momento in cui presentate nuove richieste e pensate a come questo influenzerà la concentrazione e gli impegni del team.
4. Ritardi o assenze senza preavviso: I Product Owner  passano molto tempo con i clienti e gli stakeholder, spesso a discapito del tempo con il loro team. Questo può farli sentire trascurati o che essere parte dello Scrum Team è meno importante del resto del mondo. Soluzione: Aspettatevi di agire come qualsiasi altro membro del team e di presentarvi in tempo. Se non puoi farcela, aderisci a qualsiasi accordo di lavoro che il tuo team ha in merito al ritardo o a dire agli altri che non puoi partecipare. Il team sa che non sarai presente ad ogni Daily Scrum. Sii consapevole di quante volte manchi a questo e ad altri eventi e vedi se le cose stanno creando uno squilibrio. Fate in modo di bloccare il vostro calendario per il Daily Scrum (e altri eventi) in modo che i vostri compagni di squadra sappiano che stare con loro è una priorità tanto quanto parlare con i clienti e gli stakeholders.
5. Mancanza di informazioni cruciali: Se da una parte incoraggiamo i Product Owner a condividere quando è appropriato, potremmo avere dei problemi quando le risposte che il team ha bisogno non si possono avere a causa di un Product Owner che non è in contatto con i bisogni o i feedback dei clienti. Soluzione: Mentre essere presente con il team è da lodare, un Product Owner deve sapere comunque bilanciare il suo tempo anche con i clienti e gli stakeholder. Dopo tutto, lo scopo di queste interazioni, e il ruolo del Product Owner in generale, è quello di aiutare a tradurre quei bisogni e le informazioni in un backlog chiaro per il team. Senza questa parte si possono generare impedimenti che il team non può eliminare. Assicuratevi di partecipare ad ogni Sprint Review e imparate come tirar fuori un buon feedback sul prodotto, come catturarlo e distillarlo in un formato comprensibile per il team.

Conclusione

I Product Owner dovrebbero partecipare al Daily Scrum? I Product Owner possono essere utili se presenti al Daily Scrum in quanto sono un membro dello Scrum Team che ha informazioni critiche da condividere. Devono tener bene a mente che la loro presenza può essere benefica o dannosa e sta a loro incarnare i giusti comportamenti che promuovono l'agilità del team.

Tradotto ed adattato da: Scrum Inc - https://www.scruminc.com/should-product-owner-attend-daily-scrum/
Scritto da Avi Schneier | 23 luglio 2021 | Blog