Een verhaal over aannames, communicatie en het belang van regelmatige afstemming.
Aannames: De sluipmoordenaar van heldere communicatie
Tijdens de implementatie van een nieuw tarief leek alles volgens plan te verlopen.
Het project liep op schema, de aanpassingen werden doorgevoerd en de testresultaten zagen er goed uit.
Tot het moment dat de opdrachtgever de eindversie onder ogen kreeg. Wat er was opgeleverd,
voldeed totaal niet aan wat men voor ogen had. Verwarring alom. En frustratie.
Wat ging hier mis? Tijdens het project werden aannames gedaan die nooit expliciet geverifieerd zijn.
Termen als ‘tarief’, ‘premieberekening’ en ‘kortingsstructuur’ klonken bekend in de oren.
Alleen… betekenden ze voor iedereen hetzelfde? Niet dus.
Er werd gecommuniceerd in vaktermen. Zowel aan de kant van de business als IT werd ervan uitgegaan
dat de ander “wel wist wat er bedoeld werd”. Maar zoals zo vaak geldt:
als je iets niet expliciet controleert, loop je het risico dat je langs elkaar heen werkt.
Tegen de tijd dat de verschillen werden ontdekt, zat het werk er al bijna op.
De correcties kostten veel tijd, geld en goodwill.
Van waterval naar SAFe: een wereld van verschil
Destijds werkten we volledig volgens de watervalmethode. De scope lag maanden vast,
het contactmoment met de opdrachtgever was beperkt en de oplevering kwam pas aan het eind.
Het voelde als een duikboot: onderduiken, bouwen, opleveren. Pas dan hoor je of het goed was —
of niet.
Binnen SAFe is dat anders. Elke PI is een kans om richting te toetsen.
MVP’s zorgen voor snelle feedback. Inspectie- en adaptatiemomenten zijn ingebouwd.
We spreken met elkaar. Vaak. Expliciet. Open.
De kracht van vragen stellen
Wat ik persoonlijk geleerd heb? Veel. Maar het belangrijkste is misschien wel dit:
stel vragen, veel vragen. Vervelend veel vragen. Bijvoorbeeld:
- Wat bedoel je precies met ‘korting’ in dit tarief?
- Kun je dit uitleggen aan de hand van concrete voorbeelden?
- Wie bepaalt of dit correct is ingericht?
Of klassiek: de vijf keer “waarom”. Niet om irritant te zijn, maar om helderheid te creëren.
Want alleen dan ontstaat er begrip. En alleen met begrip kun je bouwen aan een oplossing die écht werkt.
Duikboten maken schade. Dolfijnen maken progressie.
Een beeld dat ik vaak gebruik is het verschil tussen de duikboot en de dolfijn.
De duikboot duikt onder en komt pas boven als alles af is.
De dolfijn daarentegen duikt óók, maar komt regelmatig boven om te ademen, te toetsen, te navigeren.
Als architect wil ik een dolfijn zijn. Samen met het team, de product owner en de business.
We duiken in de inhoud, maar blijven verbonden met de werkelijkheid.
We komen regelmatig boven om te vragen: “Zitten we nog goed?” En dat maakt het verschil.
— Martin de Weger

En het wil ook nog eens helpen als iedereen zijn verantwoordelijkheid neemt, want anders komt het ook niet goed.
Leuke stukjes schrijf je Martin.
Dat ook. Ik denk dat de kern vaak neerkomt op miscommunicatie.
Dank je wel Huub.