Wat begon als een typfout leverde mij een waardevol woord op. Een mooie kandidaat om toe te voegen aan de Dikke van Dale. Zeker op het gebied van innovatie, en dan met name in de it, is 'probleren' namelijk de belangrijkste methodiek.
Sinds de komst van cloud computing is probleren nog veel gemakkelijker geworden. In plaats van lange trajecten voor het aanschaffen van hard- en software zijn services nu simpelweg aan, maar ook weer snel uit te zetten. En door middel van microservices-architectuur is snel te schakelen om nieuwe oplossingen te ontwikkelen en uit te testen.
Maar werken we wel op deze manier? Of gebruiken we alleen nieuwe technologie op basis van onze oude procedures en werkwijzen?
Adagium
Probleren maakt het mogelijk om zonder al te veel risico te proberen, experimenteren en leren; fail fast, learn rapidly. Een mooi adagium wat met name door agile softwareontwikkelaars omarmd wordt. Je komt er zo snel mogelijk en tegen zo min mogelijk operationele kosten achter of iets werkt of niet. En de cloud en microservices maken dit nog zó veel gemakkelijker. Hoe eerder je weet of iets (niet) kan werken, hoe beter. Probleren dus!
En het probleergeld is de kosten van de (in zo beperkt mogelijke mate) gemaakte uren. Maar hierop is in mindering te brengen de waarde van het geleerde. Waarmee het volgende experiment weer wat doelgerichter kan plaatsvinden.
Zinvol
Soms kan het zelfs al voldoende zijn om door middel van alleen user interface mockups te bepalen of iets zinvol is om mee door te gaan of niet. Low-code is hierbij ook een fijn hulpmiddel. Op die manier kan, zonder maar een regel code te schrijven heel snel bepaald worden of iets een goede oplossing kan zijn voor een bepaald businessprobleem. Probleren betekent niet per se dat er code moet worden geschreven of dingen geconfigureerd moeten worden. De belangrijkste doelstelling van agile ontwikkeling van oplossingen is om zeer efficiënt een zo’n hoog mogelijke door de product owner bepaalde businesswaarde te creëren.
Een goed probleerder vergeet daarbij niet om het geleerde te borgen voor de rest van het team en de organisatie. Want het is eeuwig zonde als de volgende persoon iets zou probleren als een andere persoon al eerder had geleerd dat het een fast fail was. Ofwel, organizational memory maakt probleren nog doeltreffender.
Leuke woordspeling Gijs maar fail fast, learn rapidly kent een keerzijde als we kijken naar de ‘organizational memory’ van gegevens die verkregen zijn. Wat betreft oude procedures kun je een idee makkelijk toetsen met de cloud maar deze optie kent ook een duistere zijde als we kijken naar de vluchtigheid. Ons Rijnlandse businessmodel kent een groot wantrouwen als het om de ‘probeersels’ ten koste van de klant gaat. Want het probleergeld in de vorm van ‘goodwill’ gaat om het residu van data waar steeds meer regels voor gelden.
Weer eentje uit de categorie om u nog beter van dienst te kunnen zijn falen we.
Als ik het goed begrijp gaat het om snel geen businesswaarde te kunnen toevoegen.
een boute stelling dat door microservicearchitectuur beter ontwikkeld kan worden dan met een reguliere modulaire architectuur.
Natuurlijk zijn er businesscases waarbij je wel moet kunnen schalen, voor het gros van de systemen heeft het geen voordelen.
Beetje typisch voor de digital transformation.
Roepen, uitvoeren en niet terugkijken of het er nou beter op is geworden.
Door ai en automatische spellingchecker was de typo bijvoorbeeld waarschijnlijk al meteen gecorrigeerd.
Mijn two cents: proberen is goed, maar integraliteit kent vele verschillende lagen. En iemand die ergens in je landschap op een vierkante postzegel zaken zit te “probleren” kan zonder het zich te beseffen ergens anders iets teniet te doen. Wat ik vaak zie is dat de uitkomst van de “probleren” (ik noem dat gewoon een PoC-je of deep-dive doen) alleen maar op de onderhavige casus wordt toegepast en niet verder in de organisatie. Wat we dan ook niet moeten vergeten dat vaak al veel van de gewenste uitkomsten vaak bestaan binnen de organisatie, maar het niet bekend is. Ik ben wel voor experimenten, maar alleen in de veranderorganisatie, niet in de staande, dan moet het “gewoon werken”.