Kwintessens
Geschreven door Yves Schelpe
  • 3111 keer bekeken
  • minuten leestijd
  • Reacties

21 oktober 2022 Over deadlines
Deadlines zijn een illusie van controle en geven een vals gevoel van veiligheid. Bovendien bieden ze geen garantie op kwaliteit, sterker nog, vaak werken ze minder kwaliteit in de hand. Sterk ingeburgerd in ons (professioneel) leven – denk maar aan de talloze afspraken in je (virtuele) agenda, de 'milestones' van een project of organisatie, de rigide en gedetailleerde planningen die vooraf gemaakt worden maar vaak nooit gehaald worden ... Ik wil hier een lans breken voor flexibiliteit, om creatiever na te denken en onderling meer te communiceren met elkaar.
_Effectiviteit van deadlines
'Een punt in de tijd waarop "iets" afgerond moet worden', is een veelgehoorde definitie voor het begrip deadline. Een gevaar in het hanteren van zulke definitie is dat ze kan leiden tot meer angst, stress en zelfs een lak aan interesse tegenover de taak. Sommige strakke planningen met daarin verschillende op elkaar volgende deadlines laten vaak ook weinig ruimte tot autonomie, zelfregulatie en creativiteit. Indien we dit soort deadlines waarderen met bonussen of scores, dan kan dat de extrinsieke motivatie in de hand werken, en de intrinsieke motivatie naar de achtergrond duwen. Een van de gevolgen daarvan kan zijn dat het 'conformiteit' en de gevaren die daaraan zijn gelinkt aanwakkert.
Erg effectief kan je dat niet noemen, en ik weet dat sommige mensen verkiezen onder deadlines te werken en dat individueel waarschijnlijk ook zeer efficiënt kunnen. Maar wanneer we dit bekijken op langere termijn – en vooral in team- of organisatieverband – dan kan dat al problematischer worden voor de kwaliteit en effectiviteit, ongeacht de efficiëntie van het individu. Men vergeet misschien enkele zaken, of diept ze niet grondiger uit, of andere(n) moeten langer wachten op bepaald werk – zaken die de effectiviteit en kwaliteit en de eventuele deadlines die daarop volgen bemoeilijken.
Enkele voorbeelden kan je vinden in de software-industrie: wanneer men vraagt een implementatie te maken tegen een bepaalde termijn kan een persoon dat doen, zonder rekening te houden met de deadlines die erop volgen. Maar op dat moment is management en de persoon in kwestie blij deze deadline reeds gehaald te hebben. Volgende deadlines kunnen zwaarder worden, omdat er in het opgeleverde werk geen rekening gehouden werd met eventuele latere complexiteit, want dat was niet voor deze deadline, maar een probleem voor later ... Dat soort mentaliteit kan je ook zien bij schoolstudies, patiëntenzorg, en ongetwijfeld in uw professionele activiteiten of dagelijks leven.
Natuurlijk schets ik het hier zwart-wit, er zijn ook positieve elementen, maar dan moeten we een andere definitie hanteren die een andere mentaliteit omtrent deadlines mogelijk maakt.
_Wendbaarheid en communicatie
'Een punt in de tijd waarop we denken dat "iets" afgerond zal worden, waar we kunnen tonen en duiden hoever we staan met "iets"', is een andere definitie dan in vorige paragraaf. Het is wendbaarder en geeft automatisch al wat meer ruimte aan mensen dat we niet verwachten dat het werk op dat moment al klaar moet zijn. We kunnen dit 'flexibele' of 'softe' deadlines noemen, en als we die goed hanteren zouden we daarover zelfs niet op het eindstip van de deadline moeten communiceren maar reeds tijdens het uitvoeren melding kunnen maken van progressie.
Communicatie speelt hier een grote rol, zowel van de personen die moeten werken aan de deadline, als bij de persoon die de opdracht geeft. Een gesprek over verwachtingen zal leiden tot kwalitatiever werk en meer inzicht bij beide partijen. Hieronder de vier kernwaarden uit een werkwijze die het 'manifest voor agile softwareontwikkeling' genoemd wordt, maar die volgens mij ook toepasbaar zijn op veel andere sectoren – en daarom heb ik ze een beetje geherformuleerd.
Ten eerste: We verkiezen mensen en hun onderlinge interactie boven (blind) processen volgen en hulpmiddelen (of tools). Hoewel we waardering hechten aan hetgeen vermeld staat aan de rechterzijde, hechten we méér waarde aan wat aan de linkerzijde wordt genoemd. Processen zijn er niet zomaar, ze zijn vaak ontstaan uit optimalisatie, maar in een wereld die constant wijzigt door externe of interne factoren zullen processen ook aangepast moeten worden met kritische reflectie. Het inzicht en de kritiek op die processen kan je alleen maar bereiken als je een context creëert waarin mensen daarover met elkaar in gesprek kunnen gaan, en kunnen experimenteren om zo tot nieuwe en aangepaste vormen van samenwerken te komen. Dit geldt evenzeer voor de hulpmiddelen of tools waarmee we werken – is een hamer nog wel het juiste instrument, of kiezen we beter voor een schroevendraaier? Is Excel nog wel werkbaar, of kiezen we best voor een andere tool? De essentie is dat processen en tools niet bepalend mogen zijn voor je proces en dat die ook aan verandering onderworpen zijn – want voor je het weet ben je lid van een soort cargocult.
Een volgend punt betreft het belang van samenwerking met de klant boven contractonderhandeling. Hoewel contracten/afspraken waardevol zijn, is flexibiliteit langs beide kanten evenzeer belangrijk. Eens je iets hebt vastgelegd en er niet van kan afwijken, kan dat voor problemen zorgen. Ruimte creëren om in dialoog te gaan en samen te werken kan trager lijken en de deadline overschrijven, maar op lange termijn wel de kwaliteit en onderlinge verstandhouding tussen beide partijen bevorderen. Denk bijvoorbeeld aan diensten die moeten samenwerken, waar de ene moet wachten op de ander. Indien dit star vastligt, is het makkelijker om met de vinger te wijzen naar de dienst in plaats van een context te bieden waarin je samen op zoek kan gaan naar een oplossing, of tenminste erover praten en zo een verstandhouding en inzicht, tot zelfs empathie opwekken bij de ander waarom men moet wachten.
Een derde factor is het inspelen op verandering boven het volgen van een plan. Wanneer je niet open staat voor wensen van de omgeving rond je en de planning strak volgt, kan dit leiden tot werk dat niet meer relevant is op het moment van oplevering. Een planning is nuttig, maar een te lange en gedetailleerde planning kan leiden tot irrelevantie – daarom is een context nodig waarin ook planning herzien kan worden en verandering erkend als iets dat kan voorvallen tijdens een proces. Ook indien deze verandering extra complexiteit met zich zou meebrengen, of extra kosten. Die argumenten zijn vaak ondergeschikt omdat het opgeleverde werk toch minder waarde zou hebben en uiteindelijk meer zal kosten dan wanneer je de planning zal aanpassen aan een wereld in verandering. Dit derde punt is eigenlijk voor een groot deel het eerste punt toepassen op je eigen planning van een project: de 'tool' planning is ook onderhevig aan verandering als ze relevant wil blijven.
Regelmatig stukjes werk opleveren, feedback verzamelen en communiceren over moeilijkheden en struikelblokken (soms reeds voor de deadline) is vaak effectiever op lange termijn. Communicatie en het bieden van autonomie (vertrouwen, dat mensen hun werk doen) zijn hierin cruciale elementen.
_Conclusie
Ik pleit er niet voor om deadlines per se af te schaffen, maar wel om er anders mee om te gaan. De wereld is constant in verandering – denken op lange termijn is nodig maar vraagt ook tijdig momenten van kritische reflectie om ervoor te zorgen dat we niet eindigen met werk dat nutteloos is op het einde van de rit. Vasthouden aan 'harde' deadlines levert vaak minder kwaliteit en samenwerking in de hand en geeft daarom een vals gevoel van zekerheid en controle dat op de lange termijn zuur kan opbreken.
Hoewel we soms echt niet rond 'harde' deadlines kunnen (in bepaalde sectoren of werk is dat niet mogelijk), is het vaak zo dat er wel een middenweg gevonden kan worden als we hierover in gesprek gaan met elkaar, zelfs in situaties waarin we denken dat het een 'harde' deadline is. Een context creëren die het mogelijk maakt dat mensen communiceren over 'hoe' en 'waarom', stukken werk kunnen opleveren in plaats van het geheel als een 'big bang', is essentieel om te kunnen rekenen op begrip en empathie van anderen. Hiermee rekenen we op de creativiteit van mensen om problemen met elkaar op te lossen (autonomie te stimuleren), en versterken we de kans om stress te verminderen en tevredenheid over afgeleverd werk te vergroten en daardoor trots en intrinsieke motivatie te stimuleren.
De kernwaarden en de twaalf geformuleerde principes van het 'manifest van agile softwareontwikkeling' gelden niet enkel voor de softwaresector, maar zijn toepasbaar in veel domeinen en sectoren.
Kwintessens
Yves Schelpe is analist en programmeur overdag, muzikant bij nacht (als Psy'Aviah), amateur simracer en fotograaf wanneer er nog tijd rest.
_Yves Schelpe -
Meer van Yves Schelpe

_Recent nieuws

Bekijk alle nieuwe berichten

_Populair nieuws

Bekijk meer populair nieuws