Agile proces ≠ wendbaar systeem

In deze blog vertelt Willem wat het verschil is tussen wendbaarheid en agile werken, en hoe je beide strategieën kunt inzetten.
Agile proces ≠ wendbaar systeem

Agile proces ≠ wendbaar systeem

In deze blog vertelt Willem wat het verschil is tussen wendbaarheid en agile werken, en hoe je beide strategieën kunt inzetten.

Inhoudsopgave

Agile werken is hot. Logisch, want het is een flexibele en klantgerichte benadering die organisaties helpt snel te reageren op veranderingen en continue waarde te leveren. Maar hoe agile je processen ook zijn, het wil niet automatisch zeggen dat de systemen die je ontwikkelt ook wendbaar zijn. In deze blog vertelt Willem Otten, een van de oprichters van CrossBreeze, wat het verschil is tussen wendbaarheid en agile werken, en hoe je beide strategieën kunt gebruiken om je organisatie echt flexibel te maken.

Agile proces, maar geen wendbaar systeem

Agile werken wil niet automatisch zeggen dat je ook wendbaar bent. Je kunt je processen wendbaar maken en snel inspelen op nieuwe prioriteiten, maar als je systemen niet makkelijk kunnen veranderen, blijf je beperkt. Stel je moet van techniek A naar techniek B overstappen. Ook al heb je je bestaande systeem met een agile proces gebouwd, je kunt het niet zomaar veranderen. Het systeem zelf is niet wendbaar en dat beperkt je flexibiliteit.

Wanneer kan je legacysysteem eigenlijk uit?

We zien het regelmatig: Een nieuw datawarehouse is al jaren in gebruik maar de vorige implementatie draait er nog steeds naast. Het is veel handwerk om alle functionaliteiten opnieuw te implementeren en zolang er nog mensen mee werken kan je je legacysysteem niet zomaar uitzetten. Dit zie je bij veel bedrijven: ze bouwen nieuwe systemen met een agile proces, maar uiteindelijk draaien er meerdere generaties van een systeem naast elkaar. Nieuwe processen worden aangesloten op het nieuwe systeem, maar bestaande afdelingen blijven in het oude systeem hangen totdat alles is omgebouwd. Dit gebeurt netjes met sprints en elke twee weken worden de prioriteiten opnieuw bekeken. Na vijf jaar heb je misschien wel drie generaties systemen draaien. Als organisatie kom je zo niet echt verder. Er is dus een belangrijk verschil tussen wendbaar en agile zijn. Je kunt met het traditionele watervalproces een wendbaar systeem bouwen, maar je kunt ook met een agile proces een systeem bouwen dat niet wendbaar is. Het gaat erom dat je zowel je processen als je systemen wendbaar maakt.

Een houten huis wordt nooit van steen

Stel je voor dat je een huis bouwt van hout. Je kunt dat huis heel goed in een agile proces tot stand laten komen. Je begint met de fundering en daarna de eerste verdieping. Vervolgens besluit je dat op die verdieping een badkamer moet komen. Daarna ga je nadenken over de tweede verdieping, en uiteindelijk wil je ook nog een zwembad op het dak. Je besluitvorming kan heel dynamisch zijn, en je kunt per maand besluiten hoe de volgende verdieping eruit moet zien. Maar als je huis eenmaal klaar is, kun je niet ineens zeggen: “Nu wil ik dat huis van baksteen hebben.” Hoe je het ook wendt of keert, het blijft een houten huis. Je zou het compleet opnieuw moeten bouwen om er een stenen huis van te maken met alle extra materiaal- en arbeidskosten van dien.

De noodzaak van een tekening

Vergeleken met het opnieuw bouwen van een huis heb je bij de herontwikkeling van een softwaresysteem veel minder materiaalverlies, maar ook dit is een kostbare aangelegenheid wanneer je alle functionaliteiten opnieuw moet ontwikkelen met een andere techniek. Bij CrossBreeze werken we daarom altijd vanuit een tekening voordat we beginnen met de implementatie. Deze tekening is grotendeels techniekonafhankelijk en bepaalt hoe het systeem eruit gaat zien. De implementatie verloopt vervolgens grotendeels gerobotiseerd waardoor de tekening altijd actueel blijft. Even terug naar het voorbeeld van het huis. Stel dat je een actuele bouwtekening zou hebben van je houten woning en een robot die geïnstrueerd kan worden om op basis van deze tekening een stenen woning te maken. Het herontwikkelen van je stenen woning zal dan een stuk goedkoper en efficiënter zijn. Onze modelgedreven aanpak maakt dit mogelijk voor dataoplossingen.

Voordelen van een modelgedreven aanpak

Het grote voordeel van onze aanpak is dat je met terugwerkende kracht zowel je bestaande als toekomstige systeem kunt verbeteren. Het is eenvoudiger om van technologie te wisselen. De keuzes die je nu maakt, kun je later herzien zonder opnieuw te hoeven beginnen. Hierdoor hoef je bij de start van een project niet alles perfect uitgekristalliseerd te hebben. Vaak proberen mensen dit wel, net zoals een architect een huis eerst helemaal tot in de puntjes uitwerkt voordat er gebouwd wordt. Bij ons hoeft dat niet. Je kunt bijvoorbeeld snel een behangetje aanbrengen en later besluiten dat een ander materiaal leuker is. In de IT wordt er veel nadruk gelegd op techniekkeuzes die toekomstbestendig moeten zijn. Met onze werkwijze kun je echter zeggen: “We dachten A, maar zien nu dat het anders wordt,” en daarop inspelen.

Het belang van een flexibele tekening

Wij hebben het vaak over het wat en het hoe. Dus in je tekening zet je vooral het wat, de functionele logica. Hoe dat dan gebeurt, met welke techniek, daar ben je flexibel in en dat kun je gaandeweg herzien. Iedereen die een nieuw huis laat bouwen, weet dat je gaandeweg altijd afwijkt van de initiële bouwtekening. In softwareland is het precies hetzelfde. Je kunt maar beter een proces hebben dat daar van begin af aan goed mee om kan gaan, dan een statisch proces waarmee je iets creëert dat na dag één al verouderd is.

Begin vandaag met modelgedreven werken

Door een modelgedreven aanpak te hanteren, kun je je dataoplossingen wendbaar maken. Benieuwd hoe dat werkt? Neem contact met ons op voor een vrijblijvend gesprek. Laten we de stap zetten naar een efficiëntere en effectievere manier van werken.

Onze artikelen voortaan in je mailbox ontvangen? Abonneer je dan op onze nieuwsbrief!