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?
Modelleren noch het implementeren van BPM is het antwoord op meer Agile organisaties.
Het zijn wel beiden “een van de antwoorden”.
Maar het gaat natuurlijk helemaal niet om meer Agile organisaties, wel om wendbaarder, proactievere, meer waarde creërende organisaties 🙂
Dat wordt lachen. Gebruikers die zelf hun systeem onderhouden of configureren of programmeren of hoe je het maar noemen wilt. Geen IT-er meer nodig straks…
Als dat maar goed gaat. Gaan deze gebruikers ook zelf hun auto repareren en onderhouden zonder hulp van een garage? Voordeel is dat volledige controle hebben.
Agile is een veel gebruikt woord maar ik begrijp nog steeds niet wat het betekent en ik twijfel ook of daar een algemeen beeld van is als ik de artikelen over dit onderwerp lees. Het blijft vaag. Het idee wat ik bij agile heb is dat je bij aanvang van projecten ruimte overlaat voor onzekerheid en dat er ruimte is voor hoe de oplossing er uiteindelijk komt te zien en dat je in de loop van een project je gedachten vormt. Dat is niet zo gek, dat is ook hoe programmeren werkt. Je weet waar je ongeveer heen wilt en hoe je dat wilt doen maar de tijd moet zijn werk doen om een en ander duidelijk te krijgen. Je gooit code weg, je programmeert onderdelen opnieuw. Een iteratief proces. Agile betekent zeker niet dat je continu je plannen aanpast op iedere moment van de projectuitvoering: uiteindelijk moet je wel beslissingen nemen wat het uiteindelijk gaat worden, er moeten keuzes gemaakt worden. Om dan nu de programmeur, de man of vrouw die aan het einde van de lijn zit als belemmerende factor te noemen vind ik onbegrijpelijk. Mijn vraag is dan ook of er dan wel een goed begrip is van het bouwen van software.
Inderdaad zijn de gebruikers de personen die het beste inzicht hebben in wat nodig is en hoe de processen in elkaar steken. Aan de andere kant zijn het de ontwerpers/ontwikkelaars die horen te weten wat de mogelijkheden en de beperkingen zijn. Ik ben ook van mening dat de specificaties door een ontwerper gemaakt worden of in ieder geval de ‘bussines’ of de ‘gebruikers’ de handvaten geeft om specificaties op te stellen die realistisch en haalbaar zijn. Die specificaties zijn uiteindelijk het referentiepunt voor zowel gebruikers als ontwikkelaars. Maar ik vraag me af, bestaat dat nog functionele specificaties? Of is tegenwoordig alles een grote todo lijst?
@Louis
Is het leven volgens de media niet een grote todo lijst?
Ja, ook ik heb moeite met het beeld van Agile dat hier geschetst wordt. Natuurlijk is het een handige werkwijze, maar niet altijd de meest handige. Software ontwikkelen is een aaneenschakeling van activiteiten en producten die allen van hoge kwaliteit dienen te zijn om het gewenste resultaat te behalen op efficiente wijze. Of dat nu waterval is of Agile, dat maakt niet uit. Beide methodes hebben voor- en nadelen, maar het lijkt wel of Agile de oplossing is om activiteiten en producten van lage kwaliteit weer goed te maken en dan ook nog eens het gewenste resultaat behalen op een efficiente wijze. En waterval lijkt wel een door Fred Flintstone geintroduceerde werkwijze die vreselijk achterhaald is en alleen maar zorgt voor ellende. Is het misschien mogelijk dat je beide methodes wilt toepassen daar waar deze het best aansluit op de omgeving/situatie/mogelijkheden? Als je echt Agile bezig bent, dan gebruik je ook waterval daar waar het beter past! Of ben ik dan te Agile?
Zeker niet, CK. Voor interfaces realiseren is goed vooraf nadenken sowieso zeer relevant – je wilt niet IN de sprint gaan nadenken welke velden je aan elkaar wilt gaan koppelen. Dat hoort er toch echt aan vooraf.
Waar het meestal op schuurt zijn de culturen: veelal wordt er vanuit een traditioneel gestuurd op taken afronden en niet op het integraal (met elkaar, als team, vanuit verschillende disciplines bekeken) oplossen van het dilemma. Of je moet een document opleveren en je stuurt het op de mail ter review, in plaats van de uitkomsten presenteren in een presentatie en zo veel effectiever communiceren. Denk bijvoorbeeld aan dit kader: http://www.agilemodeling.com/essays/communication.htm
Dus JA, als je de Agile benadering van veel communicatie, teamwork en samenwerking toevoegt in een traditioneel project, dan ben je ook veel effectiever. En als je Agile doet zonder gezamenlijke sessies, demo’s en iteratieve opleveringen dan werkt dat ook echt niet…
@Johan Je hebt gelijk. Ik begreep niet helemaal wat je bedoelde totdat ik deze week een artikel las over mensen die het ook hadden over een todo lijst van dingen die ze nog wilden doen: bungeejumpen, de reis naar nieuw zeeland en zo. Toch vraag ik me af of dat werkt, 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.
@Anko Ik lees veel het over zelflerende team en vooral same samen en samen (Haarsma Buma) maar wie is er nu verantwoordelijk voor het doorhakken de van knopen betreffende de uitvoering? Dat kan een team natuurlijk niet beslissen? Bestaat er iets als een technische projectleider? Of zijn het dan de productowner of de scrum master met het machtswoord?
Mark,
Het lijkt erop dat je profiel niet meer helemaal up-to-date is, aangezien je hier nog spreekt van “Business Process en Business Rules Management” ofwel BPM en BRM. De vraag is in hoeverre nog sprake is van BRM nu je hier een pleidooi voert voor Model Driven Architecture (MDA).
Een zuiver BRM-standpunt lees ik nog in een (niet op internet terug te vinden) interview in Business Process Magazine nr. 8 van december 2006, waar letterlijk staat:
“Onze aanpak wijkt dus fundamenteel af van de populaire ‘model driven architecture’ (MDA) methode voor het ontwikkelen van informatiesystemen. Bij onze aanpak is het model zelf reeds de oplossing. Bij MDA dient vanuit het model eerst nog eens software te worden gegenereerd en geïnstalleerd.”
Dit “zuivere” BRM-standpunt is ook terug te vinden op deze site in het eerste deel van de artikelreeks “5GL springlevend”; om precies te zijn onder het kopje “Waarom maakt MDA het ideaal niet waar?”.
Het doet mij dus deugd dat je het BRM-standpunt van 7 jaar geleden inmiddels hebt prijsgegeven; nu je BPM-standpunt nog….
@Louis, het hangt er van af welke besluiten er genomen moeten worden. Vast staat dat diegene met het meeste verstand van het onderwerp, het besluit neemt. Het (Rijnlands) paradigma van Agile luidt nl “Wie het weet, mag het zeggen”. Dit staat tegenover het Angelsaksich paradigma “wie de baas is, mag het zeggen”. Het gaat dus niet om de rol, maar je kennis van het onderwerp.
@Anko Dank voor de reactie. Wie het weet mag het zeggen klinkt redelijk maar ik denk dat in een team met eigenwijze IT mannen en vrouwen er vast meer zijn die het weten. Dus aan beslissingen over de technische uitvoering ontkom je niet. Ik zou zeggen de technisch projectleider is de man om knopen door te hakken. Maar die rol lees ik nog maar heel weinig. Rijnlands vs. Angelsaksisch, ik lees het hier veel, zou toch denken dat wij hier meer Angelsaksisch is. Ik ga op zoek wat het is.