Agile maakt software-ontwikkeling menselijker

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

Zorg draait 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 ieder persoon anders, maar mijn ervaring is dat zorgmedewerkers op een vrij zachte manier communiceren.

It’ers zijn vaak typische bèta’s. Recht door zee, precies zeggen waar het op staat of helemaal niets zeggen. Dat wordt door opdrachtgevers in de zorg niet altijd gewaardeerd.
Andersom denken it’ers in gesprek met een zorgprofessional vaak: wat wil je nou? Een onderwerp tactisch en voorzichtig brengen, leidt bij deze groep soms tot onbegrip. Zij hebben liever dat je duidelijk bent.

Scrum brengt medewerkers dichter bij elkaar

It en de zorg mogen dan ver uit elkaar liggen, ze hebben elkaar wel nodig. En steeds harder. Kijk 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.

Bij traditionele ontwikkelmethoden zijn opdrachtgever en it-partner niet voortdurend met elkaar in gesprek. En bij twee branches die zo ver van elkaar zijn verwijderd, 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.

Mensen gaan voor

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.

Natuurlijk heb je als it-bureau een contract met je opdrachtgever nodig. Maar het samenwerken met de klant is 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 in hetzelfde schuitje.

Menselijke principes

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

• Teams zijn self organizing

Het is niet de manager die het team aanstuurt, maar het team zelf. Gemotiveerde specialisten weten namelijk goed hoe ze hun werk moeten doen. Dat geldt zowel voor zorg- 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.

• Geef gemotiveerde mensen het vertrouwen dat het werk afkomt

Ga er vanuit 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.

• Zorg voor een sustainable pace

Het tempo waarin developers werken en ontwikkelen, moet iedereen oneindig vol kunnen houden. Dat betekent bijvoorbeeld geen overwerk, tenzij ze 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 niet zo handig gekozen. Het is eerder een marathon, waarin iedereen elke kilometer even snel mag rennen.

• 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 minder misverstanden en begrijpen beide partijen elkaar beter. De product owner en het it-team komen over het algemeen zelfs dagelijks bij elkaar.

Good practices

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

• Zorg voor een product owner die zowel de zorg als it-wereld snapt

De product owner is in een scrum-traject het allerbelangrijkste: zijn rol is essentieel voor het succes. Hij slaat 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 ontwikkelt. 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 er iemand uit de zorgorganisatie gekozen voor deze rol. Dat kan goed werken, mits deze persoon goed is in prioriteren (niet alles tegelijk wil), nee durft te zeggen en goed kan omgaan 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.

• Zorg ervoor dat iedereen het jargon goed begrijpt

In de zorg heb je met jargon te maken. Soms zijn er termen die in de zorg iets anders betekenen dan in de wereld van it. Daar moet je alert op zijn. Zo moet het it-team bijvoorbeeld weten wat je met KNOV bedoelt. (De meesten 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.

• 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.

Hiërarchie kan uitdaging vormen

Het klinkt logisch. Waarom zou je developers en eindgebruikers niet bij elkaar in één ruimte zetten? In de praktijk binnen de zorg is het helemaal niet zo vanzelfsprekend. Zorginstellingen zijn vaak geen platte organisaties: werknemers in het topmanagement nemen de beslissingen voor collega’s op de werkvloer.
Natuurlijk is dat goedbedoeld, maar het is moeilijk om goed in te schatten wat een ander 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 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.

Meer voordelen

Ik hoop dat je na het lezen van dit artikel begrijpt hoe menselijk het proces wordt, wanneer je volgens scrum ontwikkelt. En natuurlijk gelden de standaardoordelen 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 scrum-trajecten veel sneller een oplossing die ook nog eens aansluit op 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?

Ruud Rietveld, scrum-master bij Finalist