scrummaster.nl

“Nog een half uur”. Dat was het antwoord van mijn vader als we vroegen hoe lang het nog zou zijn voordat we eindelijk in de haven zouden bereiken. Dat half uur bleek in praktijk geregeld een paar uur te duren. Om een of andere reden gaf mijn vader nooit het juiste antwoord.

Ik als baby aan boord

Hoe simpel is het: met behulp van de passer bepaal je in hoeveel uur je aan kan komen, en met behulp van de plotter bepaal je de koers. Dan ga je op weg en stuur je met behulp van het kompas naar de juiste richting. En dan toch zo’n foute schatting afgeven…

De backlog verleidt tot dezelfde vraag. Hoe lang nog. Dan niet tot de haven, maar tot een bepaald feature gerealiseerd is, of tot ‘alle gevraagde’ functionaliteit opgeleverd is. En graag nauwkeurig want er zijn stakeholders die er afhankelijk van zijn. En tenslotte zijn we toch professioneel bezig, dus weten we wat we doen en wanneer. Natuurlijk accepteren we wat variatie, maar niet te veel graag.

Aan boord wisten we dat er veel kon gebeuren dat de boel in de war zou kunnen sturen. De natuur gaf niet zo veel om onze plannen en deed haar eigen ding. Natuurlijk verschoven terwijl wij op zee waren de tektonische platen en het magnetische noorden. Natuurlijk bewogen zandbanken om ondieptes te vormen die er eerst niet waren. Maar de kaart, onze representatie van het domein, bleef accuraat genoeg voor de tijd die wij nodig hadden om ons doel te halen. Het was de wind, de stroming en de golven die er voor zorgden dat we niet daar heen gingen waar we heen wilden. Als voor zover je oog kan reiken er uit ziet als dezelfde zee met dezelfde golven wordt het moeilijk om te bepalen waar je bent en waar je heen gaat.

Het maken van software heeft dezelfde ‘onzichtbaarheid’ als het gaat om te bepalen waar je precies bent. Ja, je hoopt dat je de prioriteiten goed gedaan hebt, je hoopt dat je hebt gemaakt wat je afnemers nodig hebben, maar zeker weten… dat weet je pas als je enige tijd op de markt bent. En al had je de juiste keuze gemaakt, er zijn alweer veranderingen geweest waardoor je nu waarschijnlijk een andere keuze zou hebben gemaakt.

Tijdens het zeilen bepaalden wij om het uur onze positie. In de periode voordat de GPS voor normale mensen te betalen was ging het  net zoals het al eeuwen gebeurde: een gegist bestek. Met behulp van een sleeplog werd de snelheid vastgesteld en tesamen met de gevaren koers dacht je dan te weten waar je was. Het is trouwens nog steeds verstandig om deze vaardigheden onder de knie te hebben als je gaat zeilen.

Het doel van deze regelmatige controle was niet om te bepalen hoe laat we aan zouden komen, maar om te bepalen wat we moesten aanpassen om veilig aan te komen. Dat betekent niet alleen de koers, maar ook een inschatting wat het weer gaat doen, welk invloed het getij gaat hebben en welke gevaren de zee verbergt zoals zandbanken, venijnige stromingen of drukke scheepsvaartslanen. Ook met GPS is dat nog steeds noodzakelijk.

Noordzee 1977

De sprint van Scrum bestaat voor dezelfde reden. Op de grens van de sprint bepaal je positie door middel van de Sprint Review, al blijft het een gegist bestek. De Product Owner gebruikt deze informatie en alle andere informatie die hij verkregen heeft om te bepalen wat de volgende koers moet zij om het eindresultaat van de release veilig te kunnen stellen. De eerstvolgende Sprint Planning is het moment waarop de vergaarde informatie leidt tot uitvoering van het nieuwe doel. Wat bij ons aan boord gebeurde door wind, stroming en golven gebeurt bij software ontwikkeling door veranderende inzichten, marktomstandigheden en verwachtingen.

In mijn kindertijd ging al die navigatie compleet langs mij heen. Voor mij was de enige vraag die belangrijk was “hoe lang nog”. Hoe lang nog tot ik weer kan gaan spelen, hoe lang nog totdat ik niet meer zeeziek over de reling hoef te hangen. En omdat mijn vader wist dat het echte antwoord complexer was dan ik wilde horen was het antwoord ‘een half uur’.

De ‘hoelang nog?’ vraag vanuit een organisatie is dus zeer begrijpelijk, maar het is de verkeerde vraag. Waar zijn we? Waar moeten we heen? Wat is daar voor nodig? Het delen van de resterende hoeveelheid werk met de snelheid van opleveren geeft een naïef en vertekenend beeld.

Hoe lang nog… een half uur.

4 reacties op “Voorspelbaarheid is niet het doel, veilig aankomen wel”

  1. Maurice

    Tijdens het schrijven van dit artikel, of eigenlijk tijdens het toevoegen van de foto’s, raakte mijn evenwichtsgevoel van slag. Het verwachtte een beweging die niet kwam.

    Het aantal uren dat ik op de boot doorgebracht heb is blijkbaar zoveel dat het voldoende is om mijn zintuigen voor te bereiden op de deining.

  2. Tweets die vermelden » Voorspelbaarheid is niet het doel, veilig aankomen wel ‹ scrummaster.nl › -- Topsy.com

    [...] Dit blogartikel was vermeld op Twitter door Ruud Rietveld, M. le Rutte. M. le Rutte heeft gezegd: Nieuw: "Voorspelbaarheid is niet het doel, veilig aankomen wel" Over de voorspelbaarheids behoefte bij een project http://bit.ly/d2bXY1 [...]

  3. Marius van Dam

    Hoi Maurice,

    Mooi stuk en hoe waar! Deze vraag krijgen we regelmatig en het is verleidelijk om een antwoord te geven omdat dat het makkelijkste lijkt.

    Toch zullen we op een zeker moment duidelijkheid moeten geven aan onze opdrachtgevers. Het kan niet onzeker blijven. Op een gegeven moment wil je weten wat je hebt. Bijvoorbeeld omdat je een marketing campagne plant rondom de lancering van de nieuwe software. Kunnen we daarin die ene feature noemen of niet? Zeker in een grote hiërarchische organisatie zal het lastig zijn om vaag te blijven nav dit soort antwoorden.

    Hoe zou je daarmee omgaan?

  4. Marius van Dam

    Nog even vervolg: “Het kan niet onzeker blijven” schrijf ik in mijn commentaar…
    Dat blijft het misschien wel altijd, een beetje. 100% zekerheid is er niet want je weet niet wat je nog tegen gaat komen zoals je al beschreef.

    Wat de opdrachtgever eigenlijk wil is dat jij garant staat voor het leveren binnen een bepaalde tijd. Hij wil een belofte die jij waar gaat maken. Het risico is dan voor jou. In sommige gevallen kun je dat risico wellicht nemen, in andere gevallen is de situatie te onvoorspelbaar en kun je misschien een ander voorstel doen om de risico’s te verkleinen. Bijvoorbeeld door bepaalde functionaliteit meer prioriteit te geven en andere te schrappen.

Reageer

Proudly powered by WordPress. Theme developed with WordPress Theme Generator.
Copyright © scrummaster.nl. All rights reserved.