Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Agile is klaar voor de volgende stap

 

Computable Expert

Mark Mastop
Manager, WHYELLOW. Expert van Computable voor de topics Management en Mobility.

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?

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4929151). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

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.

@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."

Zie je wel dat je het best begrijpt. Of die kelder er nou door technische beperkingen achteraf niet meer ingebouwd kan worden is van ondergeschikt belang. De business wil het gewoon kunnen roepen tegen de productowner (in scrum) en die wil de bouwvakkers zien zweten. Anders krijgt volgende keer een andere aannemer de opdracht. Is dat altijd handig ? Boeit niet.
Rijnlandse en Angelsaksische paradigmas bestaan niet in Agile. Business betaalt en beslist. Scrum master heeft geen machtsrol. Die dient alleen het (door jouw verfoeide) scrum proces.
Technisch projectleider, kan wel in Agile, niet in Scrum. Knopen doorhakken ? Tegen die tijd is de business al volkomen Agile van eisenpakket veranderd. Wendbaarheid he. Bouw nou gewoon die kelder. Voor jouw bezorgde, kritische, vakkundige, ervaren, luisterende, communicatieve, oplossingsgerichte houding is geen plaats in Agile land. Heb jij weer, is Nederland net een koploper op dat gebied ;-)

@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.


Agile. Als ik het woord voor de zoveelste keer lees, in om het even welk artikel, trekt er een gapen door mijn kaken.

Agile in IT
Ongetwijfeld zal het zo zijn dat agile in tal van takken van sport hele mooie dingen doen...... maar niet in IT. De reden? Agile is namelijk niet lineair. Het laat teveel zaken open waardoor teveel eventualiteiten, (Aanpassing/Changes) invloed kunnen hebben op beoogde It processen. I^T processen houden hier in de regel niet van en vallen domweg om.

Natuurlijk, Agile kent 101 excemptions.
Precies een excemption is een bijzonder gevaar in IT. Het is Do or Don't. Niet we gaan het proberen op deze manier tot.....

Agile samenwerken
Als het al zo is dat men binnen IT met twee basale componenten, ITIL en 'Decent Project Management', ongeacht hoe u de laatste wil noemen, nog steeds niet helder en solide op elkaar worden afgestemd, men geen oog heeft voor IT als materie en diens wetmatigheden, dan heeft agile geen enkele toegevoegde waarde.

Dus klaar voor de volgende stap? Het kan zo maar zijn. Maar binnen de wereld IT? Ik betwijfel het.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×