The amazing three amigo's

Het leven van een informatie analist draait om requirements. En niet zo maar requirements; natuurlijk schrijven we allemaal goede, heldere requirements die voor iedereen in één keer te snappen zijn. Of toch niet?

The struggle is real: mensen begrijpen me niet...

Als informatie analist was ik een belangrijk deel van mijn tijd bezig met het ophalen van requirements, deze scherp op papier te zetten en deze uit te leggen aan het team. Uiteraard had het team de nodige feedback en / of vragen op de requirements en als braaf analist werden de requirements aangescherpt. Op het moment dat de gebruikersacceptatietest werd uitgevoerd, was het altijd weer afwachten of de gebruiker ook snapte hoe zijn of haar eigen requirements werkten, want natuurlijk waren de requirements SMART en helder geformuleerd!

Of toch niet? Als ik terugdenk aan hoeveel tijd er vroeger verloren ging aan het over verschillende schijven ophalen, toetsen, aanscherpen en opnieuw toetsen van requirements… Gelukkig zijn er zeer veel open deuren die we in kunnen trappen en ook voor dit probleem geldt dit. Wat nou, wanneer we de requirements niet alleen ophalen bij “de eigenaar” van de requirements, maar gewoon ervoor zorgen dat we in één keer zowel de eindgebruiker, de (DevOps) engineer alsook een tester aan tafel hebben?

In deze blog wil ik jullie meenemen in mijn ervaringen bij het zorgen dat het juiste probleem op de juiste wijze wordt opgelost, waarbij ook is nagedacht over “wat als het niet goed gaat?”

Three amigo's

Al in 2009 werd de term “The three amigo’s” gebruikt door George Dinwiddie in zijn blog If you don’t automate acceptance tests? Het idee is heel simpel (en daarom zo krachtig): zorg ervoor dat je de volgende drie rollen aan tafel krijgt
vóór, tijdens of na het realiseren van een bepaalde functionaliteit:

  • Business (Welk probleem willen we oplossen?)
  • Developer (Hoe kunnen we een oplossing voor dat probleem realiseren?)
  • Tester (Maar wat als dit gebeurt, hoe moeten we daar mee omgaan?)

Let op: ik heb het nadrukkelijk over drie rollen, niet drie personen! Wanneer het probleem dat je aan het bespreken bent bijvoorbeeld een ketenproces is waarbij twee organisaties gezamenlijk een processtap uitvoeren, dan is het natuurlijk het handigste wanneer je van beide organisaties kennishouders aan tafel kunt krijgen. Je wilt een zo’n breed mogelijk blikveld aan tafel hebben. Wat je typisch in zo’n gesprek scherp wilt krijgen is wat gaan we doen, en hoe weten we wanneer het op de juiste manier gedaan is? Dit zijn typisch ook vragen die je als gedelegeerd product owner scherp wilt krijgen, dus ook daar is het een handige aanpak.

Voorbeelden tot het duidelijk is

Los van de vorm die je kiest om uiteindelijk de te realiseren oplossing en de acceptatiecriteria te beschrijven, is het doel natuurlijk wel dat je het met de Three Amigo’s eens bent over dat iets duidelijk is. Maar, wat dan als het niet duidelijk is? De makkelijkste manier om iets uit te leggen, is door gebruik te maken van voorbeelden. Natuurlijk moeten dit dan wel voorbeelden zijn waarin de ander zich kan verplaatsen, want anders zal je eerder voor verwarring zorgen in plaats van duidelijkheid scheppen. Door de voorbeelden ook met de Three Amigo’s op te stellen en door te spreken, zullen deze voorbeelden aansprekend en duidelijk zijn voor zowel het business perspectief, het development perspectief alsook het test perspectief.

Benodigde tooling

Het mooie van deze aanpak is, dat je in principe helemaal geen tooling nodig hebt om het toe te passen. Je kunt toe met een flipover, wat markers, sharpies en een stapel geeltjes. Of blauwtjes, of rozetjes, net wat je favoriete sticky note kleur dan ook is. De kunst zit hem er in om een aantal zaken scherp te krijgen:

  • De te realiseren functionaliteit, in relatie tot het op te lossen probleem.
  • Wanneer is de te realiseren functionaliteit goed genoeg?
  • Is voor iedereen duidelijk wanneer aan een acceptatiecriterium wordt voldaan?

De te realiseren functionaliteit

Uiteraard zal de te realiseren functionaliteit landen in een of meer user stories. Door deze stories te schrijven vanuit business perspectief met hierin het op te lossen probleem verwerkt, zal de business value van de user story eenvoudiger te herleiden zijn. Laten we eens kijken hoe we dit met een voorbeeld die ik ontleen aan de Wmo waarbij een factuur voor aan een burger geleverde hulpmiddelen, kunnen verduidelijken.Dit kan met de user story in de bekende vorm

Door met de Three Amigo’s het op te lossen probleem zo duidelijk neer te zetten, help je de development en test rol om mee te denken hoe dit probleem opgelost kan worden, wat eventuele valkuilen of “wat als…” situaties kunnen zijn.

 

Wanneer is de te realiseren functionaliteit goed genoeg?

Het is uiteraard zeer belangrijk om te weten wanneer het probleem dat je probeert op te lossen, ook daadwerkelijk opgelost is. Dit kun je het beste in scherpe, SMART, acceptatiecriteria borgen bij de user story. Dan is later voor heel het team duidelijk  waaraan de oplossing moet voldoen.

Denk aan acceptatiecriteria als

  • Een factuur voor hulpmiddelen, waarbij voor de betreffende burger geen passende beschikking is afgegeven, is automatisch afgewezen.
  • Wanneer een factuur voor hulpmiddelen automatisch is afgewezen, zal de leverancier van het gefactureerde hulpmiddel automatisch geinformeerd zijn.
    • De automatische afwijzing is binnen 5 seconden verzonden. Etc.

Is voor iedereen duidelijk wanneer aan een acceptatiecriterium wordt voldaan?

En misschien belangrijker, wanneer niet?

Hier ben je nadrukkelijk op zoek naar edge cases, maar ook naar hiaten in de bedachte oplossing, of zaken die nog niet duidelijk zijn. Het helpt, wanneer de Three Amigo’s vragen die ze hebben gewoon stellen, maar deze omgebogen worden naar een voorbeeld. Een voorbeeld aan de hand van het hierboven genoemde acceptatiecriterium:

 

Een factuur voor hulpmiddelen, waarbij voor de betreffende burger geen passende beschikking is afgegeven, is automatisch afgewezen.

 

Typische vragen zouden kunnen zijn, “wanneer is een beschikking passend?”, “Welke eigenschappen van een factuur neem ik mee bij het beoordelen of een beschikking passend is?”. Maar ook: “Wat als de leverdatum op de factuur op de einddatum van de beschikking ligt?”

Het antwoord op de vraag “Wanneer is een beschikking passend?”, zal je typisch kunnen vertalen naar een of meerdere regels. Bijvoorbeeld “De productgroep waaronder het gefactureerde hulpmiddel valt, moet overeen komen met het beschikte product”, of “De leverdatum van het gefactureerde hulpmiddel moet binnen de geldigheidsperiode van de beschikking vallen”. Beide regels kun je waar gewenst met concrete voorbeelden omkleden. Dit doe je net zo lang tot het voor the Three Amigo’s helder is wat met de regel bedoelt wordt. Bij de voorbeeld regel “De leverdatum van het gefactureerde hulpmiddel moet binnen de geldigheidsperiode van de beschikking vallen” zal je typisch voorbeelden opnemen waarbij de leverdatum op de ingangsdatum van de beschikking ligt, maar ook waarbij de leverdatum op de einddatum van de beschikking ligt. Wanneer je het verwachte resultaat voor alle voorbeelden duidelijk heb opgeschreven, is de kans minimaal dat hier later nog vragen over komen.

 

Wanneer een factuur voor hulpmiddelen automatisch is afgewezen, zal de leverancier van het gefactureerde hulpmiddel automatisch geinformeerd zijn. 

 

Typische vragen hier zouden kunnen zijn, “Hoe wordt de leverancier geinformeerd?” of “Wat als het informeren niet lukt?”

Wanneer doe je dit?

In principe is het totaal niet nodig om op vaste momenten met The Three Amigo’s bij elkaar te komen. Sowieso is dit lastig, omdat bij verschillende problemen ook steeds weer andere mensen kennis hebben van hoe de business het probleem ervaart en welke oplossing voor hun waardevol zou zijn. Een vuistregel die goed werkt voor mij is: wanneer niet duidelijk is wat opgelost moet worden, of op welke manier, probeer dan in een “Three Amigo’s setting” de zaken scherp neer te zetten. Zoals gezegd, je hoeft geen ingewikkelde tooling in te zetten, dus het volstaat om te zorgen voor een plek waar je met een klein gezelschap prettig met elkaar kunt sparren over het op te lossen probleem. Hierbij is het wel fijn als je een whiteboard / wall / flipover hebt, zodat je direct zaken scherp kunt noteren.

Oké, helder. En nu?

Je hebt op een goede manier duidelijk welk probleem op welke wijze wordt opgelost, wanneer de oplossing goed genoeg is èn hoe je kunt meten dat de oplossing ook daadwerkelijk goed genoeg is. Dit is natuurlijk super handige informatie om vast te leggen bij je user story. Maar denk je eens in: de story is maanden geleden al naar productie gegaan, en nu komen er, vanuit verschillende leveranciers van hulpmiddelen, bij de WMO medewerker van de gemeente meldingen binnen dat facturen ten onrechte automatisch worden afgekeurd. Je wilt dan niet oude user stories nalopen, om te zien wat de acceptatiecriteria ook al weer waren. Natuurlijk zijn er unittests en is de code goed gedocumenteerd, maar de functionele afwegingen liggen daar niet altijd in vast.

Ik vind het zelf altijd prettig om te zorgen voor living documentation. En het liefst heb ik deze dan ook beschikbaar voor iedereen binnen de gebruikersorganisatie maar natuurlijk ook binnen het (DevOps) team. Waarom? Omdat je dan maximale  transparantie hebt over de functionele keuzes die gemaakt zijn, want die leiden tot duidelijke afgebakende regels. Het biedt ook mogelijkheden om inzicht te geven in hoeverre het product ook netjes voldoet aan de regels; hiertoe zul je dan wel tooling moeten gaan inzetten die wat verder gaat dan geeltjes (of blauwtjes, of rozetjes) op een flipover… Hier ga ik graag in een volgende blog dieper op in!