Deze video is voor iedereen die werkt in of met een Agile team.

• Team Leads en Product Owners die worstelen met prioritering en stakeholderverwachtingen
• Developers en engineers die willen begrijpen hoe beslissingen over de backlog worden gemaakt.
• Managers en directeuren die willen snappen wat Agile nu echt betekent in de praktijk.
• Scrum Masters en Agile Coaches die een heldere uitleg zoeken voor nieuwe teamleden.

Hoe krijg je meer focus en flow?

De video volgt Sam, een Team Lead die een nieuw product ontwikkelt samen met een klein, zelforganiserend team. Met een eenvoudig voorbeeld zie je dat meer instroom dan uitstroom niet meer snelheid oplevert – het leidt tot multitasking, demotivatie en lagere kwaliteit. Net als auto’s toevoegen aan een file: het werkt averechts.

Hoe krijg je meer grip op de backlog?

Stakeholders en teamleden blijven ideeën aandragen. Dat is goed! Maar zonder actief beheer wordt de backlog een wensenlijst van zes maanden oud. De video toont drie manieren om dat te voorkomen: prioriteren, opdelen en nee zeggen. Waarbij dat laatste het moeilijkst én het belangrijkst is.

Keuzes maken levert snelheid op

Ja zeggen is makkelijk. Maar je wekt verwachtingen waar je niet altijd aan kan voldoen. Nee zeggen beschermt het team, bewaakt de focus en zorgt ervoor dat de discussie verheldert.

Hoe kun je beloven wanneer iets af is?

“Wanneer is mijn feature klaar?” is een vraag die elke Team Lead krijgt. De agile animatie toont hoe je met een simpele burn-up chart en twee trendlijnen eerlijke antwoorden geeft, gebaseerd op echte data, niet op hoop.

Hoe balanceer je onderzoek met nieuwe functionaliteit?

De teamlead en het team maken voortdurend afwegingen. Hieronder wat aanknopingspunten als je die zelf wil maken.

• Kenniswaarde vs. businesswaarde – reduceer eerst risico, lever daarna klantwaarde
• Nieuw bouwen vs. bestaande producten verbeteren – een team heeft één backlog voor alles.
• Reactief vs. proactief werk – timebox beide, anders wint altijd de brand van de dag.
• Het juiste bouwen vs. het goed bouwen vs. snel bouwen – alle drie tellen, maar de balans verschuift voortdurend.

Denk je dat de agile animatie beter kan? Laat het weten!

Complexe concepten als velocity, burn-up charts en technische schuld zijn lastig uit te leggen in tekst alleen. Met de animatie wil ik abstracte ideeën tastbaar maken. Je ziet de backlog groeien, de capaciteit botsen met de input, en de trendlijnen van de forecast verschijnen. Als je dingen onduidelijk vindt, laat het weten. Dan pas ik het aan in een nieuwe versie.

De uiteindelijke tekening kun je hier zien en downloaden.

De diepte in met wendbaarheid?

Bij Wendbaar Groeien helpen we teams en organisaties om wendbaarder te werken – niet als doel op zich, maar als middel om sneller waarde te leveren en beter te leren. Benieuwd hoe dat eruitziet voor jouw organisatie? 📩 Neem contact op of bekijk ons trainingsaanbod.

The post Animatie: Waarom “nee” veel oplevert voor agile team leads appeared first on Anton Vanhoucke.

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.

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.

Agile management is uitzoomen bij urgente problemen

Problemen in de nabije toekomst kunnen al je aandacht opeisen en het team uit elkaar drijven. De beste manier om uit zo’n situatie te komen is de aandacht bewust te verleggen. Waarheen? Naar het positieve – wat je wél wil – en het grotere geheel. Dat is ook wat professionele onderhandelaars als Kohlrieser doen. Aandacht op deze manier verplaatsen is een techniek die zelfs bij gewelddadige gijzelingen effectief is. En als deze techniek daar werkt, dan helpt het zeker bij een team dat vastzit in lastige problemen. Dringende problemen halen je aandacht weg bij de grotere missie. Als je dit effect van problemen ziet, kun je bewust je focus veranderen. Die nieuwe focus helpt om betere betere oplossingen te vinden voor het urgente probleem.

Het geheel optimaliseren is niet hetzelfde als de delen optimaliseren

Het advies om naar het grotere geheel en de toekomst te kijken is niet alleen waardevol bij gijzelingen, maar helpt ook je bedrijfsresultaten te verbeteren. In 1982 schreef Goldratt ‘The Goal’, een bestseller die efficiënte productieprocessen onder de aandacht brengt. Hij koos voor de titel ‘The Goal’ omdat hij zag dat lokale optimalisatie niet altijd tot algehele verbeteringen leidt op het gebied van winst, klanttevredenheid en groei.

Als het ontspoort gaat dat ten koste van het grotere geheel

Marketing en Sales vormen vaak een klassieke clash als het gaat om winst, klanttevredenheid en groei. Deze executives hebben verschillende mindsets en leiden teams met uiteenlopende culturen. Wanneer problemen overheersen, worden de verschillen scherper en de silo’s duidelijker. Ik heb gezien dat dit rampzalig kan zijn voor de wendbaarheid van de organisatie.

Agile Management Teams hebben een voorbeeldrol

Een wendbaar, Agile, team trekt samen op en maakt zich sterk voor het hoogste organisatiedoel. Als teams intern niet verzuild zijn, maar juist samenwerken, beïnvloedt dit positief alle teams binnen de organisatie. Mijn ervaring is dat een rolvoorbeeld op hoog niveau veel navolging krijgt in de niveaus er onder.

In beweging komen

Als jij je herkent in deze uitdagingen en klaar bent om jouw managementteam naar nieuwe hoogtes te tillen, laten we dan praten. Ik heb me gespecialiseerd in het transformeren van teams door middel van positief management. Samen kunnen we ervoor zorgen dat je team niet alleen problemen efficiënter oplost maar ook innovatiever en flexibeler wordt.

The post Positief Management – De Sleutel tot Meer Resultaat appeared first on Anton Vanhoucke.

Kapitein Marquet’s aanpak was revolutionair. Hij weigerde bevelen te geven en beperkte zich tot het uitdrukken van het einddoel, zonder oplossingen te dicteren. Deze verschuiving gaf zijn bemanning een gevoel van eigenaarschap en verantwoordelijkheid. Hoe is dit van toepassing op backlog refinement in Agile?

Beperk je tot wat en waarom bij het backlog refinement proces

Net als een onderzeebootkapitein zou een Product Owner het ‘wat’ en ‘waarom’ van backlog items moeten verwoorden, en het ‘hoe’ aan het ontwikkelingsteam overlaten. Deze benadering zorgt voor een levendige, oplossingsgerichte discussie onder ontwikkelaars en ontketent hun creativiteit en expertise.

Don’t Brief, Certify

Als je alleen over wat en waarom praat, weet je nog niet zeker of mensen de goede dingen gaan doen. In “Turn the Ship Around” introduceert Marquet de “Don’t Brief, Certify” techniek. In plaats van gedetailleerde briefings te geven, peilde hij het begrip en de vaardigheid van de bemanning. Toegepast op Agile, zorgt de Product Owner er tijdens backlog refinement sessies voor dat het team elk item volledig begrijpt. Het gaat niet om instructies, maar om zeker zijn dat het team de kennis heeft om aan de slag te gaan.

Creatieve gesprekken tijdens backlog Refinement

Als je als product owner bij hoe en waarom blijft, krijg je boeiende gesprekken over oplossingen. Het team bespreekt en analyseert samen elk backlog item, en biedt diverse perspectieven. Dit proces zorgt niet alleen voor een dieper begrip, maar versterkt ook de toewijding aan de bedachte oplossingen. Wat je bovendien doet, is sturen op resultaat, in plaats van op oplossingen en plannen. Dennise Visser en ik schreven hier een praktisch boek over.

Grip houden: korte frequente gesprekken

Als het team aan de slag kan, heb je nog geen garantie op volledige wederzijds begrip. Marquet bedacht hiervoor “korte, vroege gesprekken”. In Agile betekent dit dat de Product Owner een kort gesprek heeft met het team heeft net voordat ze beginnen te werken aan backlog items, bijvoorbeeld tijdens de Daily Scrum. Deze gesprekken dienen als een laatste check-in, om afstemming en duidelijkheid te waarborgen.

Nieuwsgierigheid in plaats van ondervragen

Bij deze korte, vroege gesprekken is je mindset als Product Owner cruciaal om de betrokkenheid van het team hoog te houden. De uitdaging is om deze gesprekken met nieuwsgierigheid te benaderen, niet als overhoring. Open vragen stellen en actief luisteren toont vertrouwen in de capaciteiten van het team. Het gaat om begrijpen en open staan voor alternatieven. Het gaat niet om hun competentie in twijfel te trekken.

Laat het team het uitvinden

Deze “Don’t brief, certify” en “Short, early conversations” toepassen in backlog refinement kan de teamdynamiek en efficiëntie aanzienlijk verbeteren. Door een doelgerichte aanpak te adopteren, oplossingsgerichte discussies aan te moedigen, en afstemming te behouden door korte, vroege gesprekken, kan Backlog Refinement veel creatiever.

Duik Dieper met Expertbegeleiding

Als deze strategieën je backlog refinement uitdagingen niet oplossen, ligt het probleem misschien dieper. Neem contact op met Anton Vanhoucke, een expert in Agile en Scrum praktijken, om op maat gemaakte oplossingen voor de unieke behoeften van jouw team te verkennen. Met Anton’s begeleiding kun je jouw Agile onderzeeër omvormen tot een krachtpatser van productiviteit en innovatie.

The post Het Backlog Refinement Proces van een Onderzeebootkapitein 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.