Planningpoker in chaordische context

Complexe projecten vragen om een benadering die veel ruimte biedt aan het onverwachte, om te kunnen leren van het verleden. Daarom werken we op basis van een ontwikkelingsbenadering. Het hanteren van zo’n ontwikkelingsbenadering die vaagheid toelaat maakt plannen lastig. Complexe of chaordische projecten laten zich niet plannen. Niet in een deel, en zeker niet als geheel. Toch wil je uitspraken kunnen doen over de omvang. Inschatten waar energie in gestoken moet worden, is desondanks een belangrijk component van projectmanagement, zeker gezien het reserveren van middelen en capaciteit. Echter, bij veel complexiteit en onzekerheid werkt ‘traditioneel plannen’ niet. Wat dan wel?

Planningpoker biedt uitkomst. Planningpoker is een krachtige vorm om inzicht in complexiteit te krijgen, waarmee het team snel en nauwkeurig de omvang in kan schatten, zonder dat een en ander concreet hoeft te zijn. Het hele team, en waar wenselijk de klant, schuift aan.

Hoe gaat het in zijn werk?

Planningpoker gaat over het inschatten van complexiteit in plaats van het inschatten van tijd. Het betreft het vergelijken van opdrachten (in een Scrum-omgeving stories genoemd) met elkaar. Een opdracht is een beschrijving van een situatie met het belang van de gebruiker of klant voor ogen. Het kan een activiteit zijn, een mogelijkheid, een investering of bijvoorbeeld een thema. Door te luisteren naar argumenten en onderbouwingen van een bepaalde inschatting van de complexiteit van zo’n opdracht, komen we tot een gedeelde waarde voor de story.

Elk teamlid heeft een set met twaalf kaarten met daarop de volgende waarden: ‘0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?’. De onderhanden opdracht wordt toegelicht door de aandrager of eigenaar. Het is niet nodig alle details helder te hebben, wel moet elk teamlid begrijpen wat de opdracht inhoudt. Initieel wordt een eenvoudige referentieopdracht vastgesteld waar een waarde aan wordt toegekend (bijvoorbeeld 3). Aan de hand van deze referentieopdracht gaat elk teamlid de aangedragen opdracht inschatten. Hij kiest die kaart uit zijn set met zijn beeld van de complexiteit van de opdracht en houdt deze gesloten totdat iedereen een keuze heeft gemaakt. Dan worden de kaarten – tegelijkertijd – omgedraaid.

Geeft iedereen eenzelfde waarde aan deze opdracht (dezelfde kaart), dan is de in te plannen complexiteit duidelijk. Iedereen heeft hetzelfde beeld. Is dit niet het geval, dan krijgen de eigenaren van de hoogste en de laagste inschatting ruimte om toelichting te geven. Zo komt informatie boven tafel vanuit een gezichtsveld dat anders buiten beeld was gebleven. Er wordt holistisch naar een opdracht gekeken.

Na de toelichting van de meest afwijkende waarden wordt door iedereen opnieuw een kaart gekozen uit de set met kaarten, eerst gesloten en daarna – tegelijkertijd – getoond. Er zijn tenslotte nieuwe inzichten opgedaan die wellicht van invloed zijn op jouw beeld van de opdracht. Natuurlijk kunnen er altijd inzichten blijven afwijken, maar bij voldoende convergentie wordt de gedeelde waarde bepaald. Met die waarde wordt de opdracht op de planning van het team gezet en kan de klant of eigenaar (product owner in Agile Scrum) aangeven wat de prioriteit van dit ingeschatte deel op de planning krijgt. Zijn er nog steeds te veel verschillen in inzicht, dan zal buiten de pokersessie eerst meer duidelijkheid moeten worden verschaft. Dan is een opdracht nog niet klaar om ingepland te worden.

Spelregels

  1. Voorzie elk teamlid van een set met kaarten.
  2. Bespreek kort de opdracht.
  3. Elk lid kiest een kaart en houdt deze gesloten (kies een ‘?’ als je geen enkele voorstelling hebt van de opdracht).
  4. Toon de kaarten gelijktijdig.
  5. Laat de eigenaren van de hoogste en de laagste waarden hun keuze toelichten.
  6. Herhaal vanaf stap 3 (maximaal drie keer; geen convergentie, dan eerst buiten de pokersessie ophelderen).
  7. Besluit met welk gewicht de opdracht op de planning komt.

Door te meten hoeveel tijd wordt besteed aan de uitvoering van een opdracht en dat te verbinden aan het toegekende gewicht, is eenvoudig te achterhalen hoeveel opdrachten realiseerbaar zijn in een bepaalde periode. Door te werken in vaste periodes (van bijvoorbeeld twee of drie weken) ben je in staat een goed voorspelbaar beeld te geven.

 

Deze werkvorm is gebaseerd op de ervaringen van Cris Kaai, projectmanager bij Sligro Food Group. Cris is (o.a.) opgeleid in Value-based Project Management. Hij weet in zijn werk de gedachten van chaordisch projectmanagement te integreren met in de organisatie gebruikelijke wijzen van werken als Agile en Scrum.

Deze werkvorm staat ook beschreven in "77 werkvormen voor projectmanagement"

Kom met uw praktijkervaringen op het terrein van managen en organiseren

Deel uw kennis, schrijf 3 columns of artikelen en ontvang een gratis pro-abonnement (twv €200)

Word een pro!

SCHRIJF MEE >>

Jan-Sake Kruis
Lid sinds 2019
Beste Cris,
De beschreven techniek heb ik al vaak met succes toegepast en gepromoot (ik ben zelf Agile coach) maar desondanks blijft het voor mij erg lastig om uit te leggen wat wordt bedoeld met het begrip complexiteit. Naar welke aspecten kijk je dan en heeft iedere deelnemer wel hetzelfde referentiekader. Door het gesprek dat gevoerd wordt zal er meer gemeenschappelijk begrip ontstaan over zowel het onderwerp als het referentiekader, maar het is ook niet uit te sluiten dat dit niet gebeurd. Met alle gevolgen van dien in het vervolgproces. In de praktijk zie je dat deelnemers hiermee worstelen en dan in hun hoofd een vertaling gaan maken naar benodigde uren. Een aantal voordelen van de methodiek worden dan teniet gedaan. Ik ben benieuwd welke definitie jij gebruikt voor het begrip complexiteit en hoe je dit in de praktijk toepast.
Cris Kaai
Een mooie vraag! Om een team hetzelfde referentiekader te geven kies ik met het team altijd een eenvoudige opdracht uit de beschikbare uit te voeren opdrachten. Deze referentieopdracht wordt bij elke pokersessie doorgenomen en opnieuw gebruikt. De aspecten die er toe doen bepaalt het team dat de complexiteit inschat. Door los van elkaar de complexiteit te kiezen en die daarna pas open te leggen komen de verschillende aspecten vanzelf naar boven omdat de uitzonderlijk lage of hoge inschattingen besproken worden.
Voorkomen van verschillende beelden betekend voor mij dezelfde referentie blijven herhalen bij elke planningssessie.
Hoe houd je vast aan complexiteit? In mijn optiek door steeds te schatten ten opzichte van de referentie die je als team hebt vastgesteld. Relatief schatten ten opzichte van de onder handen zijnde opdracht en de referentie.
Natuurlijk speelt tijd een rol. Maar die tijd gaan we pas koppelen als we een paar cycli hebben gedaan en we weten hoeveel complexiteit we in een cyclus weg kunnen werken.
Willem Mastenbroek
Pro-lid
Wat wordt hier bedoeld met complexiteit? Zolang dat vaag blijft staat de deur wijd open voor grote verwarring, langs elkaar heen praten en abstracte luchtfietserij.

PlanningPoker verschaft, in het verband van Scrum/Agile, al houvast door de partijen die belang hebben bij het project te identificeren. Dan gaat de discussies niet langer over 'aspecten' maar over belanghebbenden en de activiteiten die het betreffende belang zouden dienen. Hoe meer de discussie 'vermenselijkt' wordt hoe tastbaarder de 'aspecten' worden. Bij die 'vermenselijking' passen ook vragen als wie het meeste baat hebben bij het project en wie verantwoordelijk zijn.

De column lezende nam ik overigens aan dat de auteur dat ook bedoelde. De discussie die erop volgde deed mij daaraan twijfelen. Ik ben benieuwd hoe Jan-Sake en Cris complexiteit dan wel invullen als ze er vragen over krijgen.

Zie ook https://www.managementsite.nl/complex-ammehoela
Cris Kaai
Een mooie verduidelijking van complexiteit vind ik deze: "De complexiteit die in dit kader bedoeld wordt zou beter ‘ingewikkeldheid’ kunnen worden genoemd. Het betreft hier het verschil tussen een brommer en een olifant: een brommer is ingewikkeld, kun je uit elkaar halen en weer terug in elkaar zetten. Met een olifant gaat je dat niet lukken. Een olifant is niet ingewikkeld maar complex: alles hangt met alles samen en essentiële onderdelen gaan verloren als je hem uit elkaar haalt (nog even los van de vraag of het daarna in elkaar zetten enig nut heeft…)." (Value-based project management : een aanpak voor chaordische projecten vanuit het perspectief van het complexiteitsdenken https://pure.tue.nl/ws/files/3712358/740171.pdf)

In dit kader gebruik ik als voorbeeld vaak de complexiteit van diverse flesjes met drank. Een flesje Spa blauw niet zo complex is, een flesje Brewdog (bier) een stuk complexer is dan een flesje Spa blauw, maar doordat de recepten gedetailleerd beschikbaar zijn qua complexiteit nog steeds te bevatten. Een flesje Coca Cola wordt dan wel heel complex: het exacte recept is niet bereikbaar en niemand schijnt het na te kunnen maken: de complexiteit is dan oneindig.

Een halve olifant opleveren kan niet. Het mooie is dat met Planningpoker bij de balanghebbenden veel creativiteit kan worden losgemaakt om iets dat complex lijkt samen anders te bekijken en zo grip te krijgen op een project zonder zaken vooraf eindeloos uit te specificeren.
Glenn Bieger
Lid sinds 2019
Hi Cris,

In de context waarin jij planningpoker beschrijft wordt het niet gebruikt om complexiteit in the schatten, maar "effort". Onderstaand artikel van Mike Cohn legt het goed uit:

https://www.mountaingoatsoftware.com/blog/its-effort-not-complexity

"In a class a few years back, I was given a wonderful example of this. Suppose a team consists of a little kid and a brain surgeon. Their product backlog includes two items: lick 1,000 stamps and perform a simple brain surgery -- snip and done. These items are chosen to presumably take the same amount of time. If you disagree, simply adjust the number of stamps in the example. Despite their vastly different complexities, the two items should be given the same number of story points -- each is expected to take the same amount of time."

De complexiteit van een opdracht beinvloed de planningpoker score (story points) enkel wanner het impact heeft op de "effort".

Ik werk zelf in een Engelstalige omgeving dus ik weet helaas de gangbare Nederlandse vertaling van "effort" niet.
Cris
Hi Glenn,

Lees ook deze eens: https://www.quora.com/What-is-the-difference-between-story-points-and-effort-estimates-and-how-do-we-use-them-in-backlog-grooming-and-sprint-planning
Willem Mastenbroek
Pro-lid
Beste Cris en Glenn

Jammer genoeg maken jullie reacties mij niet veel wijzer. Niet dat het geen goede definities van complexiteit zouden zijn. Maar ik ben bang dat we het zo nodeloos extra ingewikkeld maken.
Een project is geen olifant of samenstel van story-points. Een project is een samenstel van menselijke activiteiten. Deze kijk dwingt 'man en belang' te noemen.
Voorbeeld: 'Waarom zijn er zoveel falende ICT projecten bij de overheid?'
'Het is zo complex!'
Welnee, zie https://www.managementsite.nl/ict-debacle-overheid