Zeg ‘nee’ tegen onmogelijke opdrachten
Infinite Velocity maakt het mogelijk om nieuwe softwareversies als continue stroom te leveren. Onze Infinite Velocity Whitepaper beschrijft de trends en succesfactoren voor ‘Continuous Delivery’. Eén van de succesfactoren zijn software professionals die ‘nee’ zeggen. ‘Nee’ tegen collega’s die het onmogelijke van je vragen. Planningen, resultaten en activiteiten waarvan je bij voorbaat al weet dat je teleur gaat stellen.
Auteur:
<Een scenario zonder ‘nee’>
De deadline nadert: nog niet alle functionaliteiten zijn gereed. De product Owner vraagt je: ‘komt het af’, je antwoord met ‘ja, ik denk het wel’. De Product Owner hoort ‘ ja, het gaat lukken’. Op basis van dat ‘ja’ maakt de collega een plan en geeft hij het management commitment.
Nog een week tot de deadline: de Product Owner vraagt opnieuw ‘komt het af. Je zegt nu ‘we gaan het proberen’. Er zijn immers problemen met een stuk software in combinatie met een oauth2 authenticatie. De Product Owner schrikt hiervan. Hij heeft commitment afgegeven en de “marketingafdeling blijkt een campagne gestart. De Product Owner vraagt kritisch door waarom het niet vóór de deadline afgemaakt kan worden. De software Engineer somt activiteiten op die moeten gebeuren, zoals het schrijven van automatische tests, documentatie en security checks. In die discussie stuurt de Product Owner aan op het schrappen van kwaliteitsstandaarden in plaats van features. Ook vraag hij je om in het weekend over te werken om de laatste features te realiseren, zonder automatische tests, architectuurstandaarden en documentatie.
De deadline: de verstandhouding tussen collega’s en de product owner is inmiddels flink verstoord. Het zat tegen, de features zijn niet gerealiseerd. Het MT zit met de handen in het haar. ‘Hoe heeft dit kunnen gebeuren?’, stellen ze zichzelf de vraag.
<Waarom is ‘nee’ zo belangrijk?>
Bovenstaand scenario komt (te) vaak voor. ‘Nee’ zeggen en collega’s (tijdig) teleurstellen: het blijft moeilijk. Vooral als je eigenlijk in een eerder stadium de druk al voelt en geen ‘nee’ meer durft te zeggen.
‘Nee’ betekent meer dan het gaat niet lukken. ‘Nee’ betekent ook dat je de Product Owner tijdig te kans geeft om zijn omgeving te informeren, zodat er geen valse verwachtingen ontstaan. ‘Nee’, betekent dus, ‘Nee, het gaat niet lukken, en waarde Product Owner ik betrek je erbij, zodat je ruimte hebt om je belanghebbenden juist te informeren. Betrekken, zodat je met mij als vakman kunt overleggen over de risico’s en maatregelen’. ‘Nee’, zorgt ervoor dat je omgeving de kans heeft om tijdig te acteren. Als software engineer mis je met ‘we gaan het proberen’ de confrontatie. Verwachtingen zijn niet afgestemd en zorgen later voor een nog veel grotere confrontatie.
<Waarom ‘nee’ zeggen ook de softwarekwaliteit verbetert?>
De ‘nee’ van software engineers geeft je belanghebbenden de ruimte. Hierdoor voorkom je acteren in noodsituaties, waarbij kwaliteitseisen overboord moeten, omdat de continuïteit van het productsoftwarebedrijf in gevaar komt. Die kwaliteitseisen geven zekerheid dat de software goed is gebouwd en dat het ontwikkelteam op korte- en lange termijn met vergelijkbare snelheid blijft ontwikkelen. ‘We gaan het proberen’ en vergelijkbare opmerkingen leiden tot suboptimale beslissing met nadelige gevolgen voor het product.
<Gevolgen van het gebrek aan ‘nee’>
Zonder duidelijke ‘nee’ draag je als team later de consequenties. Met je team dagen, weekenden en soms weken overwerken en frustraties om onmogelijke deadlines te halen. En als het dan toch lukt, zijn jij en je team de helden. Maar held waarvan? Wat heb je bereikt voor de organisatie? Functioneel werkt het in de testomgeving maar wat is de zekerheid? Je hebt immers niet goed getest, automatische regressie is niet meer compleet en je loopt het risico tot nog veel meer overwerk door productieproblemen. Productieproblemen, terwijl de volgende deadline alweer voor de deur staat. De software engineers zijn druk met het oplossen van bugs, welke weer nieuwe bugs introduceren. Daarnaast besteden ze minder tijd aan nieuwe features, welke ook nog moeilijker zijn te implementeren tot de opgebouwde ‘cruft’.
<Conclusie>
‘Nee’ is de verantwoordelijkheid van de software engineer en een tijdige start tot een goed gesprek. Het verpakken van ‘nee’, zodat je de confrontatie mist levert misschien winst op korte–termijn op, maar op langere termijn levert het slechts verliezers.
De tekortkomingen zorgen op later in het traject voor meer en grotere problemen. Software engineer, zeg dus vaker ‘NEE’. Wil je meer weten over Infinite Velocity en over alle factoren om Infinite Velocity te bereiken? Download dan onze whitepaper Infinite Velocity!