Ineke zit met haar handen in het haar. Ze heeft een gesprek gehad met de afdeling ‘Achterstanden’ en is geschrokken van de performance problemen die ze ervaren met haar product AdminForce. Over drie dagen gaat het PI event weer van start en ze wil met haar teams zo snel mogelijk aan de slag, maar ze kunnen er maar 20% van hun tijd aan besteden. Met het management is deze afspraak gemaakt. Naast dit blok is er ook al 20% gereserveerd voor regulier onderhoud, dus dit was echt het maximum. De rest van de tijd moet besteed worden aan een aantal features uit het portfolio.

Een backlog met veel soorten problemen

Ineke zou het liefst twee volledige sprints aan de performance problemen besteden. Een aantal techneuten heeft al het een ander uitgezocht en ze verwachten dat ze in die periode de belangrijkste issues structureel kunnen wegnemen. Daarmee zou het performance issue van de baan zijn. Nu ze maar 20% mogen besteden zullen ze al gauw tien sprints nodig hebben en Ineke weet niet wat er nog allemaal tussendoor gaat komen in die lange periode. Ze heeft het met de product manager en de solution manager besproken, maar die hebben aangegeven dat dit echt het maximum is. Zij hebben met hun stakeholders al afspraken gemaakt en ze kunnen het niet maken om die punten nu naar achteren te schuiven.

Drie structurele problemen zitten in de weg

Ineke heeft als product owner de taak om de waarde voor de business te maximaliseren. Dat lukt voor haar gevoel nu niet, omdat ze te maken heeft met drie structurele problemen. Het eerste en het tweede probleem hangen nauw moet elkaar samen en gaan over een (te) complexe structuur en een beperkt mandaat.

In scrum is de product owner ook echt eigenaar van het product en heeft het volledige mandaat om al het werk te prioriteren. De product owner ontwikkelt een visie op het product en voert deze visie samen met het team uit. In de organisatie van Ineke wordt gewerkt met meerdere hiërarchische lagen. Hiervoor is gekozen vanwege de omvang en complexiteit van het product. Er zijn product eigenaren op strategisch, tactisch en operationeel niveau. De wet van Conway zie je hier in werking: er is een directe relatie tussen de complexiteit van de organisatie en de complexiteit van het product.

Ineke is product owner op operationeel niveau. De solution manager en de product manager opereren samen met de management teams op strategisch en tactisch niveau. Zij zetten de richting uit en maken dit concreet door epics en features te prioriteren. Daarmee bepalen ze ook wat de prioriteiten voor Ineke zijn. Het uiteindelijke mandaat dat Ineke heeft, beperkt zich hierdoor tot de details van de uitvoering. Hierin zie je de scheiding terug van het denken en doen, die als basis dient in de theorieën van zowel Taylor in het scientific management als van Weber in zijn bureaucratische regime.

Stroperige bureaucratie

Het is een bekende wetmatigheid dat de snelheid en de kwaliteit van besluitvorming afnemen met het aantal hiërarchische lagen. Dit fenomeen wordt nog eens versterkt in kennisintensieve organisaties waar de scheiding tussen denken en doen in stand wordt gehouden. De organisatie van Ineke probeert het zich makkelijker te maken door met reserveringen te werken voor verschillende activiteiten. Daarmee wordt haar regelruimte echter behoorlijk ingeperkt. Hierdoor wordt het voor haar niet alleen lastiger om zoveel mogelijk waarde te leveren, maar komt ook haar derde probleem om de hoek kijken: een gebrek aan focus. Multi-tasken maakt haar teams nog langzamer.

Multi tasken is slecht voor je time to market

Meerdere taken tegelijk uitvoeren lijkt efficient, maar meestal is het niet meer dan een manier om zoveel mogelijk stakeholders proberen tevreden te houden. Je kunt dan immers tegen ze zeggen dat er aan hun probleem gewerkt wordt. In onderstaande schets zie je wat het effect is. De taken A, B en C zijn alle drie een week werk. Als je ze na elkaar uitvoert, dan ben je na een week met A klaar. Na de tweede week is B af en na de derde week taak C. In de andere situatie is er sprake van multi tasking. Je werkt dan eerst een dag aan taak A, dan een dag aan B en vervolgens een dag aan taak C. Daarna is A weer aan de beurt en dan weer B etcetera. Je ziet dat je pas op de woensdag van de derde week met A klaar bent, donderdag is B af en vrijdag C. De kans is zelfs groot dat je pas ergens in week vier klaar zult zijn, want het continu switchen tussen de taken kost je ook nog extra tijd.

Als je dit vraagstuk alleen bekijkt vanuit de efficiëntie van het scrum team dan lijkt er niet zoveel aan de hand. De reden dat dit toch een ernstig probleem is, heeft te maken met de time to market. Deze is in de tweede situatie gemiddeld genomen meer dan twee keer zo lang. Als klant moet je veel langer op je spullen wachten en financiën zal gaan klagen over de return on investment (ROI). Om in lean termen te spreken: er is geen sprake van flow in het productie proces en dat veroorzaakt enorm veel verspilling.

Stap voor stap verbeteren

De organisatie van Ineke zal moeten werken aan het vereenvoudigen van het product en de structuur die daar bij past. Dit is geen gemakkelijke opgave, maar wel noodzakelijk. Pas als dat geregeld is, kun je het echt gaan hebben over het mandaat. Natuurlijk kunnen er best al wat afspraken gemaakt worden over het aanbrengen van focus, maar dan moet je gaan strijden tegen allerlei tegengestelde belangen, overtuigingen, machtsposities en technische en functionele complexiteit. Die strijd ga je niet zomaar winnen en dus blijft Ineke voorlopig nog wel even last houden van gedoe.

De presentatie was kleurrijk en creatief én ik voelde me er ongemakkelijk bij. De twee consultants, van het gerenommeerde adviesbureau hadden in hoog tempo de zeventig slides zelfverzekerd gepresenteerd. Hij strak in het pak, zij in een representatieve rok en blouse. Zij hadden vaker met dit bijltje gehakt. Aan het eind gaven ze wat extra gas om het binnen het uur te kunnen afronden. Petje af. Wat mij verontrustte was het enthousiasme van de luisteraars. Zou de organisatie hier echt mee geholpen zijn?

Bewezen aanpak

Het bestuur van de organisatie had het consultancybureau uitgenodigd om hun voorstel te presenteren voor de transformatie die het bedrijf moest ondergaan. Ik zat erbij als vertegenwoordiger van de afdeling die een flinke bijdrage zou moeten leveren aan de transformatie.

De presentatie startte met een opsomming van de vele succesvolle veranderingen bij andere organisaties. De logos van deze ondernemingen prijkten op maar liefst twee slides. Vervolgens herhaalden de consultants het doel van de verandering nog eens, waarbij zij putten uit de teksten van het Request for Proposal. De bestuurders herkenden dit en waren zichtbaar aangenaam verrast. De aanpak voor het realiseren van dit doel bestond uit enkele stappen die deskundig werden toegelicht. Ik noem er een paar.

1.      Target Operating Model

Een van de eerste stappen was het zorgvuldig ontwerpen van het Target Operating Model (TOM). Het consultancybureau zou hierin de leiding nemen vanwege haar uitvoerige expertise. De opdrachtgever zou hier natuurlijk bij worden betrokken omdat het productieproces, dat centraal stond, vrij gecompliceerd was. De belasting van de organisatie zou echter beperkt zijn: het ontzorgen van de opdrachtgever was het leidende motief. Deze had immers een nieuw TOM besteld en het was de verantwoordelijkheid van het consultancybureau om dit in overeenstemming met de specificaties te leveren.

2.      Organisatiediagnose

Om een veranderplan te kunnen opstellen was het belangrijk om gedetailleerd inzicht te krijgen in de huidige stand van zaken. Een goede organisatiediagnose zou voorzien in deze informatie. Het consultancybureau had haar eigen referentiemodel ontwikkeld waaraan zij de huidige organisatie zou worden getoetst. Samen met het TOM beschikten zij aan het eind van deze fase over een IST en een SOLL situatie. De kunst was nu om op beheerste wijze en binnen de gestelde periode van drie jaar het verschil te overbruggen.

3.      Veranderplan

Een vervolgstap bestond uit het toesnijden van het standaard veranderplan op de specifieke organisatie van de opdrachtgever. Het plan zou antwoord geven op de vraag: hoe zorgen we ervoor dat we beoogde situatie bereiken vanuit de huidige toestand van de organisatie? Welke interventies moeten wanneer en op welke plekken in de organisatie worden gepleegd om de gewenste verandering te verkrijgen? De consultants gaven voorbeelden van structuurinterventies, het bij- en omscholen van medewerkers middels training en coaching, een leiderschapsprogramma en een cultuurprogramma om het gewenste gedrag te bevorderen. De planning bevatte beargumenteerde buffers voor het opvangen van onvoorziene omstandigheden.

4.      Implementatie

Met deze zorgvuldige voorbereiding, zo legden de consultants uit, kon de implementatie met vertrouwen tegemoet worden gezien. De interventies zouden conform veranderplan worden uitgevoerd en waar nodig worden bijgestuurd om maximaal effect te sorteren. Er zou bijzondere aandacht zou worden geschonken aan eventuele weerstand van de werkvloer. Het consultancybureau stelde voor prestatie-indicatoren af te spreken met de opdrachtgever. Een alerte bewaking ervan maakte een beheerste transformatie mogelijk. De opdrachtgever zou niet voor verrassingen komen te staan en kunnen vertrouwen op een succesvol resultaat. Zoals alle andere klanten.

De consultants zeiden precies de juiste dingen, spraken de taal van het bestuur, sloten aan op hun manier van denken. De aanpak klonk als een klok. De boodschap en de zelfverzekerde wijze waarop de consultants deze presenteerden maakten een solide indruk en gingen erin als Gods woord in ouderlingen. De reputatie van dit gerenommeerde consultancybureau fungeerde als een verzekeringspremie voor het bestuur. De laatste dia van de presentatie was een afbeelding van een grote groene knop. ‘U hoeft maar op deze knop te drukken en wij gaan voor u aan het werk!’, sloten de consultants hun verhaal af.

Ontnuchterende eenvoud

‘Er is hier hard gewerkt’, zei de adviseur van het tweede bureau voor hij zijn presentatie na de copieuze lunch aanving. ‘Is het ok als we deur laten openstaan?’ Enkele directieleden trokken hun wenkbrauwen op. Een directiekamer met de deur open voelde niet goed, dat was nog nooit vertoond. Ze dachten er het hunne van, maar lieten het toch toe.

De adviseur, weliswaar netjes gekleed, maakte een wat rebelse indruk. Hij opende zijn presentatie met de opdracht zoals deze was verwoord in het Request for Proposal. ‘Dit vormt voor ons het wenkende perspectief, de organisatie die jullie willen zijn’. De weg er naartoe zou echter onvoorspelbaar zijn. We zouden op onze reis onverwachte belemmeringen tegenkomen en de oplossingen moesten we met elkaar ontwikkelen. Daarom stelden zij een Kata-aanpak voor. Een methode die door Toyota was ontwikkeld en die haar al decennia succesvol maakte. De adviseur gaf een korte inleiding in de methode en lichtte de begrippen ‘volgende doeltoestand’, ‘het doorgronden van de huidige toestand’ en ’de eerstvolgende stap’ toe. De Toyota Kata methode was toegesneden op productiebedrijven en op kostenminimalisatie maar kon ook worden gebruikt voor organisaties die informatie verwerken en wendbaar moeten zijn. De aanpak van het adviesbureau bestond eruit dat iedereen in de organisatie, dus niet alleen de medewerkers maar ook het management tot en met het bestuur toe, de Kata methode zouden leren toepassen in hun werk. Training en coaching aan de hand van de concrete problematiek in het bedrijf.

Een beetje beter

‘Wat is momenteel het grootste probleem in uw bedrijf?’, vroeg de adviseur aan de algemeen directeur. Deze reageerde alert. ’Mijn mensen komen hun beloften niet na’. De directeur IT schoof ongemakkelijk op zijn stoel. ‘Wij leveren onze producten te laat aan onze klant en ook nog eens veel te duur. Daar krijg ik klachten over’. Er ontstond een korte discussie die leidde tot een specifiekere probleemstelling. Niet iedereen droeg hieraan bij, viel op. Vervolgens vroeg de adviseur een beschrijving te geven van de organisatie die het een beetje beter zou doen dan nu. Het gezelschap zou al blij zijn als in ieder geval de belangrijkste klant het eerstvolgende product conform verwachting zou ontvangen. ‘Nu we het hier over eens zijn kunnen we interventies gaan bedenken, uitproberen en beoordelen op effectiviteit. We leren hiervan en worden er beter in’. De adviseur sloot af met een overzicht van de trainings- en coaching aanpak en de opmerking dat dit vooral een forse investering zou vergen van de mensen zelf, in tijd en in intellect.

‘Jullie concurrent presenteerde ons vanochtend een groene knop. Als we daarop drukken, zeiden zij, dan zouden zij onmiddellijk voor ons aan het werk gaan. Wanneer kunnen jullie beginnen, mochten we voor jullie kiezen?” De adviseur liet een stilte vallen keek hem verwachtingsvol aan. Na twee seconden viel het kwartje. “Ah! Jullie zijn al begonnen!”

De keuze

De directie had die dag twee verschillende voorstellen besproken. Het eerste bureau had een gedegen aanpak gepresenteerd die goed aansloot op de denkwijze van het bestuur. Zowel de inhoud als de wijze van presenteren hadden vertrouwen gewekt. De verandering was te plannen en de organisatie was maakbaar. Het tweede voorstel vertrok vanuit andere uitgangspunten. Het wenkende perspectief was duidelijk genoeg om te vertrekken, maar de reis zou veel minder goed te voorspellen zijn. De aanpak sloot hierop aan: exploratief, experimenterend, kleine stapjes, groeien met vallen en opstaan. En de organisatie zou zelf volop in actie moeten komen.

De directie koos voor het eerste adviesbureau. Dit had een reputatie van betrouwbaarheid en de werkwijze wekte vertrouwen. Het bestuur wilde ontzorgd worden. Het tweede bureau had weliswaar een interessante aanpak, maar deze viel way out of their comfortzone. En de belasting door voortdurende organisatieverbetering zou nog groter worden, terwijl zij het werk nu al niet aankonden. De keuze was niet onverwacht, maar de toekomst zal leren of de directie een verstandig besluit heeft genomen. Soms is het goed om eens iets nieuws te proberen.

De Definition of Done is een essentieel onderdeel van scrum. Ieder zichzelf respecterend scrum team heeft er een, maar er zijn maar weinig scrum teams die de Definition of Done ook echt serieus nemen. Meestal is het een wassen neus, een document voor de bühne of in het beste geval een checklist waar je best van mag afwijken als je maar een beetje een plausibele uitleg hebt.

Een limiet is er om je er aan te houden

In de Definition of Done staan de kwaliteitscriteria waar ieder opgeleverd product aan moet voldoen. Het is voor het scrum team de meetlat die bepaalt of je iets af hebt of nog niet. Deze meetlat is zo strikt dat als je er niet aan voldoet, je het betreffende item niet mag opleveren. Formeel mag je het resultaat niet eens laten zien tijdens de sprint review meeting. Dat vinden de meeste teams wel heel erg spannend en daarom wordt de Definition of Done lekker vaag gehouden, zodat je er in de meeste gevallen wel mee weg komt als de kwaliteit even wat minder is.

Wat telt is het resultaat, niet jouw inzet

Een paar maanden geleden schreef ik een blog waarin ik ervoor pleitte om procesafspraken uit de Definition of Done te halen. Van die lekker vage afspraken, dat er een peer review moet plaats vinden of dat alle testen moeten zijn uitgevoerd. Het zijn afspraken waar je alle kanten mee op kan en die je met een beetje verhaal altijd kunt afvinken. Ze zeggen echter niets concreets over de geleverde kwaliteit en daardoor geven ze ook geen enkel aanknopingspunt om te verbeteren. Dat komt omdat ze gaan over inzet en niet over resultaat, maar ook omdat ze vaak niet SMART(Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden) zijn geformuleerd.

De Olympische limiet ligt wel heel erg hoog

Als je de stap gemaakt hebt om procesafspraken uit je Definition of Done te schrappen en het is gelukt om de vaagheid eruit te krijgen, dan is er nog het gevaar van de Olympische lat. President Xi van China heeft in Peking de Olympische winterspelen geopend en de komende weken kan de hele wereld weer genieten van sporters die het beste willen laten zien van wat ze in huis hebben. Het motto van de olympische spelen is citius altius fortius en dit sneller, hoger, sterker moet de deelnemers motiveren om iedere keer weer een beetje beter te presteren. Het gaat in de topsport echter al lang niet meer om alleen maar het meedoen. Er moeten medailles gewonnen worden en het liefst een paar meer dan 4 jaar geleden. Als je mee wilt doen dan zul je moeten voldoen aan de Olympische limiet. Haal je die niet, dan doe je niet mee.

Voor veel teams wordt een kwaliteitslimiet in de Definition of Done opgesteld die op het allerhoogste Olympische niveau ligt. Een limiet waar normale stervelingen onmogelijk aan kunnen voldoen. Het is meer een Definition of Perfect. Er zijn naast de afnemers van het product namelijk nog veel meer partijen die belang hebben bij een hoge kwaliteit. Ze stellen eisen aan beveiliging, bruikbaarheid, beschikbaarheid of andere niet-functionele kenmerken. De lat wordt vaak nog een beetje hoger gelegd vanwege imago en reputatie. Eisen die vaak worden gesteld door management, ondersteunende afdelingen of de maatschappij. Denk bij het laatste bijvoorbeeld aan wet- en regelgeving. Alle eisen worden vaak met de beste bedoelingen opgesteld en aan de Definition of Done toegevoegd. En zo wordt de stapel eisen waar een team aan moet voldoen steeds maar hoger en hoger. En uiteindelijk ligt de limiet zo hoog dat alleen de allerbesten er nog aan kunnen voldoen. En dan nog alleen als de omstandigheden perfect zijn en de druk niet al te hoog is.

Nog veel belangrijker dan kwaliteit is vaak de druk op de hoeveelheid die opgeleverd moet worden. Veel organisaties verwachten van hun teams dat ze steeds een beetje beter worden en dat zich dat vertaalt in nog meer opgeleverde functionaliteit. Natuurlijk is er niets mis met beter worden waardoor je met dezelfde inspanning meer waarde kunt leveren. In de praktijk is de druk om meer te leveren echter vaak groter dan wat de teams aan kunnen en wordt de prijs betaald door consessies te doen aan de kwaliteit of, erger nog, wordt roofbouw gepleegd op de medewerkers. Teams vinden allerlei manieren om niet aan deze enorme berg eisen te hoeven voldoen. Dat gaat van negeren, de schuld afschuiven en wegredeneren tot aan verdoezelen, creatief omgaan met de regels en manipuleren aan toe. De hele trukendoos wordt open getrokken.

Iedereen wil meebeslissen

De oorzaak dat er teveel aan wishful thinking wordt gedaan, is niet de enige reden dat de Definition of Done niet de plek krijgt die hij verdient. Een andere belangrijke oorzaak is dat de eisen voor de Definition of Done van buitenaf worden opgelegd. Belanghebbenden leveren hun lijstjes in bij het team met de mededeling dat dit de eisen zijn waar ze aan moeten voldoen. Vervolgens verwachten ze dat het team wel even regelt dat ze er aan zullen voldoen. Ze houden er geen rekening mee dat iedere toevoeging of wijziging aan de Definition of Done impact heeft voor het team. Het levert extra werk op in de vorm van controles, rework of extra functionaliteit. Teams zouden dit niet zomaar mogen accepteren. Het extern opleggen van allerlei dwingende eisen aan het team is een aantasting van hun autonomie met als gevolg dat het team zich geen eigenaar voelt. Het is dan ook volstrekt logisch dat ze zichzelf daartegen beschermen door de rol van de Definition of Done te minimaliseren.

Handige tips voor een praktisch toepasbare Definition of Done

Om een goede start te maken zouden teams eerst moeten inventariseren wat het concrete huidige kwaliteitsniveau is. Leg dit niveau vast in de Definition of Done. Als meerdere teams aan hetzelfde product werken dan geldt het niveau van het minst presterende team. Dat is namelijk het niveau dat je als klant of belanghebbende minimaal mag verwachten en dat zal ongetwijfeld lager zijn dan wat de meesten ervan verwachten. Dit is een realistische start, want de teams hebben immers aangetoond dat ze dit kunnen halen. Van daaruit leggen de teams in gezamenlijk overleg de lat iedere keer een beetje hoger. De retrospective is de belangrijkste meeting die hiervoor wordt gebruikt, maar gebruik ook de sprint review meeting om de wensen en verwachtingen van belanghebbenden te achterhalen en met ze te bespreken. Iedere keer als je de lat een beetje hoger legt kun je bedenken wat de consequenties voor het team zijn, maar het is ook vooral een kwestie van gewoon doen. Ga iedere sprint een nieuw experimentje aan. Als het een keer niet lukt dan is dat niet erg. Je kunt immers altijd terugvallen op de vorige versie.

Zorg dat je de regie houdt en als je dit lang genoeg vol houdt kom je vanzelf weer op dat olympische niveau terecht, maar dan weet je ook zeker dat je het waar kunt maken.

Het gaat de laatste tijd in het nieuws en op sociale media veel over de capaciteit in de ziekenhuizen. Of eigenlijk over het gebrek aan capaciteit. Er is veel onbegrip dat na anderhalf jaar pandemie het aantal IC-bedden nog steeds niet is vergroot. De schuld wordt gezocht in de doorgeschoten marktwerking, de macht van de verzekeraars of in de bezuinigingen of onwil vanuit de politiek. Het probleem wordt daarmee echter gereduceerd tot een ordinaire geld kwestie.

Met geld alleen lukt het niet

De gedachte is dat als de politiek de portemonnee trekt en daarmee zorgt voor extra personeel en de salarissen verhoogt dat dan het probleem wel opgelost zal zijn. De primaire reactie van de meeste mensen om te vragen om extra geld voor meer capaciteit lijkt op zich een logische, maar vanuit een verbeter perspectief is dit eigenlijk nooit de juiste keuze. Behalve in de actuele discussie over ons zorgstelsel, wordt precies hetzelfde gezegd als het in bedrijven of organisaties niet goed gaat. Ook in de ICT sector waar ikzelf in werk hoor je het steeds weer terug komen. De kwaliteit van software is niet goed, dus er moeten meer testers komen. We leveren te weinig functionaliteit, dus er moeten teams bij. Het is altijd weer dezelfde reactie.

Wat is het werkelijke probleem?

Door alleen naar capaciteit te kijken leidt je de aandacht af van wat werkelijk het probleem is. Als je goed luistert naar de zorgmedewerkers dan hoor je hele andere problemen. Medewerkers ervaren gebrek aan waardering. Er heerst een management cultuur waarbij niet geluisterd wordt naar de problemen van de mensen op de werkvloer, maar vanuit de ivoren toren allerlei oplossingen worden bedacht die over de mensen worden uitgestort. Medewerkers hebben last van bureaucratische rompslomp en regeldruk. Ze ervaren een enorm gebrek aan autonomie om als professional zelf de regie in handen te hebben. Er is veel teveel focus op efficiëntie waarbij de menselijke maat uit het oog verloren wordt en aan de andere kant ziet iedereen dat er juist enorme verspillingen zijn, doordat verantwoordelijkheden versnipperd zijn en teveel mensen willen controleren en meebeslissen. Mensen haken niet af voor een paar euro’s meer of minder of omdat ze hard moeten werken. Ze haken af omdat ze zich machteloos voelen, omdat ze de grip op hun eigen werk kwijt zijn en omdat ze geen perspectief zien dat dat beter wordt.

Dit zijn de werkelijke problemen waar onze zorg professionals tegenaan lopen en die los je niet op door je alleen op de capaciteit te richten. Dan worden deze problemen misschien zelfs wel groter. Denk alleen al aan al die extra coördinatoren die nodig zijn om al die extra capaciteit te managen. Door de capaciteit te vergroten zul je de last voor een korte tijd verlichten en denk je op de juiste weg te zijn, maar krijg je al die andere problemen er na een tijdje dubbel zo hard weer voor terug.

Ga gecontroleerd verbeteren

Een beproefde manier van het verbeteren van productieprocessen is om de capaciteit steeds een klein beetje te verlagen. Niet teveel, want dan loopt de boel vast of er ontstaan teveel problemen waardoor je niet meer weet waar je moet beginnen. Het is daarbij niet de bedoeling dat mensen harder gaan werken, maar dat je gezamenlijk manieren vindt om slimmer te gaan werken. Jaren geleden kreeg ik een rondleiding door de Scania fabriek in Zwolle en ik zal nooit vergeten wat onze gastheer ons daar vertelde: iedereen loopt hier als een slak want anders lopen ze de problemen voorbij zonder die te zien. Als je iemand ziet die erg transpireert dan moet je meteen de dokter bellen. Hij zal koorts hebben en ziek zijn. Dat was overigens ver voor de Corona tijd.

Iedere dag werken aan echte problemen

Door de capaciteit iets te verlagen, komen de knelpunten boven water en die kun je dan oplossen. Je neemt dan een tijdelijke vermindering van de productiviteit voor lief. Ongewild gebeurt in de ziekenhuizen nu het omgekeerde. De capaciteit wordt niet gereguleerd verlaagd, maar de vraag wordt ongecontroleerd vergroot. Het effect is hetzelfde, maar omdat we er geen controle over hebben breekt de paniek uit. Door de grotere vraag aan zorg, kun je de bestaande problemen niet meer omzeilen door harder te werken. Extra capaciteit lijkt dan de oplossing, maar dan stopt het nadenken om de werkelijke grondoorzaken te vinden. Voor de korte termijn kan het natuurlijk verlichting geven. In Wuhan werd in korte tijd een compleet ziekenhuis uit de grond gestampt, maar dat hebben ze ook weer afgebroken toen de ergste crisis daar voorbij was. De echte problemen zullen ook opgelost moeten worden. En dat is waar het management in iedere sector samen met de werkvloer iedere dag aan zou moeten werken.

Wat lossen we toch graag problemen op. Ga in gesprek met iemand, benoem een probleem en voor je het weet heb je al een advies binnen om het op te lossen. Vaak nog helemaal gratis ook. Eigenlijk is het een wonder dat er nog problemen bestaan. Luister gewoon eens naar je medemens, dan is het allemaal niet zo ingewikkeld.

Dopamine verslaving

Dat we graag problemen oplossen blijkt een natuurlijke oorzaak te hebben. Alleen al het geven van een advies zorgt er voor dat er een beetje dopamine wordt aangemaakt. Van het idee dat je daadwerkelijk een probleem hebt opgelost, krijg je zelfs een flinke boost van dat spul. Je wordt er gewoon blij van. Het is dus niet zo gek dat we dat graag doen. Toch is enige voorzichtigheid wel geboden, want een snelle oplossing wil de situatie nog wel eens erger maken dan dat hij was.

Het probleem verschuiven

Bij een test team van een grote Nederlandse gemeente was frustratie ontstaan omdat men kort geleden op scrum was overgegaan. Het test team bestond nog, omdat er nog geen vertrouwen was dat de door de scrum teams geleverde software zomaar naar productie kon. De testers waren gefrustreerd, omdat ze merkten dat ze nogal eens testen uitvoerden die achteraf gezien al door een scrum team waren uitgevoerd. Dubbel werk dus en zonde van de tijd. De manager keek naar dit probleem en had binnen een paar seconden de oplossing: jullie moeten beter met elkaar gaan communiceren. En weg was zij, op weg naar het volgende probleem.

Het test team nam het advies ter harte en ontwierp een rapportageformulier. De bedoeling was dat als iemand in het scrum team een test had uitgevoerd dat zij de belangrijkste gegevens van deze test zouden gaan vastleggen op het formulier. Om het makkelijk en efficient te maken kon je dit formulier aan de user story koppelen in Jira. Het test team beoordeelde na de sprint alle rapportage formulieren, ze maakten een testplan en zo werd voorkomen dat ze dubbel werk moesten doen. Eind goed, al goed zou je denken, maar niets was minder waar. Het enige wat er gebeurd was, was dat er extra werk naar een andere plek was verschoven. In plaats van af en toe een incidentele test dubbel te doen, moest het scrum team nu voor iedere test een rapportage formulier invullen. Dat was uiteindelijk veel meer werk en daar kwam ook nog eens bij dat de frustratie was verschoven naar het scrum team. “Hoezo moeten wij dat invullen, we zijn toch een scrum team? We doen niet aan documentatie. Dat is niet Agile”, waren veel gehoorde opmerkingen bij het koffiezet apparaat. Met als gevolg dat de rapportages dikwijls niet ingevuld werden, wat weer leidde tot frustratie bij de testers. De manager had hier gelukkig ook een snelle oplossing voor: vanaf heden is het verplicht om het formulier in te vullen. Zo niet, dan is dit een onderwerp tijdens jouw functioneringsgesprek.

Wat gaat hier nu allemaal mis?

Ik heb drie oorzaken gevonden waardoor vaak de verkeerde keuzes gemaakt worden.

1. Problemen moeten opgelost worden.
   De grondgedachte is dat problemen opgelost moeten worden, maar durf dat idee eens los te laten. Ga er eens vanuit dat je een probleem slechts tot ontwikkeling hoeft te brengen. Dat gebeurt sowieso al als je intervenieert, want dan gaat er wat gebeuren. Denk alleen niet dat je na je interventie al klaar bent. Zelfs achter een lamp die het niet meer doet, kan meer zitten dan alleen het simpele feit dat de lamp stuk is.
2. Problemen oplossen doe je alleen
   Ook al is de verleiding groot en voel je jezelf Superman als jij de grote held bent die het probleem heeft opgelost, stap toch eens over jouw eigen ego heen en betrek meerdere mensen bij het vraagstuk. Maak het probleem gemeenschappelijk onder de mensen die er mee te maken hebben, zodat meerdere standpunten op tafel komen te liggen. Samen weet je nu eenmaal meer dan jij alleen. Het kost wat meer tijd, maar hou dan de mooie wijsheid in gedachten die hierbij past: “alleen ga je sneller, maar samen kom je verder.”
3. Ga niet teveel de details in
   Ga juist wel de details in. Met het algemene probleem uit het voorbeeld ‘we doen dingen soms dubbel’ kun je niet zoveel. Welke dingen zijn dat dan, hoe vaak is soms, hoe erg is dit eigenlijk? Het zijn allemaal vragen die je moet stellen voordat je een interventie gaat doen. Doe je dit niet, dan is het makkelijke antwoord ‘je moet beter communiceren’ makkelijk gegeven, maar dat is veel te vaag en het zal je niet gaan helpen. Zelfs als je het al wat specifieker maakt door te zeggen dat we niet goed met elkaar communiceren, ga je nog niet diep genoeg. Het gaat uiteindelijk om het concrete probleem dat test 4 van user story x dubbel is uitgevoerd. En dat willen we niet. Dan moet je het daar dus over hebben.

Blijf niet praten, kom in actie

Ik hoor je nu denken, leuk dat gepraat en geanalyseer, maar we moeten wel door. We hebben helemaal geen tijd voor zo’n Poolse landdag en dat gepolder. Je hebt helemaal gelijk als je blijft praten en niets gaat doen. Uiteindelijk leer je het meeste van concrete acties in de praktijk. Als die lamp al voor de derde keer in een week stuk is, ga er dan niet blind weer een nieuwe indraaien. De eerste keer vervangen was een experiment op basis van de hypothese dat slechts de lamp stuk was. Leer daarvan. En als werk dubbel wordt uitgevoerd, betrek dan alle mensen uit de waarde keten bij het gesprek. Graaf met elkaar naar concrete feiten, formuleer een hypothese, bedenk meerdere interventies, kies er samen een en kom in actie. Niet morgen, maar vandaag want je moet de kans om te leren niet voorbij laten gaan.