Steeds meer bedrijven zien de voordelen in van een Agile-aanpak bij daarvoor geschikte projecten. Dit geeft heel veel voordelen omdat de business user tijdens het gehele verandertraject aangehaakt wordt, sterker nog, een cruciale rol speelt. Met als gevolg, een goede user adoptie en meer samenwerking tussen business en it.
Keerzijde is wel dat zo’n business user wel een dubbele wissel trekt op z’n werkweken, hij is immers bezig met de dagelijkse operatie en actief betrokken met het project. Dan kan zo’n traject maar beter met high speed plaatsvinden.
In het 2012 Agile Survey van Xebia staat dat 38 procent van de deelnemers aan dit onderzoek, ontwikkelteams in organisaties heeft die op een Agile-wijze werkt. Deze trends zullen zich naar verwachting doorzetten omdat het steeds meer gewoongoed wordt en de eerste angst voor agile, ‘Ik geef je een zak met geld en ik heb geen flauw idee wat ik straks ga krijgen’, is wegens de positieve resultaten grotendeels verleden tijd. Verderop in het onderzoek staat ook wat de effecten zijn van deze manier van werken. Maar liefst 57 procent geeft aan een snellere time-to-market waar te nemen en 51 procent geeft aan een hoge productiviteit te ervaren.
Allemaal goed nieuws, positieve resultaten en innovatie vieren hoogtij. Het duurde een kleine twintig jaar maar nu begint het vroegere ‘prototyping’ echt een prominente plaats te krijgen in ontwikkeltrajecten. Wat opvalt is dat deze voordelen veelal van toepassing zijn op de organisatorische kant van het project en helaas nog geen voordelen kan boeken op de technische realisatiekant van het traject.
Op z’n Hollands; we krassen nog steeds met code, iets wat we dertig jaar geleden ook deden. Dat is precies waar nog veel winst valt te behalen. Zodra we andere tools gaan gebruiken om de software te ontwikkelen, zal er veel meer geproduceerd gaan worden in een veel kortere tijd. De sprint demo’s zullen veel interessanter worden en de doorlooptijd van de projecten significant korter. Zeer waarschijnlijk zal de business user een betere bijdragen aan het project kunnen leveren, immmers de totale doorlooptijd is vele malen korter en is in combinatie met z’n dagelijkse werk beter te behappen. Deze business user zal zich dus beter kunnen comitten aan dergelijke intensieve projecten.
Kortom innovatie binnen ontwikkeltrajecten is met de Agile-aanpak goed op dreef maar er kan nog veel meer winst uit dergelijke projecten worden gehaald. Een van de weinige bastions die nog wacht is het productiever maken van het softwareontwikkelproces. We hebben geen Development Strategy Survey nodig om nu al te kunnen bepalen dat met gebruik van modernere tools en de Agile-aanpak, echt snelle time-to-market gaan krijgen en een geweldige productiveit mogen ervaren.
Het is december 2013. Laten we het laatste bastion bestormen en gaan voor het creëren van optimale innovatie.
tjakaaaaa!!
Beste Mark, je verhaal sluit niet echt aan bij mijn belevingswereld als softwareontwikkelaar die nu een krappe twintig jaar met beide voeten in de modder staat.
Als er tools zouden zijn om beter en meer efficiënt te kunnen werken dan zal een programmeur daar maar wat graag mee willen werken. In de praktijk is het juist vaak dat deze hogerop wordt tegengehouden omdat het te veel zou kosten of dat er geen tijd is om om te schakelen. Dus in die zin kan ik wel met je meegaan dat je als instelling wel de moeite moet doen om zoveel mogelijk gebruik te maken van de nieuwste ontwikkelingen.
Wat softwareontwikkeling betreft lijkt dat er weinig innovatie heeft plaatsgevonden maar dat valt op zich wel mee. De tools zelf innoveren maar mondjesmaat en het aantal API’s lijkt exponentieel te groeien. Alleen is het punt dat vaak instellingen te eigenwijs zijn om bestaande standaarden te willen gebruiken en ze dus op maatwerk terug moeten vallen. Daar gaat behoorlijk wat tijd en moeite in zitten en dus daar valt ook het meeste te winnen.
De claim dat er extreem veel ontwikkeltijdswinst te behalen valt zou ik eigenlijk als spookgedachte durven te bestempelen. En wat dat betreft ben ik al te vaak managers tegen gekomen die liever in hun eigen wensdenken wilden geloven dan aan te nemen dat sommige dingen nou eenmaal tijd nodig hebben om goed gebouwd te hebben.
Goedemiddag Johan,
Graag maak ik een afspraak met je om e.e.a. toe te lichten. Zelf spreek ik uit harde ervaringscijfers, die zeer positief te noemen is.
Een mooie, realistische kijk op Agile. De visie dat softwareontwikkeling de vertragende factor is lijkt mij zeer juist. Deze visie werd in 2006 al door A. Hartman heel knap verwoord in het tweede deel van zijn boeiende artikelreeks “4GL springlevend”:
“Ondertussen staat de software-industrie op het punt van ontwikkeltechnologie eigenlijk stil. Voor mij is dat een raadsel in een zo dynamische industrie. De 4GL-omgevingen zijn alle ontstaan in de tachtiger en negentiger jaren van de vorige eeuw. De 3GL’s die algemeen in gebruik zijn, zijn eveneens 15-20 jaar oud of een recente combinatie van bestaande talen (C#). Er is geen zicht op de volgende stap die men 5GL zou kunnen noemen. De software-industrie blijft steken in de technologie. Er komt wel steeds nieuws, maar in de fundamentele combinatie van productiviteit, kosten en kwaliteit verandert niet veel. Software ontwikkelen blijft een moeizaam proces dat veel geld kost; vervolgens kost het nog veel meer tijd en geld om de ontwikkelde software op een goed kwaliteitsniveau te krijgen. Het wordt hoog tijd dat iemand een briljant idee heeft dat de basis kan vormen van 5GL-producten die een grote stap voorwaarts zouden moeten zijn in productiviteit, en kwaliteit en de kosten en het tempo van softwareontwikkeling naar een volgend niveau zouden moeten tillen.” [Einde citaat]
Hoogste tijd dat we overschakelen van 3GL bedrijfslogica (in Java, Cobol, etc) naar 5GL bedrijfsfunctionaliteit; ik hou het op SOA, beslissingstabellen en doelgerichte redeneermechanismen.
Met als resultaat: Agile onder Architectuur.
“Wat opvalt is dat deze voordelen veelal van toepassing zijn op de organisatorische kant van het project en helaas nog geen voordelen kan boeken op de technische realisatiekant van het traject.”
Mijn interpretatie hiervan : “er wordt steeds leniger ge-OH-d. OH, omdat de business niet betere specs levert, maar zich het recht toeeigent om op elk moment maar wat te roepen. Wendbaar noemt men dat. De programmeur is tot beperkende factor verklaard. Jammer, OH runt nog steeds niet op een computer.
In een reactie lees ik dat dit artikel een realistische kijk geeft op Agile. Ik lees ook :
50% heeft positieve resultaten met Agile (zonder bronvermelding uiteraard). EEh dus, 50% negatieve ? Verder proza over goed nieuws, positieve resultaten, geweldige productiviteit en daar hebbenwenumweer snell time-to-market. Survey niet nodig. Tis gewoon zo ?
Zelf kras en klop ik code. Al heel lang. Niet in machinetaal, assembler, maar in de meest productieve, abstracte omgeving die het project/bedrijf toelaat of voorschrijft. Meestal derde generatietalen dus. Niet mijn idee. Ik kan er niets aan doen. Johan Duinkerken ook niet.
Oplossing volgens Jack Jansonius : “Het wordt hoog tijd dat iemand een briljant idee heeft dat de basis kan vormen van 5GL-producten die een grote stap voorwaarts zouden moeten zijn in productiviteit, en kwaliteit en de kosten en het tempo van softwareontwikkeling naar een volgend niveau zouden moeten tillen.”
Een mooie realistische kijk op Agile..
Het is december 2013. Laten we het laatste bastion bestormen en gaan voor het creëren van optimale innovatie.
@Jack Ik vind de bewering dat software bouwen de vertragende factor is een verkeerd en negatief uitgangspunt. Zeker niet realistisch. Nog maar weer een keertje: software maken kost tijd, goede software maken kost nog meer tijd. En als het bouwen van software de ‘snelheid, wendbaarheid en flexibiliteit’ van de organisatie niet aankan dan zit er denk ik eerder in die organisaties iets heel erg fout. Ik weet dat verandering voor veel organisaties de core bussiness is maar ik denk dat het een slecht teken is als de organisatie het eigenlijk niet weet en dat het steeds weer anders moet. Kan me trouwens niet eens voorstellen dat het zo werkt in de praktijk bij een goed geleid bedrijf/organisatie.
Volgens mij is het nog niet veel die 5GL talen maar dat betekent niet dat je bv die beslissingstabellen prima kan gebruiken, in je specificaties bijvoorbeeld. Iedereen die Agile werkt weet hoe belangrijk documentatie is en zeker functionele specificaties zijn daarbij een must. Ken Schwaber vind dat ook. Hierin kan je alle energie en ideeen kwijt over 5GL en een poging te doen op een zo formeel mogelijke manier je specificaties op te stellen. Ik denk dat er veel mensen een plezier mee gedaan wordt, zeker de bouwers.
@mauwerd,
Ten aanzien van de hete hangijzers in discussies rond bedrijfstechnologie, zoals cloud computing, agile applicatieontwikkeling, big data, en misschien nu ook weer eens 5GL, vormen zich steevast 3 kampen:
1. de sceptici, – meestal conservatief -die vooral denken in problemen,
2. de idealisten – soms ook evangelisten genoemd -, die vooral de mogelijkheden zien, en
3. ergens in het midden de realisten, die zowel oog hebben voor de mogelijkheden als voor de problemen.
Als in dit opiniestuk dus ergens wordt beweerd dat 50% van de bedrijven positieve resultaten heeft met agile, dan klopt dat dus precies met een realistische kijk op agile. Want de scepticus zal het op 0% houden en de idealist op 100%; hiervoor is inderdaad geen enkel verder onderzoek nodig 🙂
@Louis,
Eigenaardige argumenten voer je in deze discussie aan, omdat je steevast mijn visie bevestigt (waarvoor dank).
Ik zeg, net als de schrijver van dit opiniestuk, dat software bouwen (inclusief testen uiteraard!) de vertragende factor is, en jij zegt: software maken kost tijd, goede software maken kost nog meer tijd.
Dat beweer ik dus ook; waar we dan van inzicht verschillen is, dat jij dit blijkbaar als een vaststaand gegeven aanneemt, en ik nog veel mogelijkheden zie om dit ontwikkeltraject te versnellen.
Ik zeg: hoogste tijd dat het nu wel eens met 5GL gaat lukken; jij zegt: “Volgens mij is het nog niet veel die 5GL talen “. En bedankt, dat is ook wat ik beweer.
Als je nu ziet dat veel bedrijven hun bedrijfslogica vastleggen in een 3GL-taal als Java, is dat dan niet een stap terug ten opzichte van het gebruik van bijvoorbeeld 4GL Cobol-generatoren?
ik zeg iets anders. Als je iemand wilt overtuigen dat een nieuwe aanpak juist is, dan is rond de 50% positieve resultaten niet doorslaggevend. Das zegmaar, geen businesscase.
Realisten vragen zich af, hoe het onderzoek is uitgevoerd en wat die andere helft dan te melden heeft.
Louis zegt ook iets anders. Hij zegt dat een zwalkende business, eerst maar eens bij zichzelf te rade moet gaan. Daar kan ik met zelf wat bij voorstellen. Visie, consistentie, continuiteit, slagvaargdigheid. Allemaal business kwaliteiten. Verder zegt hij (nog maar weer een keertje) dat het maken van goede software tijd kost. Realisten zien dat de markt geen geschikte 4e en 5e generatietalen biedt, terwijl er een gigantische vraag naar is. Kennelijk is het niet zo eenvoudig.
Hoogste tijd dat de Messias op aarde komt, iets tegen aids en kanker wordt uitgevonden, de crisis over is, een nieuwe Mandela…
@Jack Het grote verschil is nu en in de toekomst. Misschien dat het in de toekomst sneller kan dat software ontwikkelen, bij voorkeur zonder ict-ers, maar op dit moment kost sofware maken tijd. Dus niet te langzaam maar het kost tijd. En ik schreef wat @mauwerd ook al aan haalde, slecht teken al het steeds anders moet. Agile, wat het ook mag zijn, lijkt me geen vrijbrief voor zwalken. Realisme is dat software maken tijd kost.
Over Java en Cobol, het is te hopen voor een organisatie/bedrijf dat de bedrijfslogica niet alleen in Java is vastgelegd. Overigens niet ondenkbaar met het agile motto: als het maar werkt. Cobol heeft de naam goed leesbaar te zijn dus denk we moeten vrezen voor de legacy van morgen.
@Beiden,
Dank voor jullie genuanceerde reacties; ik kan mij er heel goed in vinden.
Eerlijk gezegd speelde ik in mijn eerste reactie wel een beetje advocaat van de duivel; uit voorgaande reacties op deze site blijkt dat mijn standpunt ten aanzien van agile applicatie-ontwikkeling eerder kritisch/sceptisch/afwijzend is. Zo heb ik begin dit jaar (in reactie op “De rol van de tester verandert”) met instemming Ewout Dekkinga geciteerd:
“Want afstemming in de keten is nogal moeilijk te verkrijgen als SCRUM teams vooral naar functionele oplevering sprinten en aspecten als overdraagbaarheid, efficiëntie en onderhoudbaarheid blijven negeren. “
Hoewel we van dat denken in ketens nog wel af moeten (maar dit nu even terzijde).
En wordt de onzin die ten aanzien van agility gedebiteerd wordt mij te gortig, dan wordt agile in haar zuivere vorm gewoon “zielloos opportunisme” (waar jullie dan terecht van een zwalkende business spreken).
Kortom, het nog maar de vraag of wij zo heel veel van standpunt verschillen.
Want eigenlijk moeten wij alle drie niets hebben van de hyperige en hijgerige overwaardering van ‘snelheid, wendbaarheid en flexibiliteit’ zoals naar voren komt in een opiniestuk als “Agile is klaar voor de volgende stap”; met interesse heb ik jullie discussie onder dit stuk dan ook gevolgd.
Als de auteur van dat opiniestuk spreekt van “het toppunt van agile”, een trend waarin Nederland nu al koploper zou zijn, dan is dat een rampscenario dat we maar beter kunnen afwenden; de huidige softwarecrisis is al erg genoeg.
De clou is (mijns inziens): inzien dat ten aanzien van bedrijfstechnologie het (Angelsaksische!) denken in modellen (MDA), regels (BRM) en processen (BPM) een doodlopende weg is. Ik houd het dan ook op kennisgedreven architectuur (knowledge-driven architecture (KDA)) als implementatie van SOA, beslissingstabellen en doelgerichte redeneermechanismen. En uiteraard: KDA = 5GL.
En wat 5GL niet is (en ook nooit is geweest):
http://businessrules.editme.com/files/Archief2007/5GL-Springlevend-Leo-Hermans.pdf
(met alle respect overigens voor de in 2009 overleden auteur).