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
Nou en of, allemaal ! En je kan er ook nog eens zo lekker over ouwehoeren 🙂
Dino, alles draait om de communicatie. Je kan er ook nog een certificaat in halen.
Beiden voorgangers hebben gelijk. Maar je zou natuurlijk ook eens als it-professionals de non-it-professional uit kunnen gaan leggen wat it is, hoe het werkt en hoe je ermee om dient te gaan. Iets wat in +80% van de gevallen telkens weer word nagelaten. Echt, dat scheelt meer dan 3/4 van je werk. Heb je dan niet eens een extra certificaatje voor nodig. ;O)
Alle voorgangers hebben gelijk. En je zou natuurlijk ook eens als it-professionals de non-it-professional kunnen vragen wat hun vakgebied is, hoe het werkt en hoe we er mee om dienen te gaan. Ook dit wordt vaak maar summier gedaan. Of het 3/4 van het werk scheelt, durf ik geen uitspraak over te doen, maar ik weet wel dat het dan ook een stuk makkelijker wordt om een goed resultaat te halen.
@RuudRietveld Zomaar wat opmerkingen. Het is een vrolijk mix die je opschrijft van de gangbare management inzichten van dit moment. Er zitten hele zinnige dingen in die je opschrijft, over het jargon, gebruikers en ontwikkelaars die contact met elkaar kunnen (mogen) hebben, net zoals dat voor iedereen geldt waar het werk elkaar raakt. Niet voor niets is het fenomeen DevOps ontstaan. Maar ook een heel pallet van procesbegeleidings methodes. Ieder gekenmerkt door eigen terminologie, rituelen en rollen. Rollen die over het proces gaan en niet over de inhoud. Het doel is meestal wel duidelijk: zo snel mogelijk, zo goed mogelijk en zo goedkoop mogelijk. Met maximale controle. Ik ben nog een man van de oude stempel: concrete taken, rollen en verantwoordelijkheden.
Een zo een begrip wat op dit moment in is, het zelfsturende team. Ik hoor dat om me heen, niet perse in de iCT maar ook in de zorg. Het team doet dit, het team beslist dat. Daar snap ik nou helemaal niets van. Het doet me wat denken aan de blauwe maandag dat ik in militaire dienst zat. Aan de andere kant van het terein werd een brandblusser leeggespoten, maar iedereen moest nablijven. Het hele team. Als je naar groepsdynamiek kijkt dan weet je waar dit op uitdraait. Het recht van de sterkste en de aap met de grootste mond heeft het voor het zeggen. Survival of the fittest. Is dat nou de manier waarop er gewerkt wordt? Levert dat de beste oplossing? Wat is er mis met een verantwoordelijk, manager, projectleider, die luistert naar zijn medewerkers en voor de uiteindelijke beslissing verantwoordelijk is? Lijkt me veel gezonder.
Dat is een ontwikkeling die ik wel waarneem. De ene helft van de medewerkers coacht, begeleidt, stuurt, controleert de andere de helft van de medewerkers die het werkelijke werk doen. Is het wantrouwen? Of is het het streven naar inderdaad zo snel, goed en goedkoop mogelijk. Waarbij het medicijn erger is dan de kwaal.
En voor de zorg, je zegt het al, de marktwerking. Noem het ook wel de marktbureaucratie. Gekenmerkt door registratiedrift, controledrang en wantrouwen. Met in de zorg dus een overvloed aan ICT systemen om dit te bereiken. Niet voor niets wordt in de zorg (maar ook onderwijs) hierover geklaagd. Teveel tijd kwijt aan niet werk maar aan administratie. Vraag me dan ook af of die ICT’er enthousiasme zal tegenkomen bij de gebruiker. Als hij/zij die al spreekt.
Wat ik hier in het verhaal volkomen mis zijn, m.i. de belangrijkste faktoren.
1 Waarom automatiseer je?
Er is maar één reden te automatiseren en dat is winst. De hausse in EPD (elektronisch patienten dossier) heeft ertoe geleid dat er een woud aan typen en applicaties zijn opgetuigd en uitgerold die dan vervolgens weer veel meer admistratieve rompslomp met zich mee brachten laat staan, toevoegende waarde.
Het heeft alleen zin te automatiseren als je versnelling van processen tegemoet kunt aantonen waardoor winst kan worden behaald zodat er meer tijd en zorg aan patienten kan worden besteed. Menig automatiserings proces op dit vlak faalt jammerlijk.
2. Doel vs opbrengst
Vaak is het doel niet eens goed gedefinieerd en dat speelt de ontwikkeling en implementatie volkomen negatief in de kaart. Als bijvoorbeeld artsen, specialisten en verpleegkundig personeel meer en meer tijd kwijt zijn aan allerlei overbodige handelngen, is de keten consequentie dat er meer tijd en geld verloren gaat voor de patient, die uiteindelijk, links of rechts om, die rekeningen betaald.
Vaak weten de ‘gebruikers’ helemaal niet wat IT als materie is, waarom je het inzet, en hoe je ermee om gaat. Een bijzonder goede en eenvoudige white paper is enige jaren geleden al geschreven die non-profit en non-commercie een zeer eenvoudig voorbeeld geeft waar het nu bij automatiseren en zorg om gaat.
http://numoquest.nl/EPD IT.pdf
Dat maakt zaken als scrum of agile volkomen overbodig, met alle besparingen van dien.
Waarschuwing: dit is off topic (en het vorige commentaar ook al)
@louisKossen Ik denk dat de vergelijking van een groep dienstplichtigen met een zelfsturend team van professionals niet helemaal eerlijk is. Een echt team heeft een zekere mate van autonomie, de juiste vaardigheden en een helder en goed Doel. Met onderlinge openheid en constructieve conflicten. Dat heeft een groep dienstplichtigen allemaal niet. Dat zul je met me eens zijn.
En binnen Scrum hèb je die managende rol die luistert naar het team en voor de uiteindelijke functionele beslissing verantwoordelijk is: de Product Owner. Deze gaat echter helemaal niet over hoe het werk gedaan wordt. De professionele ontwikkelaars weten zelf het beste hoe het werk gedaan dient te worden, als team, zoals ik al schreef.
En dat nu ‘de helft’ (jouw woorden, ik zie dit meer als een tiende) coacht en begeleidt komt alleen maar omdat we jaren gewend zijn om in een hiërarchie te werken, waarin de manager’s wil wet is. Dit is een heel goed management model als je met ongeschoolde arbeiders werkt en geschoolde managers. Tegenwoordig zijn de meeste mensen goed geschoold, en kun je ze wel iets toevertrouwen. En toch zie je in veel opleidingen tot manager nog dat het oude model aangeleerd wordt. Dus daar is ook nog winst te halen.
Terug on topic: de zorgmedewerker besteed inderdaad veel tijd aan administratie, en laat dat nou net iets zijn waar wij als IT’ers de zorgmedewerkers in kunnen ondersteunen, door die administratie zo makkelijk mogelijk te maken. Als we daarover met die gebruiker in gesprek gaan kunnen we enthousiasme genereren. En daarnaast is het wel interessant om er ècht achter te komen waar al dat wantrouwen vandaan komt. Ik probeer te denken in oplossingen, niet in machteloosheid.
Een scrum team heeft behalve een product owner ook een scrum master en bestaat uit maximaal 9 personen (bron scrumguides.org). Das alvast minimaal 2/9 manager/medewerker verhouding.
Enthousiasme genereren en met gebruiker aan de slag gaan 😉
Scrum is elke dag meeting tbv micromanagement waarbij de eindgebruiker het druk heeft en zijn belangen door de product owner vertegenwoordigd zouden worden. Moet ook wel want in een uur geïnterviewd worden door developer kon die ook zes bejaarden onder de douche duwen.
Hoewel agile nu doel op zich lijkt te zijn geworden, presenteert het zich als middel. Nog sneller de business ondersteunen. En die willen controle.
Kijk eens in hoeverre de agile manifesto values in de zorgorganisatie zelf vertegenwoordigd zijn :
Individuals and interactions over processes and tools.
Responding to change over following a plan.
Customer collaboration over contract negotiation.
Vraag opa en zijn zorghulp maar waar het wantrouwen vandaan komt. Zal wel weer off topic zijn.
@ All
Ter zake procesmatig en IT matig kennende, heb ik me altijd gekeerd en gekant tegen Borst/Hoogervorst/Klink/Schippers. Ik heb me destijds zeker achter mevrouw Borst geschaard vanwege haar stelling dat de zorg goedkoper moest, kon, ook destijds met haar visie en zicht op de komende vergrijzing. Ik heb me, nooit voor laten staan, zorgverzekeringen en zorg, verregaand te privatiseren.
Twee eenvoudige redenen
Menselijke gezondheid nooit een financial commodity
De factoren die op niveau van individuele menselijke gezondheid elk moment van de dag van invloed zijn op die persoon, zijn te talrijk om deze te kunnen verzekeren. Lees hier, er zijn twee zekerheden, dag van geboorte en overlijden, alles daar tussenin is volkomen onbegrensd en onbeheersbaar, laat staan voorspelbaar.
Mevrouw Borst en heer Hoogervorst zijn hiervan op de hoogte gebracht dat dit statistisch gewoon niet kan, beiden hebben zich doof en blind betoond. Ab Klink is destijds, inmiddels vijftien jaar geleden, indringender hierop gewezen. Met de toenmalige politieke visie, iedereen verplicht te verzekeren, hebben wij gewaarschuwd dat dit alleen kan met een model dat gelijk staat aan afpersing. Ab Klink heeft miljarden voor de varkens gegooid, zonder enig aantoonbaar resultaat. Wat wel bekend is zijn twee zaken. Ab Klink heeft de belastingbetaler in zijn ambtsperiode met een schade van meer dan 24 miljard opgezadeld en wordt hiervoor nu fors beloond door de VGZ, zonder aantoonbare kennis van zaken.
EPD
Het EPD, als instrument data, in het licht van privatisering van zorgverzekering, te centraliseren, druist in tegen elke technisch denkbare IT norm denkbaar. Immers, een database van dergelijke grootte zal alleen maar problemen opleveren technisch terwijl administrering en onderhoud van machtigingen een onmogelijkheid. Bovendien, is er geen enkele sanctiemiddel of beschermingsconstructie voor die individuele data, ‘as we speak’, opgetuigd en geïmplementeerd.
Om u hier te bedienen, een eenvoudige verzekeringspas met chip, a raison € 0,80 per verzekerde en een eenduidig landelijk protocol voor alle zorgverleners, die misschien een stukje software van nog geen twintig mille zou opleveren, hadden de uitgegeven miljarden en deze hele stelling in alle eenvoud kunnen voorkomen.
Aanvullend, had dit laatste vele miljarden in de zorgprocessen vereenvoudigd en vele medische missers kunnen voorkomen en vijftien jaar geleden al een eenvoudige ‘Pay per Handling’ opgeleverd.
Misschien kunt u de laatste alinea hier even in uw gedachte nemen en deze afzetten tegen deze publicatie en u zich voorstellen dat de gehele voorstelling van zaken overbodig zou zijn geweest.
Overigens, de gelegaliseerde afpersing van de Nederlandse overheid breid zich op dit vlak alleen nog maar verder uit. ‘Hence’, politiek en commercie, beiden dodelijk voor een gezonde werkende IT.