Toegevoegde waarde is complex

Slim werken is zo veel mogelijk bereiken met zo weinig mogelijk moeite. Simpel, maar niet makkelijk. Het is steeds moeilijker om een slim en perfect plan te maken. In plaats daarvan, zegt Agile, maak je beter een goed genoeg plan. Vervolgens begin je zo snel mogelijk. Het is namelijk jammer om veel tijd te besteden aan plannen als het plan waarschijnlijk binnenkort verandert.

Die eerste stap is namelijk goud. Hoe sneller hoe beter. Met een beetje geluk heb je al iets waardevols gedaan met weinig moeite. In het slechtste geval heb je van de harde realiteit geleerd. Je weet nu hoe je slimmer kunt werken, én wat waarde is voor jou. Bovendien komt er altijd iemand met nieuwe eisen op de proppen. Hoe eerder je deze ontdekt, hoe minder tijd je verspilt aan de verkeerde aanpak.

Agile is frequent bijsturen naar meer waarde

Na elke kleine stap stuur je weer bij. Hoe vaker je bijstuurt, hoe minder hard je hoeft te sturen. Meer waarde, minder moeite. Gewoon slim werken. Als je behendig en frequent kunt bijsturen, ben je wendbaar, oftewel “Agile”.

Vaak wordt Agile verward met flexibiliteit. Hierdoor denken veel mensen dat het betekent dat je geen afspraken kunt maken en dat alles flexibel moet blijven. Maar het tegenovergestelde is waar. Flexibiliteit is slechts een middel om effectiever je doelen te bereiken. Afspraken maken en een duidelijke koers aanhouden helpen vaak om sneller resultaten te behalen. In onvoorspelbare omgevingen zijn flexibiliteit en behendigheid vooral belangrijk als je iets nieuws leert. Maar dat betekent niet dat je je huiswerk niet meer hoeft te doen.

Agile is mensenwerk!

Misschien nog het belangrijkst van allemaal in onvoorspelbare omgevingen zijn mensen. Agile erkent dat het realiseren van toegevoegde waarde mensenwerk is. Diversiteit, verschillende perspectieven en onderlinge interactie spelen een belangrijke rol bij het oplossen van complexe vraagstukken. Processen en tools zijn belangrijk om gewoon slim te werken, maar mogen geen keurslijf worden.

Een plan als hulpmiddel, geen controlemiddel

Een voorbeeld van ondersteuning en keurslijf: het plan. Het plan is ondersteuning om je werk slim in te richten. Het is waardevol als het helpt bij onderlinge afstemming en om zaken efficiënt en snel voor elkaar te krijgen. Maar als het plan de overhand krijgt – het werkt als keurslijf – verlies je de toegevoegde waarde uit het oog. Dit gebeurt bijvoorbeeld als iemand het plan gebruikt als controlemiddel.

Het Agile Manifesto: de essentie van Agile

De uitgangspunten van Agile werken zijn vastgelegd in het Agile Manifesto. Hoewel het oorspronkelijk is geschreven door softwareontwikkelaars, is het ook relevant voor een bredere groep mensen. Hieronder vind je een vertaling naar het Nederlands en een bredere context dan alleen software. Het Agile Manifesto bevat de volgende vier statements:

• Processen en tools zijn ondersteunend aan individuen en hun onderlinge interactie, niet andersom.
• Kennis en documentatie zijn waardevol, maar ondergeschikt aan het werkelijk leveren van toegevoegde waarde, bijvoorbeeld werkende producten of diensten.
• Heldere afspraken – contracten – zijn belangrijk, maar ze mogen samenwerking met collega’s, leveranciers en klanten niet in de weg staan.
• Planmatig werken is wel zo efficiënt, zo lang het je maar niet verhindert om in te spelen op verandering.

De vijfde hoeksteen van Agile: werken met feiten

Helaas is in het Agile Manifest een belangrijke hoeksteen van Agile onderbelicht gebleven: het empirisme. Empirisme betekent dat je kennis en beslissingen baseert op waarneembare feiten, niet op meningen of aannames. Het werken met data en feiten speelt een belangrijke rol in onze succesvolle aanpak. Daarom kun je een vijfde statement maken:

• Meningen en aannames geven richting, maar ze mogen je niet verblinden voor de waarneembare feiten.

Ook gewoon slimmer werken?

Als je wilt ontdekken wat Agile voor jouw team of organisatie kan betekenen, neem dan gerust contact op. Je kunt ook het boek “Sturen op Resultaat” lezen, waarin handvatten worden gegeven om de bovenstaande statements in de praktijk te brengen. Het is een bewezen aanpak om veel toegevoegde waarde te creëren voor je organisatie en haar klanten.

The post Wat is Agile precies? appeared first on Anton Vanhoucke.

Waarom zijn regelmatige Retrospectives belangrijk?

Frequente Retrospective zorgen ervoor dat je verbeterideeën direct kan toepassen. Dat is beter dan één grote projectevaluatie aan het eind. De crux is om van retrospectieven een regelmatige gewoonte te maken – een integraal onderdeel van je werk in plaats van een moetje. Met de problemen nog vers in het geheugen kun je ze betere analyseren en verhelpen. Bovendien verhoogt ook het moreel van het team door leden de mogelijkheid te geven om regelmatig hun inzichten te uiten.

Hoe houd je een Sprint Retrospective in minder dan 30 minuten?

Hier is hoe je een effectieve sprint retrospectieve kunt uitvoeren in vijf eenvoudige stappen. Zorg ervoor dat je een timer gebruikt – de tijd vliegt als je aan het scrummen bent.

1. Zet de toon (2 minuten)
   De eerste stap op je retrospectieve agenda is het creëren van een omgeving waar iedereen zich comfortabel voelt. Moedig openheid aan en herinner deelnemers eraan dat de resultaten van de sessie direct hun werktevredenheid zullen ten goede komen.
2. Verzamel feiten (3 minuten)
   Sta teamleden toe om stil te reflecteren op de gebeurtenissen van de sprint. Sommige teams reflecteren op hun burndown of continuous flow diagram. Andere teams noteren gedachten op sticky notes of gebruiken digitale tools voor remote teams. Als je ervoor kiest om aantekeningen te maken, is het handig om de retrospectieve voor te bereiden met onderwerpen. Mijn favoriete onderwerpen zijn de acht items op het agile manifest. Je kan ook reflecteren op de scrum waarden – openheid, moed, respect, toewijding, focus – of de drie elementen uit Daniel Pink’s Drive.
   Het doel hier is om diverse individuele perspectieven op te halen, zonder beïnvloeding van anderen. Onthoud dat emoties ook gegevens zijn. Houd het niet te cognitief. Je kunt rondgaan met vragen als: Hoe tevreden voel je je? Wat zijn momenten van lage en hoge vreugde? Hoe was je energieniveau?
3. Verzamel perspectieven en oplossingen (15 minuten) Groepeer de verzamelde gegevens in onderwerpen en begin met het belangrijkste onderwerp. Faciliteer een open discussie gericht op zowel positieve resultaten als verbeterpunten. Moedig deelnemers aan om hun observaties uit de vorige stap te delen. Dat bevordert een evenwichtig gesprek over zowel successen als uitdagingen. Deze dialoog kan beter gericht zijn op het onthullen van de oorzaken en het gezamenlijk brainstormen over potentiële oplossingen.

4. Prioriteer acties (5 minuten)
   Als er meerdere acties voortvloeien uit de discussie, prioriteer deze dan op basis van impact en haalbaarheid. Dit zorgt ervoor dat je focus houdt en de belangrijkste dingen eerst verbetert.
5. Sluit af (5 minuten)
   Sluit af door te reflecteren op de kwaliteit van de retrospectieve zelf – wat werkte er goed in deze sessie? Wat kan er de volgende keer verbeteren? Tot slot, bedank alle deelnemers voor hun bijdragen en versterk zo een cultuur van waardering en continu leren.

Bonus praktische online tools voor je retrospectieve agenda

Als je geen face-to-face retrospectieven kunt houden, raad ik aan een virtueel whiteboard te gebruiken. Miro is mijn favoriet omdat deze tool het intuïtiefst aanvoelt. Wanneer je in een Microsoftomgeving werkt, kan Azure Devops ook observaties vastleggen met een extensie. Ik heb ook geëxperimenteerd met een Loop in een MS Teams-kanaal.

Hier is een retrospectieve uitnodiging die je kunt kopiëren en aanpassen:

Hoi Team,

Laten we 30 minuten nemen om terug te kijken op de afgelopen weken en bekijken hoe we ons werk leuker en aangenamer kunnen maken. Laat het me weten als je specifieke onderwerpen hebt die je wilt bespreken.

Hier is onze agenda voor de retrospectieve:

1. Welkom, doel en structuur - 2 min.
2. Verzamel de feiten - 3 min.
3. Bespreek situatie en acties - 15 min.
4. Prioriteer acties - 5 min.
5. Afsluiting - 5 min.

Tot dan! Je Scrum Master.

Door deze gestroomlijnde aanpak voor sprint retrospectieven te gebruiken bespaar je niet alleen tijd. Je investeert ook in de groei en efficiëntie van je team. Regelmatig geplande retrospectieven gaan over het vieren van successen en het constructief aanpakken van uitdagingen. Dat is een recept voor blijvend succes in elke agile omgeving.

Zin om het ook te gaan doen? Je zult zien hoe de productiviteit van je team stijgt! Als je nog steeds het gevoel hebt dat het echte gesprek ontbreekt in retrospectieven, neem dan contact met me op. De neutrale grond van een externe persoon zoals ik kan het betere gesprek op gang brengen.

The post Een handige retrospective agenda van 30 minuten appeared first on Anton Vanhoucke.

Hoe kijk je de Draak in de Ogen?

Stel je angst voor als een draak die een schatkist met potentieel en groei bewaakt. Door deze draak te confronteren, kun je groeien en kansen vinden. Mario Andretti, een legendarische racecoureur, zei ooit: “Als alles onder controle lijkt, ga je gewoon niet snel genoeg.” Dit betekent dat echte vooruitgang meestal buiten je comfortzone ligt. Buiten je comfortzone treden gaat makkelijker met persoonlijke bescherming. Bij draken helpt een harnas. Maar niet alle harnassen werken even goed. Lees verder om te ontdekken hoe je je kunt beschermen!

Wat is een goed Harnas om Product Owner-angst aan te pakken?

Een paar weken geleden was ik bij een interview met Brené Brown. Ze sprak over omgaan met angst en het soort harnas dat je aantrekt. Sommige harnassen isoleren ons, terwijl andere ons in staat stellen om samen risico’s te nemen. Ik vond haar lijst harnassen heel herkenbaar. Hieronder een paar persoonlijke voorbeelden uit mijn praktijk als coach voor Product Owners.

Allesweter vs. dapper leren harnas

De bepantserde allesweter vindt het belangrijker om gelijk te hebben dan om te leren. Maar dat leidt tot starheid en gemiste kansen. Ik heb Product Owners ontmoet die er zo van overtuigd waren dat ze alles moesten weten dat ze overspannen werden. Hulp vragen, daar dachten ze niet aan. Misschien werden ze dan wel ontmasker als niet alwetend! Met coaching konden we de overgang maken van een allesweter harnas naar een ‘dapper leren’ harnas. We werkten aan het omarmen van nieuwsgierigheid en het durven vragen om hulp. Het nieuwe harnas werkt erg goed in hun Agile team, omdat het het intellect en hulpvaardigheid van het hele team aanspreekt. Een Product Owner merkte op: “Ik heb ontdekt dat de juiste vragen belangrijker zijn dan de juiste antwoorden.”

Wij-Zij harnas vs. Multi-waarheid harnas

Een ‘wij-zij’-harnas creëert veiligheid door mensen met moeilijke meningen in een inferieure groep te plaatsen. Dit verdeelt teams. Ik ben mensen tegengekomen die collega’s vermijden. Ze concentreerden zich op persoonlijke taken om moeilijke gesprekken uit de weg te gaan. Een persoon die ik coachte, bijvoorbeeld, vermeed haar team door al het configuratiewerk van tools te claimen. Ze pantserde zich door haar domein af te bakenen. Ze hoopte te bewijzen aan ‘de hardwerkende mensen’ dat ze geweldig werk leverde, en dat ze niet een van de ‘slackers’ was. De broeiende wrok ontaarde in een destructief conflicten. Het streste iedereen. Ook hier heb ik met het team gewerkt aan een harnaswissel. We hebben een nieuw harnas gebouwd door meningen los te koppelen van identiteit. De nieuwe ruimte voor complexiteit maakte het mogelijk dat verschillende waarheden harmonieus naast elkaar bestaan.

Schaamte en schuld vs. Gedeelde Verantwoordelijkheid

Schaamte en schuld is een effectieve manier om ervoor te zorgen dat fouten jou niet aangerekend kunnen worden. Het onderdrukt echter creativiteit en innovatie binnen teams. In mijn LEGO Scrum-simulaties, bijvoorbeeld, maken teams meestal fouten. Dat is de bedoeling. Toch kijkt vraagt ​​iemand mij soms om de schuldige aan te wijzen.

Ik vind het geweldig als dat gebeurt, omdat het een leerkans creëert. Het stelt me in staat om het harnas van gedeelde verantwoordelijkheid in de praktijk te laten zien: ik wijs erop dat we er allemaal bij waren toen het misging. Schaamte en verwijten zijn zinloos. Wat telt, is de fout corrigeren en ervoor zorgen dat deze zich niet herhaalt. Ik hoop dat Product Owners in mijn training van deze ervaring leren. Ik hoop dat alle teamleiders zich beschermen met compassie en gedeelde verantwoordelijkheid. Ze bouwen ze een omgeving waarin risico’s worden aangemoedigd.

Hoe word je een onbevreesde Product Owner?

Gedijen als Product Owner betekent verstandig kiezen van je persoonlijke beschermen: omarm leren, ga openhartig de confrontatie aan en bevorder gedeelde verantwoordelijkheid binnen je team. Het is oké om angst te voelen, want je nieuwe harnas beschermt je. Het stelt je in staat om de draak van angst samen met je team onder ogen te zien.

Als je je aanpak als Product Owner wil transformeren tot een aanpak vol zelfvertrouwen en dapper leiderschap, overweeg dan een paar coachingsessies met Anton.

The post Product Owners mogen Angst voelen appeared first on Anton Vanhoucke.

De drie onderdelen van een heldere rol

Je beschrijft een rol binnen een team het best aan de hand van drie elementen: de bestaansreden, het mandaat en de verantwoordelijkheid. De bestaansreden formuleer je als een volzin. Dit is een handige pitch waarmee je kort uitlegt waarom de rol essentieel is voor je organisatie. Als je meer tijd hebt, geven het mandaat en de verantwoordelijkheid verdieping en verheldering. Het mandaat omvat de lijst van zaken waarover je mag beslissen. De verantwoordelijkheid betreft datgene waarop mensen je kunnen aanspreken: het resultaat van goede beslissingen. Deze twee elementen zijn nauw verbonden. Zo kunnen mensen mij aanspreken op de focus van een workshop. Blijven we bij de kern of dwalen we af? Hiervoor heb ik wel het mandaat nodig om in te grijpen als ik merk dat we afdwalen.

Psychologische Veiligheid vergroten door rollen aan behoeften te koppelen

Een sterke behoefte aan duidelijke roldefinities wijst vaak op een lage psychologische veiligheid binnen een team. Dit is begrijpelijk, want onzekerheid over je positie en verwachtingen van anderen kan maken dat je voorzichtig wordt. Je kunt daarom bij de roldefinities verder gaan dan bestaansreden, mandaat en verantwoordelijkheid: denk ook actief na over hoe je elkaar ondersteunt. Meer ondersteuning leidt tot meer psychologische veiligheid. De benodigde steun verschilt per rol, en ik laat mensen daarom met elkaar in gesprek gaan over hun behoeften. De uitkomst van dat gesprek schrijf je bij de roldefinitie onder het kopje behoeften. Tip: zorg ervoor dat behoeften van de ene rol geborgd zijn in de verantwoordelijkheden van de andere rol. Zo weet iedereen waar ze steun kunnen zoeken. Als mensen zich gesteund voelen, vullen ze hun rollen effectiever in.

Voorbeelden van rolbeschrijvingen

Omdat de roldefinities hierboven wat abstract zijn, geef ik hieronder twee voorbeelden: een Scrum Master en een ouder/verzorger. Kun je de beschrijving van die rollen niet gewoon opzoeken via Google? Mogelijk, maar waar het om gaat, is dat je ze definieert voor jouw situatie. De Scrum Guide zegt expliciet dat de rolbeschrijvingen niet volledig zijn, maar dat je ze uitbreidt met de beschrijvingen die nodig zijn voor jou. Zou hou je het lekker simpel. De voorbeelden hieronder zijn dus onvolledig en ze zijn mijn eigen interpretaties.

Voorbeeld 1: Scrum Master

Bestaansreden

Continue verbetering organiseren zodat de Scrum Master uiteindelijk overbodig wordt.

Mandaat

• Coachen
• Uitleg geven over Scrum en wendbaarheid
• Faciliteren

Verantwoordelijkheid

• Vergroting van de wendbaarheid
• Verbetering van de effectiviteit van de Scrum events
• Groeiend begrip van empirisch werken

Behoeften

• Tijd en ruimte om te coachen en faciliteren
• Afstemming met de Product Owner over prioriteiten

Voorbeeld 2: Ouder/verzorger

Bestaansreden

Een veilige basis bieden voor de kinderen om van daaruit te groeien, te leren en de wereld te verkennen, zodat ze uitgroeien tot succesvolle, zelfstandige individuen.

Mandaat

• Huisregels opstellen (in overleg met partner)
• Huishoudgeld besteden

Verantwoordelijkheden

• Gedrag van de kinderen verbeteren
• In fysieke behoeften voorzien (kleding, eten, bed, etc.)
• In mentale behoeften voorzien (verbinding, veiligheid, uitdaging, etc.)
• Toegankelijk zijn

Behoeften

• Ondersteuning van partner en familie
• Tijd voor zichzelf om te ontspannen en op te laden

Aanpak van de Workshop over Rollen en verantwoordelijkheden

Tijdens de workshop start je met een probleemanalyse om onduidelijkheden bloot te leggen. Vraag je af welke belangrijke problemen je wilt oplossen door de rollen duidelijker te maken. De uitkomst van dit onderdeel vormt de basis voor verbeterde rolbeschrijvingen. Over rollen kun je lang discussiëren. Om het effectief te houden, werk je in kleine groepjes waarin iedereen zijn eigen rol definieert. Dit bevordert niet alleen begrip, maar ook betrokkenheid binnen het team. Streef tenslotte niet naar perfectie, maar rond de workshop af met een experiment. Hoe introduceer je de nieuwe roldefinities in de praktijk? Hoe weet je dat er verbetering optreedt? Kleine stappen vooruit kunnen grote verschillen teweegbrengen in hoe teamleden samenwerken. Bij holacratie is het gesprek over rollen iets wat regelmatig terugkomt.

Een Externe Begeleider voor de workshop rollen en verantwoordelijkheden

Het organiseren van zo’n workshop is vaak productiever met hulp van een neutrale, externe begeleider. Een externe facilitator maakt het makkelijker om gevoelige kwesties bespreekbaar te maken zonder dat mensen zich persoonlijk aangevallen voelen. Vraag dus een Scrum Master, iemand van HR die vertrouwt of neem contact op met mij. Hoe sneller je de dynamiek binnen jouw team verbetert, hoe eerder je er baat bij hebt!

The post Workshop Rollen en Verantwoordelijkheden: zo maak je het helder appeared first on Anton Vanhoucke.

Vind je deze lijst te lang om te lezen? Ik kan jou en je team ook komen trainen in het onderwerp. Dat is een stuk minder droog, want je maakt dan echt mee hoe het is om te Scrummen.

A

Agile: Agile is de filosofie achter het Scrum Framework. Scrum is Agile, maar Agile is niet altijd Scrum. Net zoals een mus een vogel is, maar niet alle vogels mussen zijn. Veel mensen vertalen Agile als wendbaarheid. Je kunt Agile ook letterlijk vertalen als behendig. Die vertaling is accurater, want Agile gaat over meer waarde toevoegen met steeds minder moeite. Behendiger waarde toevoegen dus. De essentie is mooi beschreven in het Agile Manifest.

B

Burn-down Chart: een grafiek die de hoeveelheid werk laat zien die naar verwachting nog overblijft. Deze grafiek is behulpzaam als je een plan maakt voor het werk in de resterende tijd die je nog hebt. Tijd staat op de horizontale as en het resterende werk op de verticale as. Naarmate de tijd verstrijkt en werk af is, daalt de lijn die het resterende werk laat zien. Begint iemand over een Burn-down Chart, dan kun je vragen:

• Staan er bij jullie story points of uren op de verticale as?
• Heeft de curve in jullie Burn-down Chart wel vaker deze vorm?

Burn-up Chart: een grafiek die de hoeveelheid voltooid werk laat zien en een trendlijn toont waarmee je kan inschatten welk werk wanneer af gaat zijn. Tijd staat op de horizontale as en voltooid werk op de verticale as. Henrik Kniberg heeft een mooie uitleg over de Burn-up. Slimme vragen die je kan stellen:

• Hoe haal jij je forecast uit je Burn-up?
• Laat je je Burn-up chart zien bij elke sprint review?

D

Daily Scrum: De Ontwikkelaars steken elke dag van de Sprint de koppen bij elkaar in Daily Scrum. In dit kwartiertje plannen de Ontwikkelaars het werk voor de komende 24 uur. Het gesprek over tactiek om het Sprint Goal te halen verbetert de samenwerking en prestaties van het team. Ervaren scrummers korten Daily Scrum af tot de Daily. Vraag eens:

• Wat is de regelmaat van jullie je Daily?
• Waar houden jullie je Daily?
• Hoe werkte de Daily in je LEGO scrum simulatie?

Definition of Done: De Definition of Done (DoD) beschrijft de kwaliteitseisen voor het product en alles wat je toevoegt. Het zijn afspraken die borgen dat toevoegingen aan je product waardevol zijn en aansluiten bij wat al bestaat. Toevoegingen zijn dus pas echt af als ze aan deze definitie voldoen. De DoD bevordert transparantie door iedereen een helder kader te geven van wat geldt als voltooid werk. Je komt professioneel over wanneer je de term ‘Definition of Done’ afkort tot ‘DoD’ (Die, oh die!). Dan kun je bijvoorbeeld vragen:

• Welke regressietests omvat jullie DoD?
• Welk bedrijfsbeleid is relevant voor jullie DoD?

Developer: Een professional die zich inzet om bruikbare, kwalitatieve toevoegingen aan het product te maken. Deze ontwikkelaar ontwikkelt bijvoorbeeld marketingstrategieën, code, functionaliteit, designs of diensten. Multidisciplinaire teams zijn zelfstandiger, met minder afhankelijkheden, dus je kan vragen:

• Hoe makkelijk kunnen developers werk van elkaar overnemen in jullie team?

E

Emergence: Dit is het proces waarbij inzichten over een feit ontstaan, vaak op onverwachte wijze. We hebben het ook soms over voortschrijdend inzicht.

• Hoe gaan jullie om met voortschrijdend inzicht van de directie?

Empiricism: Empirisme is de filosofische opvatting dat kennis voortvloeit uit ervaring en observatie. Deze benadering vormt een fundament van de wetenschappelijke methode en is de basis voor hedendaagse wetenschap en geneeskunde. Binnen Scrum duidt empirisme op het idee dat het aanpakken van ingewikkelde problemen vraagt om experimenteren, in plaats van vastomlijnde plannen. Doorwinterde scrummers vragen:

• Welke empirische klantgegevens gebruiken jullie om je prioriteiten bij te stellen?

F

Forecast (of functionality): De forecast geeft vaak aan welke werkpakketten het team kan uitvoeren binnen de tijdsduur van een enkele sprint. De voorspelling kan ook gaan over toekomstige sprints en een indicatie geven van het tijdsbestek waarbinnen het team het werk afrondt.

• Wat bedoel je precies met forecast, in dit geval?

I

Increment: Scrum teams maken hun product waardevoller in sprints. De toegevoegde waarde uit een sprint is het increment. Alle increments samen vormen een product. Kenners weten dat het increment één van de drie artefacts is. Dus zonder met je ogen te knipperen kun je vragen:

• Welke artefacts bespreken jullie in je sprint review?

P

Product: Alles wat het team voortgebracht heeft. Dit kan een letterlijk product zijn, een dienst of elk ander resultaat met bedrijfswaarde.

Product Backlog: Deze geordende lijst bevat van het werk dat nodig is om een product te ontwikkelen en te onderhouden. Het werk bovenaan de lijst doe je eerst.

• Hoe ver vooruit is jullie Product Backlog gevuld?

Product Backlog Refinement: Dit is de activiteit waarbij je verfijning aanbrengt in het toekomstige werk. Je maakt het werk letterlijk en figuurlijk fijner. Letterlijk door het op te splitsen in kleinere waardevolle werkpakketten, en figuurlijk door samen oplossingsroutes te verzinnen. Daarbij richt je je vooral op het werk voor de komende paar sprints.

• Hoe organiseren jullie backlog refinement?

Product Owner: Rol in het Scrum-team die verantwoordelijk is voor het maximaliseren van de waarde van het product, en dat doet door prioriteiten te stellen. Je kan het ook een value maximizer noemen.

• Product owner klinkt als een zware verantwoordelijkheid. Krijgt zo iemand coaching of ondersteuning bij jullie?

Product Goal: Het productdoel schetst een toekomstige staat van het product en geeft richting aan het Scrum Team. Het OPME-Canvas is een mooie manier om het product goal bondig samen te vatten.

• Op welke manier hebben jullie het product goal transparant gemaakt? Met een canvas?

R

Refinement: zie Product Backlog Refinement

S

Scaled Scrum / Scaled Agile: Samenwerken in een organisatie met twee tot honderd Scrum of Agile Teams. Je hebt dan meer afstemming nodig. Veelgebruikte aanpakken om wendbaarheid op te schalen zijn LeSS, SAFe, Nexus of Sturen op Resultaat. Dat is met een goede vraag:

• Welk Scaled Agile Framework gebruiken jullie?

Scrum: Scrum is een opzettelijk onvolledige aanpak – een framework – dat mensen, teams en organisaties helpt waarde te genereren door complexe problemen op te lossen.

• Hoe hebben jullie het Scrum framework ingevuld?
• Wat maakt jullie uitdaging complex?
• Wie heeft jullie scrum training op locatie verzorgd?

Scrum Board: Dit bord visualiseert informatie voor en door het Scrum-team. Je kan het werk voor de huidige sprint er op zien en meestal ook de voortgang, toekomstig werk, de belangrijkste doelstelling, en de aanwezigheid van teamleden.

• Heb je toevallig een foto van jullie scrum board? Ik ben heel benieuwd wat er bij jullie allemaal op staat!

Scrum Master: Rol binnen een Scrum Team die verantwoordelijk is voor het begeleiden, coachen, onderwijzen en bijstaan van een Scrum Team en zijn omgeving. Het is de rol die Master Yoda heeft in Star Wars.

• Wat vind jij de grootste toegevoegde waarde van de Scrum Master?

Scrum Team: Dit is het team dat Scrumt. Het is een team bestaande uit één Scrum Master, één Product Owner en meerdere Ontwikkelaars. Meestal is zo’n team tussen de drie en 10 personen. Een kleiner team is wendbaarder.

• Hebben sommige mensen in jullie team meerdere rollen?

Scrum Values: De Values zijn een set fundamentele waarden en kwaliteiten die ten grondslag liggen aan Scrum. Het zijn Commitment, Focus, Openness, Respect en Courage. Dus toewijding, focus, openheid, respect en moed.

• Doen jullie wel eens een retrospective met de Scrum Values?

Self-managing team: Een zelfsturend team beslist wie wat, wanneer en hoe doet. Het team stuurt ook bij richting de doelstellingen. Een zelfsturend team kiest niet zijn eigen doelstellingen – dat is een zelfbesturend team.

Sprint: De sprint is de container voor all Scrum activiteiten. Direct na het aflopen van de sprint start een nieuwe sprint. Het lijkt op een klein project met een doel, een plan, een eindoplevering en een evaluatie.

Sprint Backlog: Het overzicht van het werk van één Sprint. Het is meestal een voorspelling van functionaliteit en het werk dat nodig is om die functionaliteit te leveren. Kenners weten dat dit een artefact is.

• Beheren de Developers de Sprint Backlog bij jullie, volgens het boekje?

Sprint Goal: Een beknopte omschrijving van het doel van een Sprint, vaak een zakelijk probleem.

• Wat is jullie huidige sprint goal ?

Sprint Planning: Elke sprint start met een planning, waarbij het Scrum Team bepaalt wat het waardevolst is om in de komende sprint te doen.
Kenners weten dat hier een sprint goal uit voorkomt, en een sprint backlog. Je kan overkomen als een kenner met deze moeilijke vragen:

• Redden jullie het om binnen de timebox een forecast te maken voor de functionaliteit van de komende sprint?
• Hoelang duurt jullie sprint planning? Veel minder dan 8 uur hoop ik!

Sprint Retrospective: Het team gebruikt deze tijd om de voorbije sprint te evalueren en verbeteringen te plannen voor de komende Sprints. Het is het allerlaatste onderdeel van de Sprint. Kenners korten het af tot ‘Retro.’ Vraag dus:

• Kan jij je ei wel kwijt in de retro? Waarom?

Sprint Review: Tijdens dit kijkje in de keuken beoordelen de belanghebbenden en het team samen de toegevoegde waarde van de sprint. Als je de metafoor doortrekt, proeven ze welke gerechten er al zijn en bekijken ze wat er nog op het menu staat. Ze bespreken de voortgang werken hun plan bij voor de komende periode.

• Vertel eens, waar was je trots op tijdens de laatste sprint review?
• Hoeveel voortgang heb je gemaakt richting je product goal?
• Hoe trots was je tijdens de sprint review van de LEGO scrum game?

Stakeholder: Een belanghebbende is iemand buiten het Scrum Team die een specifiek belang en kennis van een product heeft. Die persoon sluit af en toe aan, of de Product Owner vertegenwoordigt deze persoon.

• Welke stakeholders hebben jullie bij de Sprint Review?

T

Technical Debt: Suboptimale keuzes die zorgen dat extra inspanning nodig is – vaak onverwacht – voor het onderhouden en doorontwikkelen van een product. Er zijn dan bijvoorbeeld incidenten bij gebruikers en het Scrum team verliest tijd met het oplossen daarvan. Kenners weten dat technical debt bijdraagt aan de total cost of ownership (TCO). Vraag dus:

• Hoe hard weegt jullie tech debt door in je TCO?

Values: Zie Scrum Values

Velocity: De velocity is de snelheid waarmee je toegevoegde waarde weet te produceren. Kenners noemen dit ook wel: een optionele indicatie van de hoeveelheid werk uit de Product Backlog die een Scrum Team omzet in een product increment tijdens een Sprint. Ontwikkelaars houden dit bij voor zelfsturing. Combineer al deze termen in een moeilijke vraag, en knijp lichtjes je ogen dicht terwijl je die vraag stelt. Niemand zal je nog aanzien voor een beginner!

The post Verklarende woordenlijst met de betekenis van Scrum Termen appeared first on Anton Vanhoucke.

Holacracy betekent dat het hele team de leiding heeft, niet alleen de manager. In essentie is Holacracy een proces om zelfsturing en zelforganisatie in teams te organiseren. Zelforganiserende kenniswerkers blijken productiever te zijn dan beheerde kenniswerkers. Ik deed onderzoek naar Holocracy met als doel nieuwe inzichten te ontdekken voor het bouwen van zelforganiserende teams.

Getting Teams Done

Ik baseerde mijn onderzoek vooral op ‘Getting teams done’, een praktische gids voor het implementeren van Holacracy. Getting Teams Done is geschreven in de stijl van ‘The Goal’ en ‘The Phoenix Project’. Er is een fictief verhaal van een team dat de overgang maakt van een hiërarchische manier van werken naar een Holacracy. Dat maakt het boek gemakkelijk te lezen. Naast het boek heb ik wat interviews gedaan, een aantal ervaringen met Holacracy gelezen en de officiële Holacracy website geraadpleegd.

Hoe Holacracy werkt

In Holacracy wordt een team een cirkel genoemd. Het Holacracy-proces kent twee verplichte vergaderingen voor elke kring: de bestuursvergadering en de tactische vergadering. Deze bijeenkomsten zouden tweewekelijks en afwisselend moeten plaatsvinden. Het verschil met Scrum is dat bij holocratie de vergaderingen een zeer strikt proces hebben. In Scrum ben je vrij om het proces te optimaliseren en worden alleen de input (wat te inspecteren) en de output (wat aan te passen) van de vergaderingen gedefinieerd. Dit geeft Scrum veel meer ruimte voor continue verbetering.

Holocratische rollen

In Holacracy wordt een rol gedefinieerd als een reeks mandaten en verantwoordelijkheden. Zij zijn de macht en de verantwoordelijkheid om dingen voor elkaar te krijgen. Het lijkt veel op een functiebeschrijving, behalve dat het niet alles is wat een persoon in haar doet een positie: het is slechts een van haar rollen. In tegenstelling tot een functie evolueert het ook expliciet. Dus als persoon heb je misschien meerdere rollen. Of je deelt een rol met andere mensen. De roldefinitie is kort en duidelijk voor alle betrokkenen.

De rol beschrijft werk dat nooit wordt voltooid. Het bevat werkwoorden die oneindig zijn. Ik denk dat deze roldefinitie empirisme mist. Het zou beter zijn als er een maatstaf voor succes zou zijn. Hoe weet je of je je werk goed doet? Wat zijn de ambitieuze doelen die je binnen je rol zou kunnen bereiken die echt indruk zouden maken op de rest van het team?

Holacracy heeft 4 vooraf gedefinieerde rollen:

• Lead link: Definieert prioriteiten en strategieën. Hiermee wijst u rollen toe.
• Representatieve link: Vertegenwoordigt team in een supercirkel om spanningen op te lossen die daaruit voortkomen
• Secretaris: Administratie, meestal met betrekking tot rollen
• Facilitator: Leidt de twee Holacracy-vergaderingen en zorgt ervoor dat de regels worden vastgesteld

‘Spanningen’ en de Bestuursvergadering

Governance in Holacracy is gebaseerd op een interessant concept: het onderscheid tussen rollen en mensen. Dit is ook een basisbegrip in deep democracy. Het leuke van het scheiden van rollen van mensen is dat je de uitvoering van een rol kunt bespreken zonder persoonlijk en emotioneel te worden.

Wanneer de rollen in een cirkel niet passen bij het werk of de kringleden, voelen ze spanningen. Het aanvoelen en bespreken van spanningen is erg belangrijk in Holacracy. Spanningen vormen het grootste deel van de agenda van de bestuursvergadering. Het doel van die bijeenkomst is om die spanningen op te lossen door de rollen of het beleid voor de cirkel aan te passen. Het proces is gebaseerd op toestemming: de cirkel is niet op zoek naar perfectie. Het is op zoek naar een oplossing die goed genoeg is en die geen geldige zorgen oproept.

‘Obstakels’ en de Tactische Vergadering

De tactische vergadering heeft veel weg van een Kanban daily standup: het gaat om het werk dat gedaan moet worden. Deze bijeenkomst mist echter veel van de krachtige aspecten van Scrum en Kanban. Er is geen motivatie om je te concentreren en werk in uitvoering te verminderen. Er is ook geen drive om het werk af te maken, zodat nieuw werk kan worden gestart. Het is gewoon een wekelijkse discussie over eventuele obstakels die zich hebben voorgedaan. Mijn ervaring is dat een week wachten om obstakels met het team te bespreken veel te langzaam gaat. Verder worden alle obstakels besproken, persoon voor persoon. Ik weet niet zeker of dit genoeg focus in het team brengt. Het voelt als een beetje verspilling.

In Holacracy worden de individuele rollen verondersteld om “projecten” bij te houden. “Projecten” worden gedefinieerd als projecten met specifieke resultaten die meerdere opeenvolgende acties vereisen om te bereiken en die nuttig zouden zijn om naartoe te werken, althans zonder concurrerende prioriteiten. Ze zijn geschreven met een deelwoord uit het verleden. Bijv. “Analytics-systeem geïmplementeerd“

Ik denk dat het nadeel hiervan is dat projecten de neiging hebben om de verantwoordelijkheid van individuele mensen te worden. Dit belemmert de flow en teambetrokkenheid.

Volledige Holacracy regelset

Ik zal hier niet in op de details. Als je alle regels wilt zien, is er een “grondwet” die alle regels van Holacracy definieert. Teammanagers zijn zelfs verplicht om het te ondertekenen en letterlijk “hun autoriteit af te staan aan de processen van de grondwet en de verschuldigde resultaten daarvan te voorzien van het gewicht en de autoriteit die anders door de bekrachtiger(s) worden gedragen, zoals verder beschreven in paragraaf 5.1 daarvan. “

Interessante Holacracy elementen

Ik ben niet geneigd om Holacracy als geheel te implementeren. Het proces is gewoon te beperkend. Ik voel me veel meer op mijn gemak bij een framework-aanpak zoals Scrum. Toch zijn er een aantal elementen die ik zal overnemen.

1. Mensen zijn niet hun rol. Zij vervullen hun rol.

Ik zal er een punt van maken om rollen te scheiden van mensen in mijn Scrum coaching praktijk. Dit maakt het wisselen van rol gemakkelijker. Het zal ook de kwaliteit van de retrospectieven verbeteren.

Zeg niet: “Zij IS de Scrum Master”, maar zeg “Ze vervult deze sprint de Scrum Master rol.”

2. Rollen moeten voortdurend worden verduidelijkt en ontwikkeld.

Ik zal een retrospectieve techniek aan mijn collectie toevoegen waarbij we speciale aandacht besteden aan rollen. Betrouwbaarheid is een belangrijke factor in teamprestaties. Duidelijke rollen zullen de betrouwbaarheid van het team veel verbeteren. Ik zal een retrospectieve techniek ontwikkelen waarbij elke rol een ‘emmer’ is en het hele team daarop kan reflecteren. In een typisch webteam kan dit Scrum Master, Product Owner, Front end developer, Tester, UX designer,… In mijn ervaring zijn de verantwoordelijkheden van elke rol altijd afhankelijk van de vaardigheden van elk teamlid en de uitdaging die voor de hand ligt. Het verduidelijken en ontwikkelen ervan zal ongetwijfeld de betrokkenheid en productiviteit verhogen. Misschien kunnen de rollen zelfs hun stukje muurruimte in de Scrum-ruimte hebben.

3. Spanningen zorgen voor continue verbetering

Spanningen worden meestal als een slechte zaak beschouwd. Hoewel Scrum diversiteit viert en er een punt van maakt om experts uit meerdere disciplines bij het werk te betrekken, zegt het niet expliciet dat een verschil van mening een goede zaak is. Ik heb teams zien degraderen tot zombies. Dat belemmert wendbaarheid omdat meer ogen meer risico’s en kansen zien.

Door spanningen te vieren en ze te crediteren voor de voortdurende verbetering die ze voeden, wordt conflict minder een emotioneel iets. Waar mensen samenwerken, zullen er altijd conflicten en spanningen zijn. De kunst is om het te gebruiken voor productiviteit.

Conclusie: Holacracy vs. Scrum

Holacrcy is meer gerelateerd aan Sociocratie dan aan Agile en Scrum. Maar omdat de methode gepositioneerd is als “een concreet kader voor het coderen van autonomie, wendbaarheid en purpose-alignment in het DNA van uw organisatie”, ga ik het toch vergelijken met Scrum en Kanban.

Als je team snel produceert, snel verandert, snel innoveert, is Holacracy misschien niet de juiste keuze voor u. De verbeteringscyclus is te traag. De focus op spanning op individueel niveau is geen garantie om visionaire organisatiewaarde te produceren. Kanban brengt meer focus met een eenvoudigere methode ten koste van het definiëren van duidelijke rollen.

Ik zou Holacracy niet agile noemen, omdat het niet empirisch is zoals Kanban en Scrum. Er is weinig motivatie om de naald tegelijk te verplaatsen. Het lijkt erop dat Holacracy meer op een versnellingsbak lijkt en elke individuele versnelling optimaliseert om goed aan te sluiten bij de anderen. Scrum en Kanban lijken meer op een sneeuwbal. Ze winnen voortdurend aan momentum, maar blijven open genoeg om van koers te veranderen wanneer dat nodig is.

Deel om andere mensen te helpen!

Als dit artikel nuttig was, vergeet dan niet om het te delen met andere mensen die er baat bij kunnen hebben. Je kunt ze doorverwijzen naar mijn Facebookpagina over teamwork. Je kunt ze ook doorverwijzen naar LinkedIn.

The post Holacracy vs. Kanban vs. Scrum appeared first on Anton Vanhoucke.