top of page
Zoeken
Foto van schrijverWeekly Iterations

Op zoek naar de Agile Consultant 1: Huh? Cultuurverandering. Moi? (wk 18)

Bijgewerkt op: 6 nov 2018


Als we het over Agile hebben in relatie tot consultancy, waar hebben we het dan over?


Klassiek gaat Agile over de wijze waarop IT ontwikkeld kan worden. Scrum is een van de meest toegepaste methoden in IT-development om sneller betere kwaliteit te leveren. Ik ga nu niet stil staan bij alle beweegredenen achter het Agile Manifesto en de 12 principes. Ik ga ervan uit dat de lezer bekend is met de belangrijkste drijfveren in de IT om agile te willen werken: sneller business waarde (minder risico’s, goedkoper, betere kwaliteit) als reactie op de lineaire aanpak die bekend staat als de ‘watervalmethode’ zoals SDM.


De kenmerken van een methode gebaseerd op het Agile gedachtengoed zijn:

  • Iteratief werken

  • Focus op geprioriteerde waarde

  • Incrementeel opleveren

  • Gebruikers betrekken

  • Last but not least; rijke communicatie

Het succes van Agile in de ontwikkeling IT waaide over van de IT-afdeling naar de andere delen van de organisatie. De interesse voor Agile werken en de behoefte om op te schalen buiten de sfeer van 1 projectteam kent een ontwikkeling die ik rond 2000 niet had voorspeld. In die tijd was Agile voor mij een thema in de zijlijn van projectmatig werken en dan vooral van projectmatig IT ontwikkelen. Agile zag ik ineen adem met DSDM, Xtreme programming. etc. Het is niet in mijn gedachten opgekomen dat Agile werken ooit een dominante zienswijze of verlangen zou worden voor organiseren van een complete organisatie. Wel maakte ik op meerder plaatsen de aandacht voor Lean mee, onder andere in de ziekenhuizen met hun ‘sneller beter programma.


Dat Agile zo kon hypen heeft mij achteraf verbaasd maar niet verrast. Ik gaf rond die tijd als projectmanager leiding aan grote ICT-implementaties. Ik was in die tijd juist heel gelukkig als ik een stuurgroep bij elkaar wist te krijgen die ook echt stuurde. De vakbladen stonden er dan ook vol van: managers die geen leiderschap tonen en geen visie hebben en de strijd tussen lijnmanagement en projectorganisatie. Met het draaien van implementatieprojecten in de zorg kwam ik terecht in een complexiteit waar de projectmanagement methoden als Prince2 geen oplossing voor hadden:

  • Machtsuitoefening artsen

  • Machtsvacuüm tussen zorgprofessionals en bestuurders

  • Overbruggen van functionaliteit systemen en werkprocessen

  • Binnen fixed data/beperkt budget een implementatie resultaat boeken.

  • Strijd om de toch al overbelaste mensen van de werkvloer in te zetten

Wat deed ik als projectleider? Ik motiveerde mensen om key-user te worden, sprokkelde budgetten om functioneel beheerders in positie te brengen, hield rekening met de diversiteit aan stakeholders (leveranciers, IT-afdeling, dokters, hoofden), hield werksessies en workshops om te verduidelijken wat kan met de software voor de praktijk, stelde rapportages op die nauwelijks werden gelezen, bewoog dagelijks als cement tussen de projectleden en de stakeholders om hun te verbinden, hield naast korte wekelijkse plansessies regelmatig feedback en intervisie sessies over hoe wij ons werk doen, en redde het projectresultaat veelal te halen met de liefde voor het vak van al die mensen met hart voor de zorg.


Guess what? Achteraf bleek dat best nog wel aardig Agile te zijn geweest volgens de Agile Coaches die ik later heb ontmoet. Was dat volgens de lettertjes van het scrum alfabet? Nee. En ik wou dat ik de lean en agile methoden eerder had geleerd. Met name de daiy stand ups, KanBan planboard en retrospectieve volgend een vaste cadans zijn geweldig aanknopingspunten en waar ik voorheen als projectleider een team doe kan ik nu met gemak als scrum master twee teams aansturen. Let wel: ik had ook ooit een project mat 80-120 medewerkers verspreid over 12-15 teams onder mijn hoede met een project board van een 6-10 personen.


Hoe ingewikkeld en omvangrijker het project, hoe groter de noodzaak om te faciliteren in plaats van te regisseren, hoe meer zorg voor de projectleden en hoe ik mij verhield tot mijn project leden. Zij waren ICT- professionals die met artsen, verpleegkundigen en administratief medewerkers en managers een weg vonden om software werkend te krijgen op al die werkplekken. Alleen bij obstakels bemoeide ik mij er mee en moet ik mijn positie hiërarchisch (naar de board) of functioneel (bakkie koffie met de stakeholders) inzetten. Bakkie koffie werkte meestal prima, omdat er achter ieder obstakel een oplossing zat. Mensen in de zorg willen het beste voor zichzelf om te kunnen werken om hun patiënten te behandelen. Als je uitgaat van de goede wil, vind je wel een oplossing.


Software Implementaties gingen over uitrollen en uit ervaring bleek: wat goed is voor één afdeling/specialisme werkt niet bij een andere afdeling/specialisme. Dat kon in potentie leiden tot veel gesteggel. Maar de artsen, verpleegkundigen en administratieve medewerkers hadden eenvoudig gelijk: ze deden wel dezelfde activiteiten maar voerden die in detail verschillend uit.


Die diversiteit aan implementaties is van belang om te begrijpen hoe ik wel moest werken om succes te hebbe: ik moest mijzelf en mijn teamleden iedere keer weer aansporen om aan te sluiten en te luisteren en vandaaruit verder te handelen.

Om dat probleem van diversiteit aan implementaties te ondervangen, ontwikkelde ik een implementatiemethodiek die ik de projectleden hielp hanteren. Die methodiek had veel weg van een set sprintjes van 4 maal 2 weken om tot een implementatie bij een afdeling/specialisme te komen, waarbij we in het begin vooral vast probeerden te stellen wat we precies moeten doen (inclusief de extra’s) om de software op de werkvloer met goedkeuring aan de praat te krijgen.


Goed, ik kan zo nog wel even door gaan. Ik heb achteraf met verbazing en niet met verassing onderkent dat ik de kenmerken van agile werken toepaste in een werksituatie die complex was. Waar wel een doel duidelijk was (implementeren software) maar het concrete wat en hoe nog met de werkvloer ne de projectleden uitgevonden moest worden).


Toen ik rond 2012 in contact kwam met agile coaches en agile werken (mensen die o.a. bij ING al jarenlang hielpen om agile werken te implementeren in de dagelijkse routine van IT-teams, ha dik al een achtergrond met opschalen van initiatieven. En of dat initiatief nu implementeren van software was, DBC-registratie door dokters, BSN invoeren, migratie van een EPD/ZIS, privacy awareness, veilig werken, of ……agile werken. Al dat opschalen kende één gemeenschappelijke noemer waar ik door anderen om mij heen op gewezen werd: cultuurverandering?


Huh? Cultuurverandering. Moi? Dat gaat toch over heel andere zaken? Dat gaat dan toch over het bespreekbaar maken van de goede visie. Het trainen in leiderschap, feedback en over wat de verandering moest behelzen Meer voer voor psychologen en nuffige dames die mensen met zachte hand over het hobbeltje naar ‘de nieuwe werkelijkheid” duwen? Die spelend met wortel en zweep de meute verleiden en dwingen het gewenste gedrag te vertonen.


En toch: het was cultuurverandering in actie door uit te gaan van gedrag nu hier op de werkplek nodig is en met kleine stapjes aansluiten op wat mogelijk en wenselijk is, om zo vooruit te bewegen totdat zij na een aantal weken konden zeggen ‘verhip we zijn veranderd!’


Daar in het implementeren van software in ziekenhuizen is een tastbaar aanknopingspunt van mijn agility. In de komende blurr's meer over de lessen uit de implementatieprojecten in de zorg voor het uitoefenen van een consultancy vak. Op zoek naar de Agile Enabled Consultant


Comments


bottom of page