Waarom scrum & de zorg een gouden match zijn [3 good practices]

Scrum is natuurlijk al lang niet nieuw meer. Ik ga er daarom ook vanuit dat jij – als marketeer, communicatiemedewerker of IT-manager in de zorg – in grote lijnen weet wat scrum en agile ontwikkelen inhoudt. Maar wat je misschien nog niet wist, is dat scrum het complete ontwikkelproces een stuk menselijker maakt. En dat het precies daarom zo’n goede match is voor IT-productontwikkeling in de zorg.

Zorg draait om mensen, IT om machines

Zorg draait namelijk precies daarom: om mensen. En IT draait in principe om machines en code. Daarmee staan die twee disciplines bijna lijnrecht tegenover elkaar. Mensen die in de zorg werken, zijn vaak ook gericht op menselijke waarden. Natuurlijk is iedere persoon anders, maar mijn ervaring is toch wel dat zorgmedewerkers op een vrij zachte manier communiceren.

IT’ers daarentegen, zijn vaak typische bèta’s. Ze kunnen recht door zee zijn, precies zeggen waar het op staat of zelfs helemaal niets zeggen. Dat wordt door opdrachtgevers in de zorg niet altijd gewaardeerd. En andersom denken IT’ers vaak in gesprek met een zorgprofessional: “Wat wil je nou?” Iets tactisch en voorzichtig brengen, zorgt bij deze groep soms voor onbegrip. Zij hebben liever dat je duidelijk bent.

IT & zorg hebben elkaar (steeds harder) nodig

IT en de zorg staan dus vrij ver van elkaar. Toch hebben ze elkaar nodig. En steeds harder. Kijk maar naar ontwikkelingen als wearables voor patiënten, het elektronische patiëntendossier, digitale platforms om cliënt en zorgverlener met elkaar te verbinden en ga zo maar door. Ook de toenemende marktwerking en de komst van een generatie die opgegroeid is in een digitale wereld, vragen om steeds meer IT-oplossingen in de branche. Gelukkig is daar scrum: een ontwikkeltechniek die IT’ers en zorgmedewerkers dichter bij elkaar brengt. Ik vertel je graag hoe dat zit.

Agile ontwikkelen is menselijk ontwikkelen

Bij traditionele ontwikkelmethoden zijn opdrachtgever en IT-partner niet voortdurend met elkaar in gesprek. En bij twee branches die zo ver van elkaar vandaan staan, is dat vragen om misverstanden. Bij scrum is dat anders. Deze ontwikkelmethodiek is gebaseerd op de agile manier van denken. Het agile manifesto beschrijft vier hoofdgedachten. Twee van deze vier pijlers zetten overduidelijk het menselijke aspect vóór het technische en procesmatige.

‘People and interactions over processes and tools’

Mensen en interacties krijgen in agile ontwikkeltrajecten altijd prioriteit. Dat betekent niet dat (vastgelegde) processen en de tools die je gebruikt om te ontwikkelen onbelangrijk zijn. Maar als in de praktijk bijvoorbeeld blijkt dat een proces niet werkt voor ontwikkelaars of eindgebruikers, dan pas je dat proces aan. Want mensen gaan voor. Je kunt bijvoorbeeld wel bedenken dat een product owner (daarover later meer) de enige is die contact heeft met de eindgebruiker. Maar als de ontwikkelaars daardoor niet goed begrijpen wat er nodig is om die eindgebruiker écht te helpen, werkt het proces niet. Dus moet je het proces herzien.

‘Customer collaboration over contract negotiation’

Natuurlijk heb je als IT-bureau een contract met je opdrachtgever nodig. Maar het samenwerken met de klant is veel belangrijker. Je gaat samen op zoek naar de beste oplossing binnen het afgesproken budget. Bij problemen wijs je niet naar elkaar, maar zoek je samen naar een oplossing. IT-bureau en opdrachtgever zitten kortom in hetzelfde schuitje.

Menselijke principes

Naast de hoofdpijlers, zijn er ook twaalf principes. Vier van die twaalf principes licht ik hieronder graag uit, omdat ze goed laten zien op welke manier agile ontwikkelen IT een menselijker gezicht geeft.

1. Teams zijn self organizing

Het is niet de manager die het team aanstuurt, maar het team zelf. Gemotiveerde specialisten weten namelijk heel goed hoe ze hun werk moeten doen, dat geldt zowel voor zorgspecialisten als IT-specialisten. Geef ze daarom geen taak, maar een doel. En laat ze zelf bepalen hoe ze dat doel behalen. Op die manier geef je mensen meer verantwoordelijkheid en dat zorgt voor meer motivatie.

2. Geef gemotiveerde mensen het vertrouwen dat het werk afkomt

Ga ervan uit dat mensen intrinsieke motivatie hebben om hun werk goed en tijdig te doen. Geef ontwikkelaars dan ook het vertrouwen dat ze het juiste bouwen en dat hun werk snel genoeg afkomt. Daarvoor hoef je ze niet continu achter de broek aan te zitten.

3. Zorg voor een ‘sustainable pace’

Het tempo waarin developers werken en ontwikkelen, moet iedereen oneindig vol kunnen houden. Dat betekent bijvoorbeeld geen overwerk, tenzij mensen dat zelf willen. In dit opzicht is de term ‘sprinten’, die we gebruiken voor de korte cycli waarin delen van het eindproduct worden opgeleverd, misschien ook niet zo handig gekozen. Het is meer een marathon, waarin iedereen elke kilometer even snel mag rennen.

4. Zorg voor face-to-face-conversaties

Tegenwoordig kun je alles in de cloud doen. Overleggen kan prima via een video-gesprek, want dan zie je elkaar toch ook? Dat klopt in zekere zin, maar toch is dat niet de meest menselijke manier. Samen met elkaar in één ruimte zijn, elkaar in de ogen kunnen kijken: dat blijft de rijkste manier van communiceren. Daarom is het van belang dat het IT-team en de opdrachtgever elkaar regelmatig zien.

Als wij bijvoorbeeld werken in sprints van twee weken, zien we de opdrachtgever minimaal eens per twee weken gedurende anderhalf uur. Op die manier ontstaan veel minder misverstanden en begrijpen beide partijen elkaar veel beter. De product owner en het IT-team komen over het algemeen zelfs dagelijks bij elkaar.

Good practices bij scrum-trajecten in de zorg

Natuurlijk klinkt dat allemaal mooi, die theorie. Maar hoe zorg je ervoor dat het in de praktijk ook werkt? Daarvoor heb ik een aantal good practices uit eigen ervaring op een rij gezet.

1. Zorg voor een product owner die de zorg- én IT-wereld snapt

De product owner is in een scrumtraject het allerbelangrijkste, zijn rol is essentieel voor het succes. Hij slaat immers de brug tussen de opdrachtgever in de zorg en het IT-bureau. Hij is degene die het eindproduct stuurt op inhoud: hij bepaalt hoe het uiteindelijke product eruit gaat zien en hoe het zich in de toekomst verder gaat ontwikkelen. Als deze persoon de verkeerde beslissingen neemt, krijg je een product dat niet voldoet aan de wensen van de eindgebruikers en andere belanghebbenden.

 

Daarom is het zaak dat je goed nadenkt over wie de geschiktste product owner is. Hij of zij moet een brug kunnen slaan tussen zorg en ICT en daarom beide ‘talen spreken’. Meestal wordt iemand uit de zorgorganisatie gekozen voor deze rol. Dat kan heel goed werken, mits deze persoon goed is in prioriteren (niet alles tegelijk wil), nee durft te zeggen en goed om kan gaan met interne druk. Soms is het makkelijker om het buiten de eigen organisatie te zoeken. Denk aan een freelancer die gespecialiseerd is in deze rol en ook nog eens verstand heeft van de branche. Het kan ook iemand zijn uit de IT-organisatie waarmee je gaat samenwerken.

2. Zorg ervoor dat iedereen het jargon goed begrijpt

In de zorg heb je met een hoop jargon te maken. Soms zijn er termen die in de zorg iets heel anders betekenen dan in de wereld van IT. Daar moet je echt alert op zijn. Zo moet het IT-team bijvoorbeeld weten wat je met ‘KNOV’ bedoelt. De meeste mensen weten wel wat KNO is, maar KNOV is dus niet de vereniging voor KNO-artsen. De term ‘LVG’ heeft zelfs drie verschillende betekenissen, afhankelijk van de context binnen de zorg.

Communicatie gaat lastig als mensen niet dezelfde betekenis aan een woord hangen, of misschien maar gedeeltelijk weten wat iets betekent. Het helpt zeker om een IT-partner te kiezen met de nodige ervaring in de zorg. Maar ook dan nog geldt: wees je ervan bewust dat een ICT’er misschien denkt dat hij het jargon kent, maar dat het uiteindelijk toch iets anders kan betekenen. Schrijf daarom altijd afkortingen voluit of zorg voor een levende begrippenlijst.

3. Zorg ervoor dat IT’ers met eindgebruikers in gesprek gaan

De laatste en belangrijkste good practice is zorgen voor direct contact tussen ontwikkelaars en de eindgebruikers. Of dat nu medewerkers zijn van een zorgorganisatie of patiënten/cliënten: het gaat voor developers pas echt leven als ze de doelgroep spreken en in actie zien. Dan kunnen ze zich veel beter inleven in hun wensen en behoeften. En soms ook in hun beperkingen en mogelijkheden. 

Ik vond het zeer zinvol om de eindgebruikers te leren kennen. Daar zag ik dat het in de praktijk toch net even anders gaat dan hoe men erover praatte en hoe het beschreven stond. Verder gaf het me veel energie om te zien voor wie ik het allemaal deed. – Geert van der Ploeg, developer voor onze klant ‘s Heeren Loo

Een goed voorbeeld daarvan is JIP van ‘s Heeren Loo: het internetportaal dat we voor mensen met een verstandelijke beperking hebben ontwikkeld. Pas toen onze developers deze mensen aan het werk zagen met een eerste versie van het portaal, ging het écht voor ze leven. Het zorgde niet alleen voor meer begrip, maar ook voor motivatie. Juist omdat ze konden zien hoe de software die zij ontwikkelden deze doelgroep echt kon helpen.

Hiërarchie kan een uitdaging vormen

Het klinkt logisch. Waarom zou je developers en eindgebruikers niet bij elkaar in één ruimte zetten? In de praktijk is het binnen de zorg echter helemaal niet zo vanzelfsprekend. Zorginstellingen zijn vaak geen platte organisaties: mensen in het topmanagement nemen de beslissingen voor collega’s op de werkvloer. Natuurlijk is dat altijd goedbedoeld, maar het is ontzettend moeilijk om goed in te schatten voor een ander wat hij of zij nodig heeft. Hoe goed je die persoon of groep personen ook denkt te kennen.

Hier ligt overigens ook een uitdaging voor de product owner. Hij of zij moet ervoor zorgen dat alle belanghebbenden goed worden vertegenwoordigd: van topmanagement en eindgebruikers tot aan het IT-team. De scrum master heeft de taak om de product owner daarin te ondersteunen.

Scrum heeft nog veel meer voordelen

Ik hoop dat je na het lezen van dit artikel beter begrijpt hoe menselijk het proces wordt, als je volgens scrum ontwikkelt. En natuurlijk gelden de standaard voordelen van agile development ook voor productontwikkelingsprojecten in de zorg. Met scrum krijg je kort-cyclisch inzicht in concrete resultaten. Je werkt dagelijks samen en dat zorgt voor vertrouwen in een goede voortgang en begrip voor eventuele vertraging.

En uiteraard bouw je in scrumtrajecten veel sneller een oplossing die ook nog eens erg goed aansluit bij de wensen en doelstellingen van de gebruiker. Tot slot levert het steevast ideeën op voor de doorontwikkeling van je product. Kortom: wat houdt je nog tegen?