Development

Software-ontwikkeling
Agile

Agile is slecht voor ontwikkelaars, zegt Agile-vader

Een van de opstellers van het Agile Manifesto treurt als hij ziet hoe organisaties de methodiek misbruiken

© CC BY-SA 2.0 - Flickr 2.0 gdstream
26 juni 2018

Een van de opstellers van het Agile Manifesto treurt als hij ziet hoe organisaties de methodiek misbruiken

Ron Jeffries raadt ontwikkelaars aan agile te boycotten. Het Agile Manifesto - waarvan hij mede-opsteller is - heeft het leven van ontwikkelaars slechter gemaakt in plaats van beter.

Organisaties misbruiken het 'agile'-label om ontwikkelaars aan te zetten om meer code sneller te kloppen dan redelijkerwijs mogelijk is, vat ZDNet de blog van Jeffries samen. Agile is big business geworden, concludeert Jeffries. "Er zijn honderden, zo niet duizenden zogenaamde 'agile'-coaches en -trainers en afgeleide frameworks en methodes die soms conflicteren met de grondgedachte. Zo zijn er agile leadership trainingen en aanbiedingen voor agile project management."

Organisaties varen doorgaans wel bij deze aanpak. Elke organisatie die probeert te vernieuwen, verbetert vaak ook wel. Maar ontwikkelaars zijn het kind van de rekening bij organisaties die het 'agile'-gedachtegoed verkeerd toepassen. Er is dan namelijk meer bemoeienis met de ontwikkelteams, er is minder tijd om het werk af te ronden en er is hoge druk om sneller met resultaten te komen. "Dat is slecht voor ontwikkelaars en uiteindelijk ook slecht voor de organisatie", zegt Jeffries. Hierdoor ontstaan meer fouten en gaat uiteindelijk het proces trager dan mogelijk was geweest. Bijkomend schadelijk gevolg is dat goede ontwikkelaars bij dergelijke organisaties vertrekken.

Scrum sucks

Jeffries hoort veel ontwikkelaars klagen over agile, of liever gezegd over de Scrum-werkwijze, want daarmee vullen veel organisaties de agile-methodiek in praktijk in. Vaak komt het er op neer dat de organisaties niet doen wat de opstellers van het Agile Manifesto of de Scrum-werkwijze hebben geadviseerd.

Hij steekt de getergde ontwikkelaars een hart onder de riem: zet een punt achter alle methoden die refereren aan 'agile'. Richt in plaats daarvan je aandacht en trainingsinspanningen op alle softwareontwikkelingsmethoden die vallen binnen de fundamentele principes van Agile Software Development-methodieken. Die somt Jeffries nog maar eens op:

  • Produceer werkende, geteste en geïntegreerde software, elke twee weken. Werk aan je vaardigheden zodat je elke dag een nieuwe volledig operationele versie kan opleveren; elke dag, of twee keer per dag of zelfs meerdere keren per dag.
  • Houd het ontwerp van de software 'schoon'. Naarmate de toepassing groeit, heeft het ontwerp de neiging onnodig complex te worden. Voorkom dit en keer de trend consciëntieus zodat je voortgang zo regelmatig en consistent mogelijk is.
  • Gebruik alleen huidige versie van software als basis voor alle conversaties met het productmanagement en leidinggevenden. Spreek met hen in termen van wat er klaar is en wat zij graag zouden willen dat je het eerst oppakt.

Elke dag deadline

Volgens Jeffries is het belangrijk dat elke dag de deadline is. Door elke dag functionele software te leveren, kan er ook elke dag worden geïmplementeerd met het best mogelijke resultaat. Door je te richten op de huidige versie van de software, en de conversatie te richten op wat er in de volgende stap moet worden opgepakt, voorkom je de oeverloze discussie over de oneindige lijst met wensen van het management. Het is niet altijd gemakkelijk om te schakelen van 'doe dit allemaal' naar 'doe als eerste dit', waarschuwt Jeffries, maar het is de beste manier om het leven aangenaam te houden.

Lees meer over
Lees meer over Development OP AG Intelligence
7
Reacties
Bop 11 oktober 2018 20:33

Typisch voor het gebruik van dit Engelse modewoord is dat mensen niet doorhebben dat ze een bijvoeglijk naamwoord gebruiken.
Vaak is het dus geen 'agile' maar 'agility', een zelfstandig naamwoord.

Titel zou dus moeten zijn: 'Agility is slecht voor ontwikkelaars', zegt Agility-vader.

RB 27 juni 2018 17:05

Exact! Het afwerken van je post-it is het doel geworden ipv het oplossen van het probleem waardoor het post-it is geplaatst. PS: zoals je uit de reacties kunt lezen zie je precies wat het probleem in agile teams is namelijk dat agile alles oplost en waterval alles slecht maakt. De ene methodiek sluit de andere niet uit in software engineering is geen enkele methodiek , taal etc toepasbaar op alles. Het inzetten en inrichten van agile is afhankelijk van het soort software dat je wilt bouwen en de ervaring van de teamleden het is gewoon niet per definitie de beste oplossing voor alles.

Ik ben van de oude stempel ik werk zowel agile waterval als prototyping maar sinds er alleen mensen van school komen die agile hebben geleerd is het ineens de oplossing voor alles, alles wat goed is is zgn agile alles wat slecht is waterval teams bestaan vaak voor meer dan 60% uit niet ontwikkelaars iedereen lult een eind weg en weet precies wat er moet gebeuren behalve de ontwikkelaars en wanneer je denkt te beginnen met iets te bouwen moet je babyzitter spelen voor de tester want die kan geen testplan maken omdat hij niet weet wat je bouwt en wanneer je klaar bent moet je weer babyzitter spelen om de tester uit te leggen wat hij moet testen en zo ben je weer 20% van je tijd kwijt terwijl de ontwikkelaar de schaarste resource is. Wat ik onwijs goed vind aan agile is de reflectie maar deze word vaak over geslagen of 80-90% gedaan op alles wat goed en positief is terwijl het er juist om gaat dat je achteraf fouten erkend en stappen neemt om niet weer de zelfde fouten te maken, zoals 20% van je tijd kwijtraken aan testers omdat stories bij uitvoering niet helder blijken of minder capabele collega's die snel taken afronden terwijl ze andere functionaliteiten slopen die jij moet corrigeren en worden geboekt als bugs terwijl het geen bugs zijn maar slordigheid is omdat iemand graag het binkie wil uithangen door veel post-itjes bij zijn naam te willen hebben en doof is voor het feit dat hij andere delen van de software beschadigt.

Dit is mijn ervaring op basis van de 8 agile projecten die ik heb gedaan er was maar 1 team bij die de aanpak juist implementeerde wat meer en betere software opleverde als gevolg. En dan zit er ook zo een coach gast in je nek te blèren waar je echt niks aan hebt, ik ben geen klein kind meer en heb ook geen Emile Ratelband nodig. Een team hoort elkaar te helpen maar mensen denken dat andermans werk doen hetzelfde is maar dit ondermijnd het team moraal en de efficiëntie.

Jeroen Meetsma 27 juni 2018 12:32

Een vaardig en volwassen team maakt zichzelf productief door het ontwikkelproces naar zijn hand te zetten. Door “waste” te mijden en praktische activiteiten te hanteren zoals kort en gericht aft e stemmen, en requirements te verfijnen op basis van feedback op een werkend product.
Agile methodieken zijn gebaseerd op de uiterlijke kenmerken van dergelijke teams. IT-managers maken een denkfout als ze veronderstellen dat het simpelweg kopiëren van best practices een middelmatig team laat excelleren.

Anko Tijman 27 juni 2018 10:30

Nee, de watervalaanpak met zijn fixed price, fixed date, fixed scope en "gooi het maar over de muur naar Beheer" aanpak was beter voor programmeurs! :-/(dit is sarcastisch bedoeld hoor!)

Michel 27 juni 2018 08:18

Verwarrend stuk. Eerst schrijven dat Agile/Scrum door verkeerd uitvoeren een negatieve uitwerking heeft voor veel ontwikkelaars maar vanaf de kop Scrum Sucks lees ik niks wat niet met scrum gerealiseerd zou kunnen worden.
De opsomming en de laatste alinea zijn eigenschappen van een snel en effectief scrum team.

Waar is nu de onderbouwing voor de kritiek?

Harold 26 juni 2018 17:42

En de oplossing is zo simpel. Software Cost Estimation op basis van data en beproefde modellen. Zorg dat er een realistische sprint backlog is in plaats van een wenselijke. Jammer dat het zo lang duurt voordat de industrie dit omarmt. Toch worden volgend jaar de eerste software Cost estimators gecertificeerd door de International Cost Estimation and Analysis Association 😃

ronald wouterson 26 juni 2018 12:35

Het artikel bevestigt het haast-je-rep-je idee naast het befaamde JBF-en en de dagelijkse dus fout introducerende updates. Kwaliteitsdenken en termijnvisie bestaan steeds minder. Gestructureerde technieken, sterk ontwerp en streven naar perfectie, zijn zo ver op de achtergrond gekomen dat vervanging van de huidige ICT teams door de veel belovende AI technieken van IBM en Google voor de hand ligt.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.