Eén rol, twee petten: waarom Scrum Master én Product Owner combineren niet werkt

Blog

Eén rol, twee petten: waarom het combineren van Scrum Master en Product Owner niet werkt

Waarom het scheiden van verantwoordelijkheden cruciaal is voor een effectief Scrum-team

In veel organisaties, vooral die aan het begin staan van hun Agile-transformatie, wordt soms de verleidelijke beslissing genomen om de rol van Scrum Master en Product Owner bij één en dezelfde persoon te beleggen. Maar hoe goed bedoeld dit ook mag zijn, één persoon kan nooit tegelijk die kritische teamcoach én besluitvaardige eigenaar van het product zijn. Het plaatst één persoon in een constante spagaat tussen teambehoeften en productprioriteiten. En dat kan vergaande gevolgen hebben voor zowel het teamproces als het uiteindelijke product.

In dit artikel deel ik, Dennis Voorham Scrum Master bij Identify, waarom het combineren van de rollen Scrum Master en Product Owner in de praktijk vaak niet werkt en welke spanningen dit veroorzaakt in teamdynamiek, besluitvorming en productwaarde.

Als Agile Consultant bij Identify kom ik deze ‘dubbele pet’ nog altijd tegen in vacatureteksten of opdrachtbeschrijvingen. Een organisatie die op zoek is naar een Product Owner, die ‘wanneer het nodig is’ óók de rol van Scrum Master op kan pakken.

Het klinkt zo aantrekkelijk: één persoon die zowel de rol van Product Owner (PO) als Scrum Master vervult. Op papier bespaart dit tijd en moeite, maar in de praktijk zien we dat het maar al te vaak averechts werkt. De rollen hebben tegengestelde doelen, vragen andere vaardigheden, vergen allebei veel aandacht en daarmee ook veel tijd. Sterker nog, door deze rollen samen te voegen, worden de fundamentele Scrum-principes – of ‘spelregels’ zoals ik ze eigenlijk graag noem – ondermijnd.

Botsende verantwoordelijkheden

De Product Owner draagt de verantwoordelijkheid voor het product en de waarde die het oplevert. Hij/zij bepaalt wat er ontwikkeld wordt en houdt daarbij rekening met zowel gebruikers als Stakeholders.

In een steeds veranderende markt worden eisen en wensen continu bijgesteld. Het is de taak van de Product Owner om alert te zijn op deze schommelingen en zorgvuldig af te wegen welke aanpassingen direct klantwaarde opleveren. De Product Owner schat continu risico’s in, toetst requirements op haalbaarheid binnen de gestelde termijnen én moet ondertussen zorgen voor een goede balans tussen de verschillende en vaak tegengestelde belangen van de Stakeholders.

De Scrum Master richt zich juist op hoe het team werkt. Als onafhankelijk coach begeleidt hij/zij het proces, faciliteert samenwerking, coacht het team én de Product Owner, en ondersteunt hij/zij het management om een cultuur van vertrouwen en samenwerking bevorderen, waardoor teams effectief en onder zelforganisatie kunnen werken aan complexe projecten.

Wanneer één persoon beide rollen vervult, liggen conflictsituaties al snel op de loer.

Want wie grijpt in als de Product Owner te veel druk op het team legt, of het team er samen met de Product Owner niet in slaagt om overeenstemming te bereiken bij lastige beslissingen? Wie biedt ondersteuning wanneer er spanningen binnen het team ontstaan? En wat als het team geen ‘Impediments’ (belemmeringen / obstakels) durft te melden omdat die de Product Owner zelf betreffen?

De Scrum Master is er om vanuit een onbevooroordeelde positie niet alleen het team, maar óók de Product Owner te ondersteunen en te coachen. Wanneer één persoon alles bepaalt én begeleidt, doe je direct afbreuk aan het fundament van Scrum.

Intern conflict leidt tot extern verlies

Wanneer één persoon zowel Product Owner als Scrum Master wordt loopt diezelfde persoon het risico om met zichzelf in conflict te raken. De rollen hebben namelijk tegengestelde belangen: de Product Owner wil voortdurend meer waarde leveren en dus vaker op resultaten sturen, terwijl de Scrum Master juist moet waken over het proces, het team moet beschermen en soms op de rem moet trappen.

Dit interne conflict kan leiden tot:

  • Wankele prioriteiten, omdat de persoon niet meer weet vanuit welke pet hij of zij beslist;

  • Verminderd teamvertrouwen, omdat het team geen duidelijke richting of bescherming ervaart;

  • Ongezonde druk, doordat de “Product Owner-kant” deadlines blijft pushen terwijl de “Scrum Master-kant” ziet dat het team overbelast raakt;

  • Vervaging van verantwoordelijkheid, wat uiteindelijk de kwaliteit van zowel het product als het proces ondermijnt.

Kortom, door beide rollen te combineren kan één persoon in een voortdurende spagaat terechtkomen, met negatieve gevolgen voor zowel het team en het product

“Het samenvoegen van Scrum Master en Product Owner lijkt misschien slim, maar het knelt de rollen juist af.”

-Dennis Voorham, Agile consultant

Tijdgebrek als belemmering

De Product Owner is verantwoordelijk voor het uitzetten van strategie en visie, het begrijpen van markt en klanten, het prioriteren van werk en het managen van Stakeholders.

De Scrum Master richt zich echter op het optimaliseren van teamdynamiek, het verbeteren van processen, het begeleiden van de teamontwikkeling en het ondersteunen van het management.

Dit zijn allemaal taken waar beslist niet te licht over gedacht mag worden, want voor één persoon is het vrijwel onmogelijk om beide sets vaardigheden volledig te beheersen.

Het is dan ook duidelijk dat het samenvoegen van beide rollen een aanzienlijke druk op één persoon kan leggen. Hierdoor komt de kwaliteit van het werk bijna altijd onder druk te staan.

Conclusie

Het samenvoegen van Scrum Master en Product Owner lijkt misschien slim, maar het knelt de rollen juist af. We moeten ons realiseren dat Scrum Master en Product Owner bewust als afzonderlijke rollen zijn ontworpen en daarmee juist complementair aan elkaar moeten zijn. Een goede invulling van deze rollen begint bij een duidelijk begrip van taken en verantwoordelijkheden.

Door verantwoordelijkheden gescheiden te houden, voorkomen we de complexiteit en problemen die ontstaan wanneer één persoon beide rollen probeert te vervullen.

Hierdoor krijgt iedereen de ruimte om zijn of haar werk écht goed te doen en bevordert het de groei naar een sterk, high-performing team die aan de verwachtingen van de organisatie tegemoet komt – en zelfs keer op keer weet te overtreffen!

Klaar om te sparren?
Benieuwd wat Agile werken voor jouw organisatie kan betekenen? Bij Identify helpen we dagelijks toonaangevende organisaties om wendbaarder, efficiënter en succesvoller te worden. Neem contact met ons op of ontdek hoe je kan beginnen met Agile werken.

Over de auteur

Foto van Dennis Voorham

Dennis Voorham

Dennis Voorham is Agile Consultant bij Identify. Als ervaren Scrum Master ondersteunde hij teams bij onder andere het Nationaal Archief en de Belastingdienst en helpt organisaties hun samenwerking en resultaten te verbeteren. Zijn menselijke aanpak en focus op continu ontwikkelen brengen teams dagelijks naar een hoger niveau.

Mail
Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd
Identify Consultancy Amersfoort Great Place To Work 2025

Contact

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.

De onmisbare rollen in een Scrum-team

Blog

De onmisbare rollen in een Scrum-team: Product Owner en Scrum Master

Verantwoordelijkheden en relatie van Scrum Master en Product Owner

Binnen het Scrum-framework zijn twee rollen absoluut essentieel: de Product Owner en de Scrum Master. Hun verantwoordelijkheden, focus en manier van werken verschillen sterk, maar juist doordat ze elkaar aanvullen, kan een Scrum-team optimaal presteren.

In dit artikel deel ik, David Korten, Scrum Master bij Identify, hoe deze rollen elkaar versterken en welke unieke bijdrage ze leveren aan het succes van agile teams.

Focus en verantwoordelijkheden?

Product Owner – Het ‘wat’ en ‘waarom’

De Product Owner bepaalt wat er wordt ontwikkeld en waarom dit waardevol is voor klant en organisatie. De verantwoordelijkheden zijn onder meer:

  • Het maximaliseren van de waarde van het product;
  • Het beheren en prioriteren van de Product Backlog;
  • Stakeholdermanagement en het uitdragen van de productvisie.

Als Product Owner vertegenwoordig je de klant en ben je de schakel tussen het Scrum-team en de stakeholders.

Scrum Master – Het ‘hoe’ 

Als Scrum Master richt ik mij op hoe het team zo effectief mogelijk kan samenwerken. Daarbij:

  • Faciliteer ik het Scrum-proces, inclusief Daily Scrums, Retrospectives en Sprint Planning;
  • Verwijder ik obstakels (impediments) die het team hinderen;
  • Coach ik het team in zelforganisatie en Agile-principes.

Relatie met het Scrum-team

Product Owner

  • Geeft duidelijke doelen en prioriteiten aan het team;
  • Zorgt dat het team begrijpt wat er nodig is, maar bemoeit zich niet met de technische uitvoering.

Scrum Master

  • Beschermt het team tegen verstoringen van buitenaf;
  • Stimuleert samenwerking en bewaakt de toepassing van Scrum;
  • Helpt teamleden obstakels te overwinnen en agile vaardigheden te ontwikkelen.

Stakeholdermanagement en planning

Product Owner

  • Onderhoudt intensief contact met stakeholders om wensen, eisen en feedback te verzamelen;
  • Zorgt voor alignment tussen klantbehoeften en de ontwikkeldoelen van het team;
  • Stelt prioriteiten in de Product Backlog;
  • Bepaalt samen met stakeholders welke items de meeste waarde toevoegen.

Scrum Master

  • Heeft een interne focus en beschermt het team tegen onrealistische verwachtingen of druk van stakeholders;
  • Ondersteunt de Product Owner bij het communiceren van voortgang en resultaten;
  • Faciliteert processen om backlog-items efficiënt en effectief te realiseren;
  • Bewaakt de sprintdoelen en helpt het team bij het behalen ervan.

“De Product Owner bepaalt wat belangrijk is, de Scrum Master zorgt voor hoe het team dat het beste kan bereiken.” – David Korten, Scrum Master

Product owern en scrum master schrijven scrum op whiteboard tijdens een sprint sessie

Hoe vullen de Product Owner en Scrum Master elkaar aan?

Hoewel hun rollen verschillend zijn, vormen de Product Owner en Scrum Master samen de motor van een effectief Scrum-team.

Gezamenlijke missie: waarde leveren

  • Product Owner: stelt prioriteiten en definieert waarde;
  • Scrum Master: optimaliseert de manier waarop het team deze waarde realiseert.

Efficiënte communicatie

  • Product Owner: vertaalt stakeholderinput naar heldere backlog-items;
  • Scrum Master: zorgt dat het team deze input efficiënt verwerkt.

Bouwen aan een succesvol team

  • Product Owner: profiteert van een betrouwbaar team dat waarde levert.
  • Scrum Master: coacht het team in samenwerking en zelforganisatie;

Verwijderen van obstakels

  • Product Owner: lost strategische uitdagingen op, zoals veranderende prioriteiten.
  • Scrum Master: pakt interne belemmeringen aan;

Visie en uitvoering

  • Product Owner: levert de productvisie en prioriteiten;
  • Scrum Master: zorgt dat het team optimaal functioneert om deze te realiseren.

Hebben ze elkaar nodig?

Ja. De Product Owner en Scrum Master zijn complementair. Samen zorgen ze voor:

  • Heldere focus: de Product Owner bepaalt waarde en prioriteiten, de Scrum Master bewaakt de focus binnen het team.
  • Efficiënt proces: de Scrum Master faciliteert het proces zodat de doelen van de Product Owner haalbaar zijn.
  • Balans tussen team en stakeholders: de Product Owner richt zich op externe behoeften, terwijl de Scrum Master op teamwelzijn en samenwerking focust.

Conclusie

De Product Owner is de stem van de klant: bepaalt prioriteiten en maximaliseert productwaarde. De Scrum Master is de facilitator en coach: zorgt dat het team optimaal kan presteren. 

Samen vormen ze het fundament van een succesvol Scrum-team. Of, zoals ik het altijd zeg: “De Product Owner bepaalt wat belangrijk is, de Scrum Master zorgt voor hoe het team dat het beste kan bereiken.”

Klaar om te sparren?
Benieuwd wat Agile werken voor jouw organisatie kan betekenen? Bij Identify helpen we dagelijks toonaangevende organisaties om wendbaarder, efficiënter en succesvoller te worden. Neem contact met ons op of ontdek Agile werken.

Over de auteur

Foto van David Korten

David Korten

David Korten is Agile consultant bij Identify. Als Scrum Master streeft hij, met zijn kritische houding, voortdurend naar verbetering. Dankzij zijn ervaring in onder andere de publieke sector en de financiële dienstverlening heeft hij met diverse teams impact gemaakt in uiteenlopende trajecten.

Mail
Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd
Identify Consultancy Amersfoort Great Place To Work 2025

Contact

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.

Effectief communiceren tijdens een scrum event

Blog

Effectief communiceren tijdens een scrum events

Hoe haal je meer uit elk scrum event

In agile teams draait samenwerking om meer dan alleen de inhoud. Goede communicatie is essentieel om snel te schakelen, knelpunten te tackelen en als team te groeien. Toch lopen veel events uit, verzanden in details of leiden tot frustratie. Hoe zorg je dat een event wél effectief is? In dit artikel deelt Agile consultant David Korten een aantal praktische tips.

Hoe verbeter je de communicatie tijdens een scrum event?

  1. Beperk het aantal onderwerpen
    Focus op de belangrijkste punten. Diepgaande discussies? Plan daar een aparte sessie voor in. Zo hou je focus én energie vast.
  2. Stel heldere doelen per event
    Gaat het om informeren, besluiten of brainstormen? Spreek dit aan het begin uit. Zo weet iedereen waar het overleg naartoe moet.
  3. Stimuleer gestructureerde bijdragen
    Geef ieder teamlid kort het woord. Een ‘rondje langs het bord’ helpt om iedereen betrokken te houden – zonder chaos.
  4. Bevorder actief luisteren
    Laat mensen uitspreken. Vat samen of herhaal wat er gezegd is om misverstanden te voorkomen en de boodschap kracht bij te zetten.
  5. Beperk afleidingen
    Zet telefoons op stil, sluit onnodige schermen. Volle aandacht = betere besluiten.
  6. Gebruik een facilitator
    Een Scrum Master of neutrale gespreksleider helpt om de structuur te bewaken en ervoor te zorgen dat iedereen wordt gehoord.
  7. Sluit af met actiepunten
    Wat is afgesproken? Wie doet wat en wanneer? Sluit elk agendapunt af met concrete vervolgstappen.
  8.  

“Zet je telefoon op stil, sluit onnodige schermen en vergeet je smartwatch niet. Niets is zo storend als die collega die tóch zijn WhatsApp zit te lezen.” – David

Agile werkoverleg tips van David, Scrum Master bij Identify IT-consultancy, zet alles ook je smartphone en watch op niet storen.

Wanneer onderbreek je een collega?

Onderbreken voelt soms ongemakkelijk, maar het is soms nodig om het overleg efficiënt te houden. Doe dit respectvol en doelgericht in de volgende situaties:

  • De discussie gaat off-topic “Laten we dit onderwerp parkeren voor later, zodat we nu bij het agendapunt blijven.”
  • Iemand neemt te veel tijd “Goed punt, maar laten we het kort houden zodat ook anderen hun input kunnen geven.”
  • Er is herhaling “Dank voor je herhaling, volgens mij is het duidelijk. Laten we doorgaan met het volgende punt.”
  • De sfeer wordt gespannen “Laten we dit onderwerp even laten rusten. We kunnen hierop terugkomen in een aparte sessie.”

Wanneer laat je een discussie juist doorgaan?

Niet elke lange discussie is slecht. Laat gesprekken doorgaan als ze iets toevoegen aan het event:

  • Er ontstaat waardevolle input “Dit punt lijkt belangrijk en verdient verdieping. Laten we hier meer tijd voor nemen.”
  • Er is sterke betrokkenheid “Mooi om te zien hoe actief iedereen meedenkt. Laten we dit verder uitwerken.”

Een open gesprek over verschillen van inzicht kan leiden tot betere besluiten en versterkt onderling vertrouwen, waarin meningsverschillen constructief worden besproken. Of als er is voldoende tijd beschikbaar is en de planning het toelaat, kan een langere discussie juist verdieping brengen, zolang het team erbij gebaat is.

Hoe blijf je respectvol bij het onderbreken of begeleiden van een gesprek?

  • Gebruik positieve taal “Interessant punt, laten we dit later oppakken zodat we nu op koers blijven.”
  • Wees objectief, niet persoonlijk “We willen graag de agenda volgen, zodat we alles kunnen bespreken.”
  • Pas timeboxing toe, geef vooraf aan hoeveel tijd er is voor elk punt. Zeg bijvoorbeeld: “We hebben nog twee minuten voor dit onderwerp.”

Conclusie

Effectieve communicatie vraagt om structuur, heldere doelen en wederzijds respect. Onderbreek collega’s wanneer het nodig is om focus te behouden, maar laat gesprekken doorgaan als ze waardevol zijn voor het team of de organisatie.

Of je nu werkt in een Scrum team in Amsterdam, of onderdeel bent van een groter projectteam binnen de overheid, een goed geleid scrum event bespaart tijd, voorkomt misverstanden en versterkt samenwerking aldus David Korten, Scrum Master bij Identify.

Over de auteur

Foto van David Korten

David Korten

David Korten is Agile consultant bij Identify. Als Scrum Master streeft hij, met zijn kritische houding, voortdurend naar verbetering. Dankzij zijn ervaring in onder andere de publieke sector en de financiële dienstverlening heeft hij met diverse teams impact gemaakt in uiteenlopende trajecten.

Mail
Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd
Identify Consultancy Amersfoort Great Place To Work 2025

Contact

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.

Is de daily stand-up in Scrum een werkoverleg?

Blog

Is de daily stand-up in Scrum een werkoverleg?

Een effectieve daily

In de praktijk wordt de daily stand-up, ook wel de daily scrum genoemd, vaak gezien als een vorm van werkoverleg. Logisch ook, vindt David Korten, Agile consultant bij Identify: “Tijdens de stand-up bespreken teamleden de voortgang, delen ze knelpunten en stemmen ze af wie waarmee bezig is. Dat lijkt sterk op een klassiek werkoverleg.”

Toch is er volgens David een belangrijk verschil. Een effectieve daily stand-up is namelijk géén overleg in traditionele zin, maar een kort en krachtig afstem moment met een specifiek doel.

Mag je de stand-up als werkoverleg beschouwen?

In een agile werkomgeving zoals Scrum is het op zich niet erg als de daily stand-up als ‘werkoverleg’ wordt ervaren, zolang het oorspronkelijke doel maar niet uit het oog wordt verloren. En daar wringt het soms.

Want hoewel interesse in elkaar belangrijk is binnen een team, kan het doorslaan in gezelligheid of uitweiden over bijzaken de focus tijdens een stand-up wegnemen. En juist die focus op het sprintdoel maakt de daily scrum zo krachtig.

“Tijdens de stand-up bespreken teamleden de voortgang, delen ze knelpunten en stemmen ze af wie waarmee bezig is.”

Wat is het échte doel van een daily scrum?

De daily scrum is bedoeld om:

     De voortgang richting het sprintdoel zichtbaar te maken;

     Blokkades of obstakels snel te signaleren;

     Afstemming te bevorderen, zodat teamleden gericht kunnen samenwerken.

Het is dus een instrument voor zelforganisatie, en niet voor controle of rapportage.

Wanneer wordt een stand-up een probleem?

Een daily stand-up verliest zijn waarde als het verzandt in een traditioneel overleg. Denk aan:

     Een stand-up die uitloopt tot een half uur of langer;

     Collega’s die rapporteren aan de Scrum Master in plaats van met elkaar praten;

     Diepgaande discussies die de vaart eruit halen en het team verdelen;

     Of een sfeer waarin de stand-up aanvoelt als een ‘moetje’ in plaats van een energiek startmoment van de dag. 

Hoe houd je de daily stand-up waardevol?

Een effectieve daily scrum draait om ritme, structuur en focus. Deze tips helpen agile teams om de stand-up scherp te houden:

      Houd het kort en staand – maximaal 15 minuten;

     Focus op het sprintdoel en de samenwerking;

     Zet complexe discussies in de ‘parking lot’: plan ze na afloop;

     Gebruik een vaste structuur: bijvoorbeeld drie vragen of een rondje langs het bord;

     Evalueer regelmatig in de retrospective hoe de stand-up loopt.

Conclusie

Het is niet erg als de daily stand-up in een Scrum-team aanvoelt als een werkoverleg, zolang de kern maar overeind blijft: samenwerken aan het sprintdoel, blokkades wegnemen en de teamdynamiek versterken.

De daily scrum is géén rapportage moment aan een leidinggevende of Scrum Master. Het is een instrument dat agile teams helpt om eigenaarschap te nemen, de samenwerking te verbeteren en focus te houden op wat er echt toe doet.

Over de auteur

Foto van David Korten

David Korten

David Korten is Agile consultant bij Identify. Als Scrum Master streeft hij, met zijn kritische houding, voortdurend naar verbetering. Dankzij zijn ervaring in onder andere de publieke sector en de financiële dienstverlening heeft hij met diverse teams impact gemaakt in uiteenlopende trajecten.

Mail
Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd
Identify Consultancy Amersfoort Great Place To Work 2025

Contact

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.

Hoe komen Business Analyse, Testen en Agile werken samen?

Kennis

Hoe komen Business Analyse, Testen en Agile werken samen?

Samen werken aan kwaliteit, snelheid en wendbaarheid

Agile werken is iets wat steeds meer organisaties herkennen, doen of proberen na te streven. Business Analyse slaat de brug tussen de business en de IT-organisatie. Het testen van software heeft tot doel om te toetsen of voldaan wordt aan functionele en non-functionele eisen en wensen. Agile, Business Analyse en Testen kent Identify als geen ander. Wij vinden de Mens (Agile), (Proces) Business Analyse en IT (Testen) de drie belangrijkste factoren/pijlers van een organisatie (zie figuur 1). Middels ‘Kwaliteitsregie’ stemmen we deze drie pijlers op elkaar af. Hierbij zorgen we er voor dat deze pijlers naadloos op elkaar aansluiten.

In de praktijk

Veranderingen uit de markt of in de eigen organisatie leiden tot veranderingen in eisen en wensen aan het ondersteunende IT-landschap. En in een snel veranderende markt moeten deze eisen en wensen in een hoog tempo worden geïmplementeerd in nieuwe of bestaande software. Tegenwoordig worden deze eisen en wensen steeds rapper tempo opgevoerd in een versnellende en veranderende markt. Dat kunnen kleine aanpassingen zijn of grote implementaties of migraties bij het samenvoegen van systemen/bedrijven.

Vanaf het opstellen van de eisen en wensen (requirements) is het noodzakelijk deze op de juiste en correcte wijze snel en effectief vertaald te krijgen voor een software development team. Meestal is dat het werk van een Business Analist. De Business Analist identificeert, analyseert en specificeert de requirements van zowel de business/opdrachtgever als klanten en communiceert deze inclusief acceptatie criteria naar het development team of (software)leverancier. Het is een bruggenbouwer tussen business en IT.

 

Figuur 1

Als een organisatie het software testen goed heeft ingeregeld dan wordt in het vroegste stadium ook al een tester betrokken bij het maken en toetsen van de requirements. In deze fase kan een tester gerichte vragen stellen zodat de requirements duidelijker worden. Tevens kan de Tester alvast zijn testplan/strategie bepalen. Het vroegtijdig meedenken in het proces zorgt later voor minder fouten gedurende het proces en meer duidelijkheid tijdens het bouwen van de software. Een win-win situatie.

Daarnaast is een Agile proces, waarbij het inspelen op veranderingen van belang is, belangrijk om het software ontwikkelproces effectief en efficiënt te laten verlopen. Bijvoorbeeld door gebruik te maken van een software ontwikkelproces dat incrementeel en iteratief software levert met behulp van het Scrum Framework. Een Scrum Master is iemand die het scrum proces door en door kent, en het team of de teams hierin kan coachen en belemmeringen (impediments) kan helpen oplossen en voorkomen. Hierdoor is de kans op vertraging minimaal. We kennen namelijk allemaal wel een project dat uitgelopen of gestopt is door veranderende omstandigheden of onduidelijke requirements. Bedrijfsdoelstellingen worden niet meer gehaald en de klanttevredenheid daalt.

Hoe kan dit beter en slimmer?

Zoals we zien is er een hele keten van kennis en ervaring nodig om vanuit een requirement uiteindelijk te komen tot kwalitatief goede software. Deze software helpt het proces van de klant verbeteren en de wensen van de opdrachtgever te vervullen en bedrijfsdoelstellingen te halen. Bij Identify helpen we klanten om het software ontwikkelproces goed of beter te laten verlopen. Met onze gebundelde kennis van Business Analyse, Agile werken en Testen weten we de regie op de kwaliteit in handen te houden en kijken we verder dan de afzonderlijke disciplines.

Wat betekent dit concreet in de praktijk?

Als ik dit voorbeeld op mijzelf betrek, dan kan ik aangeven dat ik jarenlange ervaring heb op het gebied van software testen. Denk aan Systeemtesten, (non-)Functioneel testen, Gebruikerstesten en Regressietesten. Ik heb dus ervaring op de inhoud, maar ook in de rol als Testmanager weet ik goed hoe het Testproces werkt. In 2010 is het Agile werken met behulp van Scrum op mijn pad gekomen. Ik heb in 2013 mijn PSM1 gehaald en heb in de rol als Scrum Master ook het testen tijdelijk gecombineerd. Tot op de dag van vandaag helpt me dat om mijn teams te helpen de kwaliteit hoog te houden. Door het stellen van kritische vragen blijft het team scherp op het gebied van testen. Mijn rol is daarmee tweeledig en dat helpt het team en het proces.

Bij Identify zien wij dat veel organisaties kampen met problemen, verwarring en vertraging in de keten van software ontwikkeling. Denk hierbij bijvoorbeeld aan leveranciers die niet tijdig de juiste software kunnen opleveren. Dat kan intern ook tussen teams zijn waarbij het werk net niet op elkaar aansluit, maar ook bevindingen in het testproces waardoor features terug moeten in het proces (‘naar de tekentafel’) om aangepast en opnieuw getest te worden. Waarschijnlijk herken je wel iets in dit voorbeeld, dit betekent dat de ketenregie niet voldoende op orde is.

Wat is het probleem precies? Wie is daar verantwoordelijk voor? Hoe kunnen we dat voorkomen?

Zomaar wat vragen die we allemaal tegenkomen als dergelijke problemen zich in de keten voordoen. Deze vragen stellen we met meerdere doelen. Namelijk het voorkomen van problemen voor voor zowel onze klanten als voor onszelf als ‘gebruikers’ van de systemen. Maar ook het hooghouden van klanttevredenheid en het groeien van bedrijfsresultaten.

Hoe zorgen wij voor regie op kwaliteit?

Binnen Identify hebben we ervaren dat bijvoorbeeld het T-shaped werken, wat we kennen vanuit ‘Agile werken’, helpt om kennis en kwaliteit te verbreden en te verbeteren. De T-shaped professionals van Identify hebben de kennis van bijvoorbeeld testen, de ligger op de ‘T’, en een diepgaande kennis van Agile werken, de staander van de ‘T’. Dat is bijvoorbeeld het profiel van een Scrum Master. T-shaped werken is natuurlijk maar een klein deel en een voorbeeld. Maar Identify gaat verder… Wij combineren de 3 pijlers Agile werken, Testen en Business Analyse. Hiermee helpen we IT, het proces en de mens (zie figuur 1.0) van uw organisatie verder door ze met elkaar te verbinden en te verbeteren. Hiermee realiseren wij regie op de kwaliteit in de keten die elke organisatie vooruit helpt.

Wil je meer weten over hoe wij u kunnen helpen? Neem contact op via onze website of stuur mij een persoonlijk berichtje via LinkedIn.

Let’s talk

Klaar om te sparren?

Met een unieke aanpak op basis van co-creatie en onze expertise in Agile, Business Analyse en IT-Testen helpen we organisaties door heel Nederland écht vooruit. Heb jij een uitdaging? We denken graag met je mee!

Over identify

Al ruim vijftien jaar biedt Identify een sterke combinatie van diensten voor het optimaliseren van producten en processen binnen organisaties. Dat doen we niet vóór, maar samen mét onze opdrachtgevers.

Onze business analisten, agile consultants en test consultants zijn meer dan vakexperts. Dankzij expertise-overschrijdende samenwerking en gedeeld eigenaarschap pakken we complexe vraagstukken integraal aan. Zo realiseren we duurzame verbeteringen die organisaties écht vooruithelpen.

Co-create to accelerate

Over de auteur

Foto van Maarten Hermans

Maarten Hermans

Als gestructureerde en resultaatgerichte Agile consultant, met ruime ervaring in softwareontwikkeling binnen de financiële dienstverlening ben ik sinds 2019 onderdeel van Identify. Als scrum master werk dagelijks samen met opdrachtgevers aan échte impact.

Mail
Identify Consultancy Amersfoort voor Agile, Business Analyse en Scrum is NEN 4400-1 gecertificeerd
Identify Consultancy Amersfoort Great Place To Work 2025

Contact

Ik wil up to date blijven

Blijf op de hoogte met onze gratis nieuwsbrief.

Hoe was het op school vandaag?


Hoe was het vandaag op school?

Auteur:

Udo Kuijpers

Agile consultant


LinkedIn

Hoe was het op school vandaag?

Wat was jouw antwoord op de vraag ‘Hoe was het op school vandaag?’ Als ik deze vraag aan mijn kinderen stel, krijg ik steevast hetzelfde antwoord “Goed”. Scrum kent een krachtig mechanisme in het ‘continu’ verbeteren, de retrospective.

Hierin kijk je na iedere sprint terug en stel je de volgende vragen: Wat ging er goed? Wat kan er beter? Hoe zitten wij in de wedstrijd?

Door iedere retrospective deze vragen te stellen, wordt deze tot een “hoe was het op school vandaag” vraag gedegradeerd. Teamleden verwachten de vragen, ze worden immers iedere sprint opnieuw gesteld. Wanneer de scrum master zelf niet verder komt dan de ‘hoe was het op school vandaag’ vraag, hoe kan deze het team dan prikkelen om te vertellen wat ze dwars zit? Wie er een compliment verdient? Of waar het nu echt mee afgelopen moet zijn?

Mijn ambitie is om bij één team nooit dezelfde retrospective aan te bieden. Ik start iedere retrospective met een check-in: ‘Hoe hebben wij de afgelopen sprint ervaren?’ Dat gebeurt de ene keer door het team te vragen een vergelijking te maken tussen een weerbericht en je gemoedsgesteldheid, en de andere keer de vergelijking met de ranglijst van de eredivisie en je gemoedsgesteldheid (wat ook weer leuke discussies oplevert, wanneer je deze na het juiste weekend gebruikt). Ook kan je teamleden vragen om de afgelopen sprint te beoordelen met een cijfer op schaal van 1 tot en met 10.

Een dergelijke check-in levert veel op, vaak komen zaken die er echt toe doen dan al op tafel. Door Covid-19 houd ik mijn retrospective nu veelal digitaal (vaak met gebruik van Mural) maar wanneer wij weer naar kantoor kunnen, loont het zich om bijvoorbeeld met je team naar buiten te gaan. Het geeft een andere dynamiek en je doet direct aan teambuilding. Ga bijvoorbeeld buiten voor twee bankjes staan en deponeer 10 stellingen, zo zwart wit mogelijk! ‘Eens’ op het linker bankje, ‘oneens’ op het rechter bankje. De discussies met de bijbehorende argumenten die daaruit voortkomen zullen het team daadwerkelijk verbeteren.

Laat teamleden kiezen uit de verschillende auto’s, de types doen er niet toe. De teamleden zullen de juiste argumenten geven: Waarom die auto? Wat kan er dus beter? Gebruik spreekwoorden, laat teamleden een liedje kiezen wat symbool stond voor de afgelopen sprint. Het team zal geprikkeld worden om na te denken welk liedje waarom symbool stond.

Uiteindelijk is het verstandig om op zijn tijd twee of drie maanden terug te kijken. Waar stonden wij als team? Wat ging er mis? En kijk eens waar wij nu staan!

Dit door de kracht van een variërende retrospective.

 

Wil je meer weten over hoe wij u kunnen helpen? Neem contact op via onze website of stuur mij een persoonlijk berichtje via LinkedIn.

Interesse? We praten graag met je verder!

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Kjell Korfage.


Hoe kan een Agile portfoliomanagement experiment vorm krijgen?

Hoe kan een Agile portfoliomanagement experiment vorm krijgen?

In de blog ‘Hoe kan Agile portfoliomanagement ingericht worden?’ ben ik ingegaan op het uitvoeren van een experiment om te ontdekken wat past binnen de organisatie. Daarin verwijs ik naar een drietal overzichten waarmee de relatie tussen idee en uitvoering concreet gemaakt kunnen worden. Deze overzichten zijn het Product Vision Board, de GO (Goal Oriented) Product Roadmap en het Product Canvas.

Wat leg je vast in het Product Vision Board

Het Product Vision Board beschrijft laagdrempelig wat anders moet zijn na de realisatie van een product of dienst. Voor wie is het product of de dienst bedoeld, welke voordelen worden er geboden of welk probleem wordt er opgelost, wat maakt het bijzonder of aannemelijk dat het te realiseren is en welke business doelen worden hiermee behaald?

Wat is het doel van de GO Product Roadmap

Het doel zit verstopt in de naam. Het is een planning op de middellange termijn waarin duidelijke meetbare doelen (KPI’s) worden gesteld voor de verschillende releases of versies van het product. Door de scope per release/versie duidelijk te formuleren met de bijbehorende features en hoe bewezen gaat worden dat deze behaald zijn, realiseert deze roadmap transparantie en voorspelbaarheid bij de betrokkenen.

Waarom dan nog het Product Canvas

Het Product Canvas bevat de details per release. Denk hierbij aan een verbijzondering van de doelgroep, een uitwerking van de features inclusief architectuur, non-functionals (zoals productkwaliteit, beveiliging en bruikbaarheid), designs en de Product Backlog. Ook is een realistische visie van deze release beschreven zodat iedereen die betrokken is weet wat de gedetailleerde inhoud is en de reden waarom specifiek deze inhoud onderdeel maakt van de release.

Het Product Vision Board, de GO Product Roadmap en het Product Canvas passen goed bij de fases of gelaagdheid die je als organisatie doorloopt om vanuit een visie of droom toe te werken naar geprioriteerde features en dit te koppelen naar concreet te realiseren onderdelen. Zie het voorbeeld van een high level Agile proces waarin de overzichten zijn gebruikt. Rollen zijn bewust niet ingevuld aangezien de invulling onderdeel is van het experiment.

Heb ik hiervoor een systeem of software nodig?

Nee! Dit proces kan volledig op papier of post-its worden ingericht zonder extra kosten voor bijvoorbeeld een applicatie. Door eerst te experimenteren op papier en dit samen te doorleven wordt het proces geheel eigen en ligt de focus op leren. Verwachtingen worden tastbaar en samenwerking gestimuleerd.

Als het resultaat van een experiment of pilot naar meer smaakt kan altijd een automatiseringsslag worden gemaakt. Zolang het doel (zie blog ‘Waarom zou je Agile portfolio management willen inrichten?’) voorop blijft staan.


Interesse? We praten graag met je verder!

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Kjell Korfage.

Hoe kan Agile portfoliomanagement ingericht worden?

Hoe kan Agile portfoliomanagement ingericht worden?

In mijn vorige blog ben ik ingegaan op de vraag waarom je Agile portfoliomanagement zou willen inrichten. Nu gaat het om de ‘hoe’-vraag.

Het inrichten van Agile portfoliomanagement is een verandering van denken en doen van de betrokkenen in de organisatie. En realisatie van verandering kost energie en tijd. Om die reden is het belangrijk om eerst te experimenteren met het bijbehorende proces en ieders rol in dat proces voordat een grootse inrichting plaats vindt.

Een laagdrempelige manier om kleinschalig te experimenteren met Agile portfoliomanagement is gebruik te maken van het gedachtegoed van Roman Pichler. Met behulp van een aantal, per fase te gebruiken, overzichten is een duidelijk inzicht te krijgen in de uitwerking van een idee naar concrete acties voor de betrokkenen.

Het experiment kan volledig op papier plaats vinden waardoor je zelf kan bepalen wie, wat en wanneer moet doen en vooral hoe samen te werken. Die vrijheid prikkelt het denken waardoor het begrip voor de inrichting van Agile portfoliomanagement zal groeien. Waarom bepaalde activiteiten uitgevoerd moeten worden en informatie moet worden vastgelegd is in deze fase belangrijk. Het bereidt de organisatie voor op de vervolgstap, het inrichten van ondersteunende tooling.

Het beantwoorden van de hoe-vraag kan op vele manieren, je hoeft maar een zoekopdracht in te typen en de methodieken en tooling vliegt om je oren. Ik geloof echter dat de hoe vooral moet worden bepaald door de organisatie en dat een laagdrempelig experiment bijdraagt aan een goede fundering voor het vervolg.

In mijn volgende blog ga ik in op de ‘wat’-vraag rondom de eerdergenoemde overzichten. Wat leg je vast per overzicht en hoe past deze in een voorbeeldproces.


Interesse? We praten graag met je verder!

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Kjell Korfage.

Waarom zou je Agile portfolio management willen inrichten? 

Waarom zou je Agile portfolio management willen inrichten?

Allereerst een wedervraag. Wat motiveert jou meer in je werk, het uitvoeren van hele specifieke taken omdat iemand je vertelt dat het moet gebeuren óf zelf de juiste taken bedenken en uitvoeren omdat je weet dat het bijdraagt aan de doelen en het gewenste resultaat van je organisatie?

Zelfsturende organisaties moeten het per definitie niet hebben van directief leiding geven. Hoe krijgt men dan toch de verbinding tussen visie, ideeën en resultaat? Hoe weet men door alle organisatie onderdelen heen wat hun deel is in het geheel? Agile portfoliomanagement is een middel om dit te bereiken.

Agile portfoliomanagement beantwoord de vraag hoe de diverse rollen in een Agile organisatie met elkaar moeten samenwerken en welke informatie met elkaar gedeeld moet worden om een business idee uit te werken, te realiseren en te verbeteren.

Agile portfoliomanagement biedt methoden voor mensen, processen en technieken die nodig zijn om een verbinding te leggen tussen strategie, investeringen, doelen, realisatie, productie en de sturing.

Hoe kan Agile portfoliomanagement ingericht worden? In een volgend blog ga ik hier op in.


Interesse? We praten graag met je verder!

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Marleen Kleijn.

Automatisering in Jira Cloud

Automatisering in Jira Cloud

“Wat een werk om dit steeds aan te maken”, “Ik vergeet dit steeds”, “Waarom kan dit niet automatisch?” Zo maar een aantal vragen die ik mij vaker stelde bij het gebruik van Jira.
Sinds de introductie van automation in Jira Cloud is het mogelijk om bepaalde handelingen te automatiseren, wat ervoor zorgt dat je zelf meer tijd overhoudt! Kenners denken nu vast; “Maar Richard, automation is toch al langer beschikbaar voor Jira in de vorm van Automation for Jira op de server en cloud app versie?” Klopt! Automation for Jira behoorde eerst tot het bedrijf Code Barrel, dat het ontwikkelde onder de naam Automation for Jira Cloud app en in 2019 is overgenomen door Atlassian. Sindsdien heeft Atlassian hard gewerkt om de functionaliteiten te integreren in de native Jira Cloud versie waardoor nu iedere Jira Cloud gebruiker toegang tot automation heeft zonder apps te installeren. In deze blog zal ik jullie een kijkje bieden in Jira Automation voor Cloud!

Jira Cloud

Sinds maart 2020 is no-code automation beschikbaar in Jira Cloud voor iedere Cloud gebruiker. Voor verschillende use-cases zijn er mogelijkheden om automatisering toe te passen, enkele voorbeelden:

  • Creëer automatisch een sub-task wanneer een task wordt aangemaakt.
  • Wanneer je laatste sub-task gesloten wordt, sluit dan ook meteen de parent task.
  • Wanneer een bug is opgelost in een gereleasde versie, stuur een bericht naar geselecteerde personen.
  • Wanneer een klant een issue aanmaakt in Jira Service Desk, clone het issue in Jira Software en assign het aan een developer.

Binnen de automation module zijn er twee verschillende groepen: single-project en global & multi-project automation. Single-project automation rules zijn automatiseringsregels die betrekking hebben op één project; terwijl global & multi-project rules (zoals de naam het al zegt) van toepassing zijn op Jira in zijn geheel of op meerdere projecten specifiek.
Maakt dit iets uit als ik automatiseringsregels ga aanmaken? Ja! Jira kijkt naar welke abonnement je gebruikt. Zo heb je voor Jira Cloud Standaard de mogelijkheid om 500 rules per maand uit te voeren, voor Jira Cloud Premium geldt een limiet van 1000 rules per betalende gebruiker per maand. Om het ingewikkelder te maken, tellen single-project automation rules niet mee voor je limiet en zijn cross-product Issue creatie rules ook uitgezonderd voor de limiet (Bijvoorbeeld een bij het aanmaken van taak A in project X, wordt ook een taak B in project Y aangemaakt).

Een “Execution” is iedere keer dat een rule uitgevoerd wordt. Als je bijvoorbeeld een rule hebt die uitgevoerd wordt over alle projecten van Jira, waarbij iedere keer een comment wordt geplaatst bij het wijzigen van de status, dan kan het al aardig oplopen.

Rules

Rules zijn gebaseerd op drie elementen: Triggers, Conditions en Actions.
Een trigger is een element die de start van een rule initieert. Bijvoorbeeld een ticket die aangemaakt wordt, of het plaatsen van een comment. Conditions zorgen ervoor dat je rule beperkt wordt tot bepaalde voorwaarden. Zo kan je bepalen dat alleen comments waarin een naam van een specifiek persoon voorkomt de rule activeert. Als laatste komen we op actions. Actions bepalen wat de rule uitvoert, zoals het aanmaken of bewerken van een ticket of een notificatie sturen.

Deze elementen gecombineerd zorgen ervoor dat je rule uitgevoerd wordt. Het Automation rules overzicht in Jira biedt een samenvatting van de rules waarbij je bijvoorbeeld kan aangeven of je notificatie wilt krijgen als een rule niet uitgevoerd kan worden, of andere rules deze rule kunnen activeren en of het voor een enkel project geldt, meerdere, of een globale rule is. In het bijbehorende audit log kan je de status bijhouden van iedere keer dat de rule is uitgevoerd.

Mocht je je rules verder willen aanpassen, dan is dat mogelijk met zogenoemde smart values. Met smart values kan je bijvoorbeeld een comment door een rule laten toevoegen met specifieke data, zoals {{issue.summary}} de samenvatting van een ticket laat zien en {{reporter.displayName}} de naam van de reporter. Zo kan je je eigen combinaties maken.

Automatiseer slim!

Automation in Jira biedt gebruikers (met admin rechten) mogelijkheden om repeterende taken en vele handmatige handelingen te automatiseren in enkele klikken om zodoende tijd en energie vrij te maken voor andere zaken. Kijk goed naar elementen die repeterend en generiek van aard zijn bij het gebruik van Jira en probeer dat te automatiseren waar mogelijk.

Wil je advies over automation in Jira, of in Jira in het algemeen? Neem dan contact met ons op!


Interesse? We praten graag met je verder!

Heb je een vraag of wil je met ons sparren? Neem gerust contact op met Marleen Kleijn.