Never split the difference is een fascinerend boek van Chris Voss, wat trouwens niets te maken heeft met programmeren of zelfs maar met software. Voss was onderhandelaar voor de FBI bij gijzelingen. Het werk waar ze in Hollywood van die testosteron-gedreven actiefilms van maken met Samuel L. Jackson, maar dan in het echt. Begrijpelijk dat hij sindsdien een lucratiever en minder stresserend carrièrepad naar de consultancy is ingeslagen.

Splitting the difference, ofwel eerlijk delen van het verschil, lijkt een fair compromis als de partijen geen eindbod overeen kunnen komen. Maar iedereen schiet er bij in, zij het dan evenveel. Ze hadden beter weg kunnen lopen, want de koper betaalt teveel en de verkoper krijgt te weinig. Hier is een hopelijk grappig voorbeeld met schoenen. Als je echt geen keuze kunt maken tussen het bruine en zwarte paar, doen dan maar de grijze, maar niet één van elk. Als de buienradar 50% kans op regen voorspelt voor je wandeling trek je toch ook niet één waterdichte schoen aan voor de zekerheid?

Dit zijn geen serieuze voorbeelden, maar zoveel minder absurd is het niet als je tijdens Scrum poker een groot verschil van mening tegenkomt en denk dat je op de helft van het verschil wel goed zit. Bij een verkoop hebben de partijen per definitie een conflicterend idee wat de beste prijs is, maar bij Scrum onderhandelen we daar niet over en horen de teamleden geen verschillende agenda te hebben. Een inschatting is geen mening en al zeker geen kwestie van smaak. Het moet een onderbouwd oordeel zijn van hoeveel inspanning en (on)zekerheid gemoeid is met een brok werk voor het team. Dat laatste is belangrijk. Je vorm dat oordeel voor het huidige team als geheel, niet voor een fictief kloonleger van jezelf. Als we het daar over eens zijn kan een taak niet tegelijk drie en acht punten waard zijn. Een van de twee is correct, of ze zijn allebei incorrect. In dit universum zitten er niet tegelijk driehonderd en achthonderd erwten in de fles. Ga je ervan uit dat de waarheid in het midden ligt, dan neem je impliciet aan dat beide partijen er even ver naast zaten, dat Daniel het werk net zoveel overschat heeft als Brenda het onderschatte. Die aanname is nergens op gebaseerd.

Als alle teamleden genoeg voorkennis hebben van de taak en goed weten waar de eenheden voor staan, dan zouden de individuele schattingen niet ver uiteen mogen lopen. Dat we dat in de praktijk wel dikwijls zien kan twee dingen betekenen. We varen ofwel op verschillende aannames, hebben niet dezelfde voorkennis van de taak, of beheersen het domein niet gelijkelijk. Of er is verschil van mening over de schattingseenheid. Het kan zeker geen kwaad dit regelmatig op te frissen.

Het woord schatting (estimation) draagt een element van onzekerheid in zich, van raden. We kunnen die onzekerheid niet uitbannen, maar we moeten wel de educated guesses zo gering mogelijk houden. Maak het verschil expliciet tussen de harde feiten en de aannames. Hoe groter de onzekerheid, hoe hoger de inschatting moet zijn. Als je tenslotte toch geen overeenstemming krijgt omdat de taak te complex is, of niet duidelijk genoeg, dan was hij klaarblijkelijk nog niet ready. En net zoals het soms verstandig is een verkoop af te blazen moet je er geen nep-inschatting door willen drukken. Dan maar terug naar de tekentafel.