Agile is de laatste jaren in een stroomversnelling terecht gekomen. Toch zijn deze agile-ontwikkeltrajecten slechts de eerste fase van de adoptie van agile, want in een streven naar meer snelheid, wendbaarheid en flexibiliteit dendert de sneltrein voort. De eerste stappen naar een volledige agile-organisatie worden momenteel gezet.
Momenteel ontwikkelt 83 procent van de organisaties al agile of heeft plannen om dit in de toekomst te gaan doen. Agile-ontwikkeltrajecten beloven ten slotte een aanzienlijk kortere doorlooptijd dan bijvoorbeeld ontwikkeltrajecten middels waterval. Aangezien agile-ontwikkeling inmiddels bijna gemeengoed is geworden, wordt het voor organisaties steeds moeilijker om zich hiermee te onderscheiden. Daarnaast is de transitie van waterval naar agile weliswaar een stap in de goede richting om de doorlooptijd van projecten aanzienlijk te verkorten, maar uiteindelijk schieten ook agile-ontwikkeltrajecten tekort.
Vooral de afhankelijkheid van de ontwikkelaar speelt organisaties parten. Business-gebruikers formuleren zorgvuldig de requirements, maar blijven uiteindelijk altijd afhankelijk van de ontwikkelaar. Deze interpreteert de specificaties van de business en zet deze om in code. Hierdoor hebben de business-gebruikers niet direct invloed op het resultaat, waardoor in de praktijk trajecten vertraging oplopen. Juist het programmeren zorgt ervoor dat organisaties in een harnas zitten en zich maar moeilijk kunnen bewegen. Tijd dus om de focus te verleggen naar de volgende stap: volledige agility.
Bereik volledige agility
Om volledige agility binnen een organisatie te bereiken is het noodzakelijk dat er een brug geslagen wordt tussen business en it. Uiteindelijk hebben de business-gebruikers de juiste kennis en ervaring van de processen, het beleid, de klanten en de structuur van de organisatie en weten zij als geen ander wat wel en niet werkt. Om geen vertraging en ruis op te lopen is het daarom noodzakelijk dat zij aan de knoppen zitten. Natuurlijk is het wat veel gevraagd om de business aan het programmeren te krijgen, maar door hen de juiste tools aan te reiken waarmee zij zelf aan de slag kunnen, wordt hetzelfde effect behaald.
Modelleren is het sleutelwoord
Door toepassing van een model driven architecture of door implementatie van een business process management (bpm)-oplossing ligt de nadruk op modelleren in plaats van op programmeren. De business gebruikers kunnen zich hierdoor richten op de inhoud van bepaalde functionaliteiten en de it op de techniek die erachter schuilgaat. It speelt in deze dus een faciliterende rol. Door business gebruikers een taak specifieke intuïtieve omgeving te bieden kunnen zij zelf modelleren. Wijzigingen kunnen hierdoor dagelijks naar productie worden gebracht zonder tussenkomst van de ontwikkelaar. Er zijn al een aantal succesverhalen van organisaties die de ontwikkeltijd hebben weten te reduceren van zes maanden naar zes weken door middel van deze aanpak. Toch zijn er een aantal zaken die organisaties niet uit het oog mogen verliezen als zij willen inzetten op volledige agility.
Het toepassen van bpm leent zich bijzonder goed voor middelgrote organisaties. Het is echter wel van belang dat er een intrinsieke wil aanwezig is om kort cyclisch te veranderen. Daarnaast moet er rekening gehouden worden met de gelaagdheid van de organisatie. Doordat business-gebruikers zelf direct aanpassingen kunnen doen in het resultaat komt namelijk de verantwoordelijkheid laag in de organisatie te liggen. Zij worden hierdoor verantwoordelijk voor bepaalde processen. Over het algemeen zijn hiervoor wel analytisch sterke mensen nodig.
Kruip uit het harnas
Agile staat aan de vooravond van de volgende stap. Tegenwoordig is agile ontwikkeling niet meer voldoende om mee te kunnen met de verandersnelheid van deze tijd. De wensen en eisen van de business moeten perfect en te allen tijde snel geïmplementeerd kunnen worden. Het is zaak dat de systemen dit faciliteren. Door business process management te implementeren kunnen business gebruikers direct veranderingen doorvoeren en zelf dagelijks aanpassingen doen. Organisaties worden hierdoor niet meer beperkt, waardoor betere resultaten behaald kunnen worden op het gebied van snelheid, wendbaarheid met een kortere time to market. Dit is wat mij betreft het toppunt van agile en door deze aanpak kunnen de oude vertrouwde ontwikkeltrajecten hierdoor vaarwel worden gezegd. Nederland is zeker een koploper op dit gebied en ik verwacht dat deze trend in 2018 volledig gemeengoed is geworden. Wat denken jullie?
@Louis
nog een variant,…
als iedereen het zelfde weet wordt er ook het zelfde gekozen… en gedaan..
@Maarten Dat lijkt me een ideaal plaatje, alleen weet niet het iedereen hetzelfde denk ik en in ieder geval krijg je te maken met verschillende meningen en ideeen over de uitvoering. Waar het me om gaat, ik geloof er niet in dat een team beslist. En van de beslisser mag je verwachten dat hij een technische afweging kan maken.
@Maarten
Als iedereen hetzelfde kiest wordt er niet meer gekozen ;D
Agile is toch een beetje programmeren volgens het Scrum model, of heb ik dat fout?
@Louis,
ik spreek toch uit vele projectervaringen 🙂
Louis jongen, ik zal het je nog es een keer voormauwen. Die agile.
In Agile plan je per iteratie, in scrum een sprint genoemd. Niet op elk moment dus, maar per iteratie.
Specificaties zijn minder formeel dan in waterval, omdat men ze gewoon minder van waarde vindt : Working software over comprehensive documentation. Agile manifesto. Men weet niet precies wat men wil tot men het looked en feelt, is de rationale.
“even agile en scrummende een huis bouwen en dat de productowner aan het eind zegt: nou een kelder is ook wel geinig. En oh ja, de bouwvakkers beslissen samen als team.”
@Maarten Bofkont. Hoe kan dat? Mijn ervaring is, soms klopt het wel en soms ook niet, een project. Misschien zegt het ook iets over de uitvoerder…:)
@mauwerd Bedankt voor de puntige uitleg, helderheid op het vlak van agile en scrum is altijd welkom. Nederland koploper op dit gebied? Oh jee, dat is niet zo mooi. Ik vind wat jij schrijft ook niet echt opwekkend en mijn vraag is of dat leuk is als technisch en uitvoerend ict’er. Maar misschien heb je wel gelijk en moet je die ongelukkige bijverschijnselen maar voor lief nemen en gewoon die kelder erin wrotten als daar om gevraagd wordt. Ik vind het vooral een slecht teken en slecht voor de kwaliteit maar je hebt gelijk wie betaalt bepaalt. Overigens, ik vind dat er ook wel iets goed is aan de scrum methode. De heartbeat aan een project geven vind ik sterk.
Als het nu toch over religie gaat, heb me wat verdiept in het Rijnlands en Angelsaksisch model. Kwam op een artikel terecht met een beschrijving van beide en volgens mij is de praktijk een bonte kruising van de twee. Las dat hier ook al eerder in een reactie. Maar als je leest over agile/scrum/etc, het gaat om samen, met alle belanghebbenden en het team dat bepaalt. Dat doet ibderdaad denken aan het Rijnlands model. De vraag is wat er eerder was. Volgens mij is dit meer theorie dan praktijk en het heeft het inderdaad niet zoveel te maken met agile/scrum/etc.
Over het artikel, ik reageerde wat gebeten over het feit dat daarin stond dat programmeren de reden is dat organisaties in een harnas zitten en een rem is op de volledige agile organisatie wat zou staan voor: snel, wendbaar en flexibel. De oplossing voor volledige agility zouden tools zijn waarmee ‘de bussiness’ zelf zijn toepassingen kan specificeren en in elkaar draaien. Ik vraag me af of dit soort toepassingen al bestaat die zo volledig zijn dat alle benodigde functionaliteiten daarin (bij voorkeur klikkend en slepend) gebouwd kunnen worden zonder tussenkomst van een programmeur. Je dekt er zeker geen ingewikkeld applicatie landschap mee af. Een realistischer benadering van ‘agile’ en het hebben van reële ambities lijkt me verstandiger. Wendbaar en flexibel ben je maar in beperkte mate en goede software maken kost tijd. Agile is niet hetzelfde als van de hak op de tak kunnen springen.
Lees net trouwens weer een artikel op computable met ongeveer dezelfde strekking, dus het leeft wel.
@mauwerd: De Agile aanpak is een stuk volwassener dan jouw perceptie ervan. Jammer dat je dat inzicht mist en je er toch mee profileert.
Anko,
Kun je me eens duidelijk maken waar mijn inzicht en perceptie van jouw werkelijkheid afwijkt ? Ik haal mijn informatie vanuit de vakliteratuur en ik probeer daarbij zo dicht mogelijk bij bron (manifesto, scrum guide) te blijven en die te combineren met mijn eigen ervaring. In het artikel lees ik niets dan vaagheden (modelleren, verwijzing naar succesverhalen, zonder bron), cliche frasen (“… is het noodzakelijk dat er een brug geslagen wordt tussen business en it), meningen (volledige agility ?) wtf 😉
Jij gaat vrolijk verder in je eerste reactie : wendbaar, proactief, meer waarde creeerende blaa.
Daar waar je concreet wordt, ga je tegen de de Agile concepten in of verzin je er e.e.a. bij:
– document niet mailen, maar uitgebreid in meeting bespreken. :
Scrum guide : minimize the need for meetings. Er zijn er max 4 en die zijn voorgeschreven en timeboxed
– Rijnland/Angelsaksisch model wordt door jou hier geintroduceerd in Agile context. Waar kan ik daar wat over lezen in Agile/Scrum Literatuur ?
– “Vast staat dat diegene met het meeste verstand van het onderwerp, het besluit neemt”. Wat als jij en ik in zo’n team zitten, samen met Louis ? Wie zou het besluit nemen dan ? We hebben natuurlijk allemaal meeste verstand ervan wellicht. Antwoord is overigens natuurlijk de baas he, weten we allemaal stiekumm, Louis in ieder geval zeker.
Louis is ervaren developer en heeft al heel wat project- en ontwikkelmethoden zien komen gaan. Hij wil gewoon weten wat er van hem verwacht wordt, wat hij moet doen in het oerwoud van moderne conflicterende methoden, meningen en eigen ervaring.
– wie hakt (implementatie)knopen door ? : Scrum stelt dat het team er wel uit komt en dat er geen leider is. Mijn ervaring is dat een beslissingbevoegde leider duidelijkheid schept in geval van verschillende meningen en die heb je nog wel eens bij ervaren, capabele geselecteerde teamleden, maar juist weer niet bij Scrum
– hoe moet je ontwerpen in Scrum ? : moet het op bierviltje passen ? zoja wat is dan de kwaliteit ervan.
– is integration testing zonder dedicated testers en zonder Continuous Integration mogelijk, zo ja hoe dan ? Zo nee, hoe test je dan ?
– business eist wendbaarheid, maar hoe ontwerp en bouw je een kelder tussen je fundamenten als het gebouw er al half staat ? Is erinwrotten een optie ?
– kan business modellerend zonder technisch inzicht applicaties in mekaar kan clicken, zonder begeleiding van programmeur ? Ik hoor er al 20 jaar over. Beloftes over 4e, 5e generatietalen, terwijl nu OOP nog niet eens gebruikt wordt.
Komop Anko, help Louis eens in zijn queeste. Hij doet zo zijn best. En ik kom zelf niet verder dan mijn paradigma “kop houwen en kelder bouwen”.
Ik lees in de laatste paragraaf het volgende: “Agile staat aan de vooravond van de volgende stap. Tegenwoordig is agile ontwikkeling niet meer voldoende om mee te kunnen met de verandersnelheid van deze tijd.”
Tsjonge, worden we als IT dan gevraagd helderziend te zijn en al de juiste IT op te leveren voordat de business zelf begrepen heeft wat ze wil?
Een goed ontwerp maken vraagt tijd. Mauwerd geeft heel goed aan waarom. Maar ja, in onze zapcultuur gooien we het liefst onze nieuwe speeltjes al in de hoek voordat we ze gekregen hebben. Dan zul je ook nooit tevreden worden.
Als ik dit artikel en de reacties daarop lees, schiet mij ineens een uitspraak in het hoofd, welke – denk ik – toepasselijk is :
“ONS GROOTSTE PROBLEEM IS DE VERWARRING OVER HET DOEL EN DE PERFECTIE VAN HET MIDDEL”
Graag wil ik een ieder helpen duiden waar – volgens mij – een ieders onbegrip ligt en mijn doorkijkje / tips geven. Laten we als 1e beginnen met respect te hebben voor elkaar expertise en bedenken dat we MET elkaar grotere kans hebben een antwoord op de puzzle te vinden.