Ken je het verhaal van de toren van Babel? Je kunt op Wikipedia je geheugen opfrissen, maar het kwam in het heel kort hierop neer: de mensen van Babel wilden een toren bouwen die tot de hemel reikte, maar dat mislukte omdat de bouwers elkaars taal niet verstonden.
Als we het tegenwoordig hebben over ‘een Babylonische spraakverwarring’, bedoelen we dat er onbegrip is tussen mensen. We snappen niet waar de ander het over heeft. Ik zie dat helaas nog vaak om me heen in softwareprojecten. In deze post vertel ik je waar het probleem vandaan komt en hoe je het op kan lossen.
Beloftes en aannames
Tussen klant en developer begint de spraakverwarring meestal met aannames. Dat ziet er ongeveer zo uit:
Klant: Dit is m’n wens. Bouw dit 🫸
Developer: OK! 🏠
Een kort verhaal, maar toch kunnen zelfs hier de aannames gigantisch zijn. De klant, die overigens geen business user hoeft te zijn, het kan ook om een product owner gaan, een tester of een andere stakeholder, denkt misschien te weten wat nodig is om het product beter te maken. En neemt daarbij dus aan dat de genoemde wens een oplossing is voor het probleem.
Daarnaast kan de developer ook nogal wat aannames doen. De reactie die de developer hierboven geeft zie ik elke dag om me heen. Jij wilt dit? Prima! Ik neem aan dat je er goed over hebt nagedacht en zal mooie code schrijven die dit voor elkaar gaat krijgen. De spraakverwarring zit hem er in dit geval in dat de klant denkt dat zijn probleem opgelost gaat worden als de developer zijn wens heeft gebouwd. De klant zegt “bouw dit”, maar bedoelt “los het onderliggende probleem op”.
De developer ziet de opdracht en precies deze opdracht wordt uitgevoerd.
Ik vind het belangrijk om hier bij te zeggen dat in deze situatie niemand bewust het proces verstoort. In tegendeel: alle betrokkenen willen juist zo snel en goed mogelijk het probleem aanpakken. Het probleem zit hem in hoe we gewend zijn met elkaar te communiceren.
Als het niet gaat zoals het moet, dan moet het maar zoals het gaat
Het is dus belangrijk om vragen te stellen. Want door vragen te stellen, kom je bij het achterliggende probleem dat opgelost moet worden. Maar het is ook belangrijk wanneer je die vragen stelt. Kijk eens naar dit scenario:
Klant: Dit is m’n wens. Bouw dit 🫸
Developer: OK …🧱…🧱… ⏱️………🧱 ………⏱️………🏚️
Wat hier gebeurt, en wat ik vaak in de praktijk zie gebeuren, is dat we te snel aan het werk gaan met de instructies die we hebben gekregen. De vragen komen dan achteraf. Van mij, bijvoorbeeld, als tester. Sommige van die vragen kunnen het hele project terug naar de tekentafel sturen.
Vroeger probeerden we dit op te lossen door in een ‘waterval’ te werken. Voordat we gingen programmeren, schreven we ALLE requirements volledig uit en maakten we functionele en technische documentatie. En wat bleek? Na al dat uitvoerige voorwerk liepen we bij het bouwen van de software alsnog tegen nieuwe vragen aan.
En het beantwoorden daarvan, plus het verwerken van de antwoorden, kostte veel tijd.
Het agile tijdperk heeft in de hoek van softwareontwikkeling waar ik me in bevind gezorgd dat we minder zijn gaan opschrijven. Het tweede gebod van het Agile Manifesto zegt dan ook: “Werkende software boven allesomvattende documentatie”. En ja, werkende software is ook het belangrijkste. Maar hoe stel je vast dat je te maken hebt met ‘werkende software’?
In agile projecten is de tijdsdruk groot en dus de verleiding om iets op te leveren waar eigenlijk niemand blij van wordt. En dan maar te hopen dat je in een volgende iteratie de kans krijgt om het te verbeteren. Zo wordt ‘agile’ een synoniem voor ‘net niet’ of ‘leuk geprobeerd’. Om even terug te gaan naar ons huisje: we stellen ons een mooi nieuw huis voor, maar we eindigen zonder ramen, met de verkeerde kleur en met scheuren in de muren.
Ik ken geen enkele developer die trots is op deze manier van werken, en soms lijkt het wel of er geen uitweg is. Maar die is er wel.
Eigenaarschap
Wat als we nou, voordat we met het project of de feature beginnen, een uitgebreider gesprek hebben:
Klant: Dit is m’n wens. Bouw dit 🫸
Developer: Wat is je probleem? 🫷
Klant: 🗣️
Developer: Wat nu als ik het zo oplos?
Klant: 👍
Developer: OK 🏡
Ik moet iets opbiechten
Ik kijk vaak naar anderen als het gaat om requirements. Als tester verzin ik voor mijn gevoel niet wat er moet gebeuren. Ik kijk alleen of het werkt zoals gespecificeerd. Eigenlijk ben ik dus vaak degene die z’n schouders ophaalt en denkt “als dit is wat ze willen, zal het wel goed zijn”.
Geen goede houding, vind ik zelf. Want het gebeurt best vaak dat later in het proces problemen bovenkomen die het correct livegaan van een applicatie tegenhouden. En was het niet mijn taak als tester om dat te voorkomen? Dus jij bent misschien niet degene in het team die het functioneel ontwerp maakt of de user stories schrijft. En je bent misschien niet direct verantwoordelijk voor het oplossen van de spraakverwarring, zoals de scrummaster of de product owner. Maar dat betekent niet dat je geen eigenaarschap kunt tonen en verantwoordelijkheid kan nemen. Want al heeft iedereen zijn eigen functie binnen een developmentteam, alle stakeholders hebben de verantwoordelijkheid om vragen te stellen als zaken onduidelijk zijn.
Dus wat je rol ook is, VRAAG DOOR als er iets besproken wordt dat je niet snapt. Want waarschijnlijk ligt het niet aan jou, maar heb je óf meer informatie nodig om je werk te kunnen doen, óf je bent een probleem op het spoor dat, dankzij jouw vraag, in een vroeg stadium opgelost kan worden. Haal dus niet je schouders op, maar zorg dat je de ‘vraag achter de vraag’ snapt.
Een klant is niet tevreden met de zoekfunctie in een applicatie en vraagt: “Kunnen jullie niet ‘google-zoeken’ inbouwen?” Het developmentteam vindt dat geen goed idee, maar komt met de suggestie om ‘fuzzy search’ aan te zetten in de zoekvelden en dit snel uit te rollen naar de klant.
Probleem opgelost? Waarschijnlijk niet
Want heeft het team onderzocht waarom de klant ontevreden is met de zoekfunctie? Begrijpen we volledig wat de klant bedoelt met ‘Google search’ en hoe goed is onze vertaling naar ‘fuzzy search’? Misschien heeft de klant wel veel meer aan betere filters.
Het antwoord zou hier dus zijn om samen met de klant naar de zoekfunctie te kijken, uit te vinden in welke gevallen de resultaten tegenvallen en dan pas op zoek te gaan naar een technische oplossing. En natuurlijk aan de klant te vragen wat ze precies bedoelen met ‘Google search’.
Heb geduld met elkaars vragen
Vaak vragen we niet door omdat we een ander niet tot last willen zijn. En vaak reageren we ongeduldig op vragen naar – voor ons – de ‘bekende weg’. Daar moeten we mee stoppen.
Heb geduld met elkaars vragen. Doe je best om de ander echt te begrijpen. En realiseer je daarbij dat het misschien lijkt of je allemaal dezelfde taal spreekt, maar dat de verschillen in ‘dialecten’ van developers, testers, product owners en businessgebruikers soms zo groot zijn dat het lijkt of je aan het bouwen bent aan een nieuwe toren van Babel.
Zoek dus eerst naar gezamenlijke termen, zodat je elkaar begrijpt. Doe oprechte moeite om elkaars taal te leren en vraag door als je iets niet snapt. Kies pas samen voor een oplossing als je zeker weet dat de bedoeling je duidelijk is. In het begin kan dit voelen als ‘moeilijk doen’ of zelfs als ‘tegenwerken’. Levert dat irritatie op? Neem dan de moeite om uit te leggen waarom je zo moeilijk doet en wat de gevolgen kunnen zijn van niet doorvragen. In mijn ervaring bouw je met dit soort gesprekken juist aan betere relaties en dat leidt uiteindelijk altijd tot betere software.
Ga voor 🏠 in plaats van 🏚️ en wie weet kom je uit bij 🏡 !
