Onlangs kreeg ik een vraag of de Product Owner aan de retrospective mag deelnemen. Er ontspon zich een interessante discussie over hoe “het moet volgens het boekje” en “gezond boerenverstand” die ik in onderstaande blog post heb samengevat.
This post is also available in English: Should the Product Owner attend the retrospective?
De vraag werd gesteld door een deelnemer van een training van Erik Philippus (auteur van de gastblog ervaringen met Agile en Scrum certificeringen en van het overzicht van Agile / Scrum Certification) n.a.v. een proefexamen voor Professional Scrum Master. In dat examen werd gevraagd of de Product Owner moet deelnemen aan de Sprint Retrospective. Mogelijke antwoorden waren dat het optioneel was (mits uitgenodigd door door de Scrum master), verplicht (de retrospective is een gelegenheid voor het Scrum team om zichzelf te assessen en te verbeteren) of niet toegestaan (de retrospective is enkel voor het development team).
Wel of geen Product Owner bij de retrospective
Waar mensen geneigd zijn om voor het eerste antwoord kiezen is de tweede correct. Bij voorkeur is de Product Owner erbij, het gehele Scrum team evalueert immers hoe de sprint gegaan is, en de Product Owner maakt onderdeel uit van het Scrum team. Daarbij is de samenwerking tussen de Product Owner en het development team iets wat in retrospective opgebracht kan worden, en dan is het m.i. noodzakelijk dat alle betrokkenen erbij zijn.
Waar er sprake is van een sterke hiërarchie in de organisatie, en het team de Product Owner ervaart als iemand die boven hun staat i.p.v. naast hun en teamleden daardoor niet open durven te zijn en uit te spreken over wat er fout gaat, zou de Scrum master de Product Owner kunnen verzoeken om initieëel niet naar de retrospectives te komen. Echter, na enkele retrospectives moet het team capabel genoeg zijn om met zoiets om te kunnen gaan, en dan is het juist beter dat de Product Owner er wel bij is.
Het eerste antwoord suggereert dat de Product Owner er alleen op invitatie van de Scrum master moeten zijn. Ik zie het andersom, de Product Owner is er per definitie bij, tenzij de Scrum master hem/haar verzoekt om niet te komen.
Erik’s reactie op mijn antwoord was:
Ik denk er hetzelfde over, en in de praktijk gaat het ook meestal zo dat de PO erbij is. Logisch.
Mooi, dan zijn we eruit? Bijna. Het vervolg van zijn reactie:
Maar zoals met diverse andere topics, is het juiste antwoord op de examenvraag wat minder logisch. Ik heb altijd begrepen dat ‘volgens de letter van de wet’ de PO er niet bij is, tenzij hij/zij wordt uitgenodigd door het Development Team. Ik ben er nog altijd niet uit wat nu het juiste antwoord is op de examenvraag. Vervelend dat praktijk/boerenverstand niet gelijk opgaan met de juiste antwoorden op diverse examenvragen …
Hoe moet het “volgens het boekje”
De Scrum Guide zegt dat de retrospective bedoeld is voor het Scrum team, dus inclusief de Product Owner:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
Dat sluit aan bij het tweede antwoord wat stelde dat de retrospective bedoeld is voor het gehele Scrum team, en het het sluit het derde antwoord (alleen het development team) duidelijk uit.
De Scrum guide zegt nergens dat het gehele Scrum team altijd bij de retrospective moet zijn, maar gezien de strekking van het verhaal in de Scrum guide is dat wel wat je zou mogen verwachten. Nergens staat in de Scrum Guide dat de Product Owner uitgenodigd moet worden.
Erik wees mij op de tekst in de Scrum Primer. Daarin staat dat de aanwezigheid van de Product Owner optioneel is:
Summary: Inspection and adaption related to the process and environment.
Participants: Team, ScrumMaster, Product Owner (optional). Other stakeholders may be invited by the Team, but are not otherwise allowed to attend.
Duration: Timeboxed to 45 minutes per week of Sprint.
Dit suggereert dat de Product Owner mag deelnemen aan de retrospective maar er niet verplicht bij hoeft te zijn. Of het team hem/haar moet uitnodigen of dat de Product Owner zelf mag beslissen om al dan niet deel te nemen is niet echt duidelijk in de Scrum Primer.
Wat ik dan wel weer mooi vind in de Scrum Primer is:
Sometimes the ScrumMaster can act as an effective facilitator for the Retrospective, but it may be better to find a neutral outsider to facilitate the meeting; a good approach is for ScrumMasters to facilitate each others’ retrospectives, which enables cross-pollination among Teams.
Iets wat ik helemaal achter sta, goed faciliteren van retrospectives is cruciaal!
Doe wat werkt voor jullie!
Zoals vaak met modellen en frameworks zijn meerdere interpretaties mogelijk. Het gezonde boerenverstand van Erik en mij vertelt ons dat we hem/haar erbij willen hebben. In de praktijk is dat gelukkig ook vaak zo, alhoewel er teams zijn die nog net even een zetje nodig hebben. Vandaar deze blog post :-).
In de workshop Agile Retrospectives leer je hoe je retrospectives toe kunt passen in je eigen organisatie. Met facilitatoren die in staat zijn om retrospectives zo te doen dat de er teams wat aan hebben en die bijdragen aan de doelen en resultaten van je organisatie.
Wat mij betreft is dit een no-brainer: natuurlijk moet de PO erbij zijn!
Hij is deel van het team, en dus deel van de retro. Hij heeft het meeste belang bij improvements en kan er dus het beste maar aan bijdragen. Het komt regelmatig voor dat de PO juist de bron is van problemen (te weinig aanwezig, durft geen keuzes te maken, etc.) en juist dan is het handig om dit met de PO te bespreken in plaats van achter zijn rug om te roddelen over zijn niet-functioneren.
Dus, hoewel ik snap dat het soms handig is om de PO te vragen niet te komen, is wat mij betreft de regel dat hij er altijd bij is.
Ik ben het helemaal met je eens André.
Een bijkomend voordeel bij deelname van de Product Owner aan de retrospective is dat verbeteracties uit de retrospective een grotere kans van slagen hebben. De Product Owner was er immer bij toen er beslist werd wat het team in de volgende iteraties wil gaan doen.
In prespectives (wij doen geen retrospectives) mag zelfs de directeur aanwezig zijn. De teamleden hebben daar geen enkel probleem mee, omdat ze precies weten wat ze doen en waarom ze dat doen. Mocht de directeur een goed advies of interessante or zelfs ‘rare’ zienswijze hebben dan horen ze dat graag en wordt bepaald wat ze daarmee gaan doen.
Als er een een cultuur van openheid en vertrouwen is dan is dit mogelijk Niels. Zo’n cultuur is er echter vaak niet, en soms alleen op kleine schaal zoals het team niveau.
Als retrospective facilitator hou ik daar rekening mee, je wilt immers dat de deenemers in de retrospective zaken (zowel negatief als positief) op durven brengen.
Het is aan het (autonome) team om te beslissen wie ergens aan deelneemt, maar ook welke (agile) events bijdragen aan het te leveren resultaat. Als iets of iemand niet bijdraagt aan het doel, dan kiest het team er voor om er mee te stoppen of er mee door te gaan. Dus: als de product owner onderdeel is van het team, is het logisch dat hij of zij er bij is. Maar het komt ook wel voor (ten minste in mijn ervaring) dat de product owner geen deel uitmaakt van het team en een stakeholder is, net als de andere stakeholders. Kortom: it depends! Dus iedereen die nu zegt dat de theorie het voorschrijft of die het team wilt opleggen hoe te werken naar het einddoel toe, heeft het Agile werken volgens mij niet helemaal begrepen… Check eens de verhandeling van Henrik Kniberg (je weet wel: van Spotify) over de Spotify Engineering Culture (part 1 en 2).
Dank voor je uitgebreide reactie Henk!
inderdaad, hoe de samenwerking tussen het development team en stakeholders zoals de product owner is speelt een rol. Echter, deze samenwerking is ook een cruciale factor om resultaten te bereiken. Als de product owner gezien wordt als een stakeholder dan kan het goed zijn om naast retrospectives met het development team ook regelmatig retrospectives met de stakeholders te doen. Mogelijke hoeven daar niet alle teamleden bij te zijn, dat is iets wat het team zelf prima kan inschatten. Maar m.i. heeft het nut om de samenwerking tussen ontwikkelaars en stakeholders onder de loep te nemen en waar mogeijk te verbeteren.
Henrik Kniberg heeft veel inspirerende dingen gedeeld (ik referereer op mijn Agile Self Assessments pagina naar zijn Scrum checklist en naar het Squad Healt Check model), prima tip van je. Overigens geldt voor Spotify net zoals voor alle “modellen” dat ze niet in elke situatie even bruikbaar zijn, “it depends” zoals je al zei in je antwoord. Maar er zit veel wijsheid in, dus doe er je voordeel mee.
Dank je wel, Ben, voor jouw respons op mijn reactie. Ik denk dat we qua inzichten elkaar niet ver ontlopen. Ik ben alleen meer geneigd om niet in modellen te denken, maar idd te kijken wat werkt in welke situatie en daar hoop ik anderen in mee te krijgen. Volgens mij probeert Kniberg dit ook uit te dragen en “evolueert” de WoW bij Spotify voortdurend.
We zitten inderdaad op een lijn, fijn om te zien.
In deze blog post heb ik ook gepoogd om een van de dilemma’s vanuit agile training te laten zien. Hoe mensen Scrum leren met een 2 daagse Scrum master cursus met een examen. In zo’n korte tijd is het onmogelijk om agile goed te kunnen begrijpen. Het risico is dan groot dat mensen alleen de “regels” en “rituelen” onthouden en die gaan uitvoeren “volgens het boekje”, wat vaak niet effectief is.
De werkwijze bij Spotify evolueert inderdaad, je kunt er veel van leren. Een waarschuwing: Ook hier geldt dat je het niet zomaar kunt kopiëren naar je eigen organisatie. Haal er dingen uit die er bruikbaar uitzien en pas die toe. En kijk hoe het gaat, in de stand-up, met een retrospective. Pas vervolgens je werkwijze aan.
Eigenlijk gaat het bij agile om continue verbetering 🙂
Leuk! Helemaal eens. Ik zie in de praktijk idd ook mensen, die zogenaamd gecertificeerd zijn, alleen vanuit de theorie acteren. Dus terecht dat je “na het behalen van het rijbewijs eerst nog moet leren rijden”! Doe je dat niet dan haal je juist het “Agile zijn” weg en wordt het contraproductief.
Welk model of methode je in een organisatie invoert, of het nu bijvoorbeeld ITIL, Lean 6Sigma of Agile werken is, alles draait inderdaad om continue verbetering!