Maak de perspectieven van het team concreet

Zoals ik in mijn perspectieven blog beschreef, zijn er naar mijn mening geen waarheden, alleen perspectieven (een soort persoonlijke waarheid). En of je het nou met me eens bent of niet, binnen de IT ontstaan vaak communicatie problemen vanwege aannames. Aannames die gemaakt worden omdat wat jij in je hoofd hebt, natuurlijk een ‘waarheid’ is voor iedereen. Dus uiteraard hoef jij dit niet uit te spreken, want duuhh… iedereen weet dit allang.

Naar mijn mening zijn aannames prima, ZOLANG je ze bespreekt met de mensen om je heen. Aannames die je voor jezelf houdt, zorgen bijna altijd voor problemen. Meestal ook voor problemen in de software.

Maar hoe ga je daar nou mee om? Het is lastig om te weten welke aannames je dagelijks maakt. Want het zijn er nogal wat. Uiteindelijk gaat het om het volgende:

Maak de perspectieven van het team concreet

Vraag jezelf hier altijd bij af: “Mag ik er zomaar vanuit gaan dat iedereen hier op dezelfde manier over denkt als ik?”. Let met name op het stukje ‘Mag‘. Want het gaat uiteindelijk om risico’s. Wat is het risico als deze aanname onuitgesproken blijft?

Het ontwikkelframework ‘Scrum’ gebruikt de ‘Definition of Done’ en ‘Definition of Ready’, om concreet te maken wanneer software klaar is om aan te werken, en wanneer software klaar is om op te leveren.

Maar voor veel teams houdt het hierbij op, en dan zie je alsnog dat er (met name bij nieuwe teams) verschillende problemen ontstaan. Ik noem hieronder een paar voorbeelden van onderwerpen die je als team concreet zou willen maken om gevaarlijke aannames te voorkomen:

  • DoD / DoR. Zoals hierboven al kort genoemd, Definition of Done en Definition of Done gebruik je om concreet te maken wanneer software klaar is om aan te werken en wanneer software klaar is om op te leveren.
  • Werkafspraken. Hoe houden wij ons werk bij? Gebruiken wij een digitaal platform of een fysiek bord? En hoe houden wij deze bij?
  • Kwaliteit. Als je op google de term opzoekt, lees je: “de mate waarin datgene goed is of aan bepaalde normen voldoet”. Dit geeft al aan dat het voor ieder team belangrijk is om te bepalen om welke normen dit gaat. Want anders kan ik je garanderen dat iedereen in het team een ander beeld zal hebben van kwaliteit.
  • Waarde. Binnen de context van Agile wordt er regelmatig over waarde gesproken. Ook weer zo’n ambigue term. Naar mijn mening is ‘zoveel mogelijk software opleveren’ niet gelijk aan waarde. Toch lijken veel teams daarop te sturen. Scrum helpt daar ook heerlijk mee met velocity charts enzo…
  • Development strategie. Design patterns die gebruikt worden? Wat is de test strategie van het team? Wat is de branching strategie en hoe gebruiken we onze pipeline?
  • Individuele skills. Waar is ieder individu binnen het team goed in? En wat vinden zij leuk? Dat iemand ‘Senior developer’ is, zegt vrij weinig over zijn specifieke competenties.

En er zijn er waarschijnlijk nog veel meer. Maar het is verstandig om aandacht te besteden aan ieder onderwerp, omdat je anders het risico houdt dat hierover aannames onuitgesproken blijven.

Het beste uiteindelijk is om iets visueels uit te werken dat je kunt ophangen in je eigen teamkamer (zorg voor een teamkamer als je die nog niet hebt). Hierdoor gaan de keuzes en afspraken die hierbij gemaakt zijn meer leven in het team, en kunnen collega’s elkaar beter wijzen op afspraken die niet nagekomen worden.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *