Jaren geleden, dienden bestaande bedrijfsprocessen geautomatiseerd te worden. Dit werden complexe softwarepakketten met een scala aan paradigmaverstuivingen. Rijk aan onduidelijkheden vanwege de digitalisering van voorheen handmatige werkprocessen. Na een goede sloot geld lichter te zijn, ging de klant er vanuit dat dit prachtige stuk software hen wel weer een jaar of 10 zou bijstaan.

De software leverancier van destijds had de functionele wens zowaar kunnen vertalen naar een stuk software en deze na een periode van zeg een jaar, hopla, over de schutting gebonjour’d. Racend tegen de klok, het bleek veel complexer als gedacht maar de klant had al betaald.. Men wist toen ook niet veel beter. Iedereen deed het toch zo? Het was toch duidelijk wat de klant wilde? Wij begrepen het alleen niet. We nemen deze grote opdracht aan, dan zijn we komende tijd verzekerd van een mooie omzet.

En dan, een 5 a 10 jaar later, zitten beide partijen toch met de baked potato’s.. De klant merkt dat een wijziging van werkproces te moeizaam door te voeren is en het de organisatie tegenhoudt in de flexibiliteit. En de software leverancier heeft al een paar jaar een aantal programmeurs nodig om maar pleisters te plakken bij het langzaam bezwijkende softwarepakket. En om nou te zeggen dat het de software toko daar echt blij van wordt?

Software leveranciers komen erachter dat ze de programmeurs niet binnen kunnen houden, omdat ze niet met nieuwe innoverende zaken bezig kunnen zijn (die dienen tenslotte die pleisters te plakken voor de Sagrada Familia onder de software). De programmeurs die er nog wel werken, zijn bezig met verouderde technologieën, dus heel erg innoveren is ook niet ‘even’ te doen.

Daarbij is de klant van nu op zoek naar een flexibelere manier van het verkrijgen van hun (maatwerk-)software. Ze weten al aardig wat de valkuilen zijn; zo willen ze niet eerst een jaar wachten tot hun wens realiteit is geworden. Daarbij komt, bedrijfs-/werkprocessen veranderen zo snel, dat het begrijpelijk is dat je als bedrijf zijnde vandaag nog niet weet, wat je mogelijk morgen qua software wenst.

De situatie hierboven beschreven is de zogeheten ‘waterval’-methode. Bovenaan begint het met een klantwens. Gaandeweg de val wordt er ontwikkeld. En bij de plons wordt het opgeleverd.

Wat als de klant gaandeweg die val in kan spelen op het product? Toch wat andere functionaliteit? Of toch een andere prioriteit, ‘we willen die app toch al eerder live ,gezien we mobiel meer aandacht willen geven!’.

En zo ontstond er ‘agile’, Engels voor flexibel. Vaak ook bekend onder de term ‘SCRUM’, dit is een vorm van agile met een verder uitgewerkt process en rolverdeling. SCRUM zal in een volgende post verder aan het ligt komen. De basis met agile is het werken met iteraties/sprints. Dit zijn periodes tot een deeloplevering. Meestal van 2 a 3 weken. Zo wordt er elke iteratie weer een klein brokje functionaliteit opgeleverd aan de klant en kan deze dus veel sneller op de rem trappen, of de bevestiging krijgen dat ze op de goede weg zitten.

Kon het maar! Ikzelf ben er volledig voorstander van gezien beide partijen automatisch meer tevreden zijn en snel resultaat zien. Je bent tenslotte écht elkaars partner!

Enkel vind je niet zomaar een klant die een agile project zal aangaan. Dit om de volgende reden; ze zijn niet zeker van een product voor het geld wat ze neer leggen. Wat ze vaak nog niet inzien is dat ze er flexibiliteit voor terug krijgen. En aan het eind van de streep wél hebben gekregen wat ze willen!

Bedrijven die momenteel langzaam hun digitale transformatie doorgaan, komen er achter dat ze hun toekomstvisie zomaar op korte termijn willen bijschaven. Lang leve agile! Ze kunnen binnen een paar weken hun nieuwe wensen verwezenlijkt hebben.