De afgelopen blog ging over waarom stabiliteit je wendbaarheid vergroot. Ik zou hier in volgende blogs op door pakken. Vandaag waarom het fanatieke streven naar wendbaarheid zonder voldoende aandacht voor je beheer zelden effectief is.
Laat ik beginnen met een voorbeeld. Een klant waar ik voor werkzaam was wilde sneller veranderen. Op zich een mooi streven natuurlijk. Agile zou het probleem gaan oplossen, maar zoals zo vaak was dat wat kort door de bocht. Laat ik duidelijk zijn, het is goed om wendbaar te willen zijn. Het kan je helpen in deze tijden van grote en snelle verandering om te overleven. Maar behendigheid heeft óók een stabiele basis nodig. Terug naar het voorbeeld. De klant had een low code platform gekocht en geïmplementeerd en kon daarop snel en flexibel ontwikkelen voor zijn klanten. Omdat dit bedrijf had gekozen om het aantal platformen te minimaliseren was er een gedwongen winkelnering en was men als klant afhankelijk van dit platform voor nieuwe ontwikkelingen. Alternatieven werden niet getolereerd. Er was echter één duidelijk probleem. Het beschikbaar stellen van een nieuw systeem aan de klant om daarop met de low code applicatie aan de slag te gaan was een tergend langzaam proces. Het beschikbaar stellen van een systeem duurde al met al meer dan 2 maanden en daarna waren er ook nog eens bij iedere oplevering vele incidenten. Dit gaf veel onvrede bij de klanten.
Er was te weinig prioriteit voor het optimaliseren en automatiseren van dit deel. Toen ik aan boord kwam speelde dit al even toen ik vroeg hoe we deze systemen sneller aan de klant beschikbaar zouden kunnen stellen en zonder incidenten. Dat gaf meteen veel onrust, want “dat zou niet gaan”, “het was al eens geprobeerd” en “dit was het snelst mogelijk”. Weerstand, maar na overleg met elkaar en een goed overzicht en inzicht waarom dit écht beter moest kwam er meer tijd om hier met een scrumteam dedicated mee aan de slag te gaan.
De oplevertijd werd in een paar iteraties teruggebracht van 2 maanden tot 1 dag
Het opleveren werd geautomatiseerd getest en een aantal incidenten werd structureel en kwalitatief opgelost. De klant kreeg daarbij via een eigen klant portaal veel meer mogelijkheden om binnen het systeem dingen te doen die nu steeds opnieuw bij beheer kwamen (denk bijvoorbeeld aan het beschikbaar stellen van logfiles). Een eenmalige investering van zo’n 8 weken maakte niet alléén de beheerders trots, maar ook de business blij. Het versnelde de implementatie van nieuwe low-code applicaties ten behoeve van de business. En het mooie was we waren uit de groef van “dat het niet zou lukken” en “dat het al eens geprobeerd was”.
Door innovatie in je beheeromgeving help je de verandering aan de ‘change’ kant
Iets te vaak wordt geroepen dat innovatie en beheer niet bij elkaar horen. Ik wil dit met klem tegenspreken. Juist innovatie in je dagelijks beheer kan namelijk de veranderkant enorm helpen. Zie het voorbeeld hierboven. Van 60 dagen met veel fouten bij de oplevering naar een zo goed als foutloze overdracht aan de klant in één dag. Mijn stelling is dan ook: Focus op een wendbare veranderkant is niet genoeg!
McKinsey heeft ooit eens onderzoek gedaan naar bedrijven die beiden goed hebben ingericht en 70% van alle bedrijven die dat voor elkaar hebben horen volgens hun onderzoek bij de top 25% van de meest succesvolle organisaties. Uit hun onderzoek bleek dat deze bedrijven zowel goed waren qua stabiliteit als ook wendbaarheid.
Het vermogen om zowel stabiel als dynamisch te zijn is de essentie van échte organisatorische wendbaarheid (Agility).
Het voorbeeld van de smartphones in de vorige blog laat zien hoe zo’n ontwerp er uit zou kunnen zien. De hardware en besturingssysteem vormen een stabiele basis. De dynamische applicatie laag geeft volop ruimte aan bestaande en nieuwe apps die kunnen worden toegevoegd,
bijgewerkt, aangepast en verwijderd. Afhankelijk van wat nodig is en of de vereisten wel of niet veranderen. Zo kun je op een stabiele onderkant heel veel moois bouwen zonder elkaar in de weg te zitten of op te houden. Als het systeem goed is ontworpen kun je ook onafhankelijk van elkaar opereren en beïnvloed een probleem bij de één niet alle andere apps, maar slechts die ene app zelf.
Op dezelfde manier ontwerpen succesvolle agile bedrijven hun organisaties
met een ruggengraat van stabiele elementen. Deze stabiele basis, zoals de hardware en het besturingssysteem van de smartphone, zullen waarschijnlijk blijven bestaan over een langere periode. Zo kan een goed gekozen basis net als een OS op een telefoon langdurig mee gaan. Uiteraard met wat updates zo nu en dan, maar een goed gekozen basis in een organisatie kan tot wel vijf tot tien jaar meegaan.
Op die stabiele ondergrond kan men met organisatorische applicaties snel ‘plug-and-play’ nieuwe kansen faciliteren. Of je kan bij onverwachte uitdagingen snel bijschakelen om bedreigen die de organisatie destabiliseren te lijf te gaan.
Goed voorbeeld doet volgen
Na het bovengenoemde succes, waarbij de systeemoplevering terug ging naar 1 dag en uiteindelijk zelfs 3 uur, zouden snel nog meer improvements worden gepland en opgepakt in de DEVOPS teams. Je zou dit sowieso als standaard aanpak verwachten, maar vaak ontbreekt het hier toch aan structurele aandacht voor continue verbeteren bij organisaties. Vaak als deel van een DEVOPS team werden vervolgens zaken waar men al heel lang tegen aan liep – vanuit een top-3 improvements lijst – structureel opgepakt. Het grote voordeel hieraan is dat men steeds minder bezig hoeft te zijn met repeterende incidenten en langdurige opleveringen of klantvragen die ze zelf kunnen oplossen. Gevolg daarvan is dat er steeds meer tijd over blijft voor Development binnen de DEVOPS teams. En dit wordt vaak als interessanter werk ervaren dan steeds dezelfde incidenten oplossen. Toen men ging zien dat men hier zelf invloed op heeft ging het ineens hard en kwam er meer en meer tijd voor DEV en hoefde men minder tijd te besteden aan OPS.
De spanning in evenwicht brengen
Zoals in de vorige blog al aangegeven zijn er drie kerngebieden van de organisatie waar het balanceren tussen stabiliteit en flexibiliteit van cruciaal belang is:
- Organisatiestructuur, die definieert hoe resources zijn gedistribueerd
- Governance (Bestuur), welke bepaalt hoe beslissingen worden genomen
- Processen, die bepalen hoe dingen worden gedaan, inclusief het prestatiebeheer
En juist deze zaken loop ik in de volgende blogs één voor één langs
Meer info op https://janwognum.nl/
Recente reacties