In de afgelopen jaren zijn we enthousiast aan de gang gegaan met Agile. Nu vijf jaar verder heb ik driehonderd agile projecten onder de loep genomen. Projecten die tot grote successen hebben geleid, maar ook gigantisch hebben gefaald. Op basis daarvan heb ik in deel 1 de misvattingen en valkuilen op een rij gezet. Deze keer is het tijd voor de voordelen en succesfactoren. Een ‘hosanna’ Agile-project is binnen handbereik.
De actuele status van een Scrum-project is vaak in één oogopslag te zien, dankzij ‘burndown charts’, Scrum-borden met user stories, taken en kolommen. Deze laten zien of een user story bijvoorbeeld ‘in progress’ of al ‘done’ is. In het algemeen kun je zeggen dat Agile projecten transparanter zijn, En door de korte iteraties, de nabijheid van de stakeholders – via de ‘product owner’ – en de nauwe samenwerking in het scrum-team kunnen prioriteiten makkelijker worden bijgestuurd. Daarmee is de organisatie in staat sneller te reageren op veranderingen.
De kwaliteit van producten is beter. Iedere it-professional kent ongetwijfeld het figuur met de schommel. Dat laat zien hoe de uiteindelijk afwijkende wens van de klant gerealiseerd wordt. Onderzoeken laten zien dat in traditionele omgevingen van de oorspronkelijk honderd gedefinieerde requirements er vijftig worden gerealiseerd. De klant gebruikt uiteindelijk maar 25 functies. Dat is nogal wat ’waste’, volgens ‘lean’-begrippen. De klant maakt nu deel uit van het Scrum-project. En zit dus dicht op het ontwikkelteam. De gebruiker of opdrachtgever ziet snel genoeg wanneer sprake is van afwijkingen. Het herstel is zo gepiept. Dat geldt ook voor nieuwe inzichten die gaandeweg worden ontwikkeld. Het verkorten van de ‘time-to-market’ in een Agile-project met 10 tot 60 procent is ook een groot voordeel van Agile. Kortom, de juiste producten worden ook nog eens sneller opgeleverd.
Vaak leven ‘uitgebluste’ it’ers helemaal op als ze in een Agile-project gaan werken. Of dat nu komt door het verlaten van een jarenlange ‘sleur’, of door het werken in een team aan een gezamenlijk doelstelling, of doordat het team meer verantwoordelijkheid heeft. Feit is, dat in Agile-projecten medewerkers vaak gemotiveerder zijn. Ze zijn ook gewoon ‘blijer’. Een niet te onderschatten emotie voor het behalen van goede resultaten.
Succesfactoren
Ja, managers, nu komt het er op aan. In het verleden was het zo dat teamleden beslissingen van de manager vertrouwden en opvolgden. Bij een Agile-aanpak moet de manager beslissingen van het Agile-team accepteren. Het is de manager die de mensen in het team moet vertrouwen en aan hen zoveel mogelijk vrijheden en bevoegdheden moet geven. Om écht succesvol te kunnen zijn met de invoering van een Agile-aanpak is bedrijfsbrede commitment nodig. De invoering vereist meestal een cultuuromslag of minimaal een cultuuraanpassing. Daardoor is het bijvoorbeeld heel gebruikelijk dat mensen het bedrijf verlaten als ze niet in staat zijn te werken in een Agile-omgeving.
Ook voor de teamleden komt het er nu op aan. Succes wordt alleen bereikt als het team daadwerkelijk als team acteert. Dus niet werken in silo’s van ontwerpers, programmeurs, testers en gebruikers. Maar allemaal samen. Verder moeten alle ontwikkelprocessen worden geïntegreerd. Dus bijvoorbeeld geen losstaand ontwikkel- en testproces, maar volledig geïntegreerd gelijktijdig ontwerpen, programmeren en testen. Deze integratie geldt ook voor alle teamleden en activiteiten. Iemand in een programmeursrol moet bereid zijn andere activiteiten op te pakken, bijvoorbeeld testactviteiten. Iemand in de testrol moet ook bereid zijn bijvoorbeeld testautomatiseringsactiviteiten op te pakken of de opdrachtgever te helpen bij het opstellen van de user stories. Dit alles is uiteraard afhankelijk van de kennis en kunde van de desbetreffende persoon. In het algemeen kun je zeggen dat ieder teamlid één discipline uitstekend beheerst en verder bereid is een tweede of derde bij te leren. Teamleden in een Agile-team zijn multidisciplinair.
Het blijkt wel dat de invoering van een Agile-aanpak nogal wat voeten in de aarde heeft. Veel organisaties worstelen daar nog altijd mee. Om maar niet te zwijgen van de bedrijven die maar wat aan modderen. Weerstand tegen de verandering is nog altijd aan de orde. Zeker bij veel managers. Zorg dan ook voor een goede begeleiding bij de invoering van een Agile-aanpak. Bijvoorbeeld in de persoon van een veranderingsmanager of Scrum-coach. Dat is een bepalende succesfactor.
De invoering van een Agile-aanpak is een leertraject en gaat gepaard met vallen en opstaan. De ene keer is de invoering sneller succesvol dan de andere keer. Het is belangrijk om telkens te leren van de gemaakte fouten. En die in een volgende iteratie weer te verbeteren. Dus niet te snel opgeven. Wees ook niet bang fouten te maken. Want hier geldt, ‘fail to succeed’!
Thomas Edison heeft ooit gezegd, ‘I haven’t failed. I’ve just found 10.000 ways that won’t work.’
Met alle misvattingen, valkuilen, voordelen en sucessen op een rij draagt dat weer een beetje bij aan de kans op een hosanna-project. Of nog beter, start direct een hosanna Agile-project. Dan is er geen poging 10.001 nodig!
Leo van der Aalst, senior testing consultant bij Sogeti Sogeti en lector software quality & testing aan de Fontys Hogeschool
Zoals ik vroeger al zei: “Efficiënt en effectief zit in het aantal schoten dat je nodig hebt en denk nog even na hierover als je zelf de 10.000 patronen moet dragen.” Agile is dan ook verre van doelmatig zoals de wet van Wirth al aantoonde, kijkend naar het totale middelenbeslag is de hele methodiek op alle fronten een mislukking. Deze ‘snedige’ reactie komt voort uit het feit dat agile lange tijd geen rekening hield met beheer en idee van DevOps mist wat essentiële aspecten doordat het uitgaat van het ‘crash & burn’ principe dat zo mooi verwoord wordt door de auteur maar te vaak leidt tot: “Operatie geslaagd maar patiënt overleden” want achteraf pleisters gaan plakken terwijl de patiënt leidt aan een slagaderlijke bloeding zorgt niet voor de gewenste resultaten.
Als lector software quality & testing aan de Fontys Hogeschool vraag ik me af of auteur op de hoogte is van de discussie die momenteel gaande is over Heartbleed, Shell Shock en nog wat van die aansprekende namen in ‘bug tracking’ land. Vanuit die discussies komt namelijk een heel aardige tegenhanger op de quote van Thomas Edison: “Today’s problem for system administrators is tomorrow’s problem for home users” als straks het licht uitgaat doordat gebruikers steeds vaker de alfa- en betatester (A/B testing) zijn geworden. Hele agile manifest is tenslotte niet meer dan de belofte van wat kleuters die geen afscheid hebben willen nemen van de zandbak.
@Ewout
De problemen die je aanbrengt met Heartbleed en Shell shock zijn niet helemaal eerlijke voorbeelden. Heartbleed is bijvoorbeeld een bug die is geintroduceerd in een open source applicatie. De ontwikkelaars maken fouten, maar kan je die mensen – die gewoon in hun vrije tijd de applicatie ontwikkelen en onderhouden – het aanrekenen dat ze niet voldoende tijd en moeite steken in het werk? Wat van de bedrijven (Google, IBM .. .nou noem ze maar op) die dit werk onder het mompelen van “dank je wel” oppakken en vervolgens meenemen in hun werk waar ze dik en dik geld mee verdienen?
Hadden deze bedrijven niet een klein deel van die winst kunnen steken in het testen van de code en de bugs oplossen (en dan natuurlijk zoals het hoort bij open source weer terug laten vloeien in de development repository van de code)?
Het probleem hier is niet dat er geen aandacht aan wordt gegeven, het probleem is dat die mensen er hun beroep niet van kunnen maken; maar dat aan de andere kant van de vergelijking er wel bedrijven zijn die er dik geld mee verdienen en zich geen $%^& aantrekken van de kwaliteit van de code onder het motto “het is gratis, dus je mag er ook niet over klagen”.
Het artikel, en nog meer de reactie van Ewout Dekkinga, zijn een aaneenschakeling van begripsverwarring, misplaatste metaforen en niet-onderbouwde beweringen.
Tot 5 jaar geleden werkte ‘Agile’ (evenals Scrum, Lean, TDD, …) prima. Maar toen de managers dat zagen begonnen die zich ermee te bemoeien. Omdat hun taken nogal op de achtergrond raakten, hebben ze Agile geadopteerd (of liever geperverteerd) tot de zoveelste “in name only” methodologie. In plaats van ‘hosanna’ of ‘drama’ zou ‘requiem’ meer op zijn plaats zijn.
Nieuwe methodes ontstaan bij de gratie van mensen die hun nek uitsteken en de gangbare werkwijze aan de kaak stellen en daar (betere?) alternatieven voor ontwikkelen. Als je weet dat 80% van je bedrijfsactiviteiten herhaalbaar zijn, ben je gek als je geen standaardisatie toepast. Maar dat wil niet zeggen dat standaarden niet verbeterd kunnen worden. Dat laatste kun je prima agile doen. Maar die 20% maatwerk in minder of meer uitgebreide trajecten, die moet je traditioneel aanpakken.
Dus, denk ik dat iedereen hier denk ik een beetje gelijk heeft.
Agile levert sneller resultaat, maar dat is niet perse het goede. Je moet dus sneller herstellen. Een goed werkend eindresultaat zal in veel gevallen niet veel eerder opgeleverd worden dan via een niet-agile aanpak. Met de oplevering van allemaal stukjes werkende software zal je toch nog steeds het beoogde eind (= totaal-) resultaat in de smiezen moeten hebben, anders gaat het alsnog fout.
Dat er managers zijn die de boel eerder dwarszitten dan dat ze insteken op de gewenste zelfwerk- en redzaamheid geloof ik ook. Er valt immers nog maar weinig te managen als alles ineens in een keer goed gaat. Geen zorgen, vooralsnog is dat ook bij agile niet het geval. Natuurlijk zijn er juichverhalen, maar die zijn er ook bij watervalprojecten.
Sommige ontwikkeltrajecten moet je niet eens agile willen doen. En voor alles geldt dat je eerst moet weten welke activiteiten of handelingen je nu precies met ICT wil ondersteunen, zodat je helder kunt krijgen welke functionaliteit tegen welke voorwaarden door die ICT geleverd moet worden.
Los daarvan ben ik benieuwd wat de volgende succesmethodiek zal worden. Hopelijk een die ervoor zorgt dat mensen echt naar elkaar luisteren, het zeggen als iets niet goed hebben verstaan en het durven toegeven als ze een keer iets niet goed hebben begrepen. Scoor je echt beter mee.
@Cpt: Het is off-topic, maar de relatie met Heartbleed en Shellshock is niet alleen niet eerlijk, maar ronduit misleidend. Dit zijn bugs die snel zijn opgepakt en waarvoor zeer snel een oplossing is gemaakt.
Ik ken genoeg voorbeelden van software waarvoor ik betaal (Google appengine, Microsoft Windows) en waar fouten in zitten die pas na jaren of nooit worden opgelost.
Maar het verband tussen Open Source en Agile ontgaat mij nog meer dan Agile – Scrum of Agile – Lean. Of het moet zijn dat software ontwikkelaars er blij van worden en dat managers er moe (alweer iets nieuws leren en een boek lezen) van worden.
Agile staat of valt met de kwaliteit van de mensen die het gebruiken, net als iedere andere methode (“de methode doet het niet”). Bij ondeskundig gebruik kan Agile verworden tot het snel opleveren van knutsels. Bij ondeskundig gebruik leiden SDM en RUP tot analysis paralysis en documentatiebezigheidstherapie. Een gulden middenweg vinden is de uitdaging.
Bij Agile methoden wordt inderdaad efficiëntie deels opgeofferd. De vraag is echter of je software überhaupt efficiënt kunt realiseren. Er zijn namelijk veel variabele factoren in het gemiddelde ontwikkeltraject. Agile probeert door iteraties alle betrokken te laten leren, en op basis van het geleerde kun je vervolgens snel bijsturen. Ewout Dekkinga’s metafoor van de 10.000 kogels gaat dan ook mis: zonder richten 10.000 kogels afschieten in de hoop een doel te raken is niet Agile. Agile is om a) 1 kogel af te schieten, b) te bedenken waarom je niet raak hebt geschoten, c) daarvoor te compenseren, en dan weer terug naar a). Waarschijnlijk raak je binnen 20 kogels het doel. Overigens, als je weet dat richten belangrijk is en hoe dat moet, dan is het dom om Agile te gaan werken. In dat geval volg je de instructie voor richten, en schiet je (hopelijk) in 1 keer raak. De referentie aan de Heartbleed bug begrijp ik niet. Ook in Agle methoden is het de bedoeling om foutloze software op te leveren. Dit heeft dus niks met agile te maken, maar met de kwaliteit van ontwerpen en testen. Beide zijn in zowel agile als niet-agile projecten gewoon moeilijk.
Agile is niet alleen de ontwikkeling van software, ook de rest van de organisatie moet mee. Dus ook financien, sales, etc. En dat is best een grote uitdaging.
Agile werken in een organisatie die met jaarbudgetten werkt is behalve ‘uitdagend’, ook eigenlijk gedoemd te mislukken.
En een hele organisatie op deze manier agile te maken is iets dat de gemiddelde reorganisatie waarschijnlijk eenvoudig doet lijken.
@Nico
Fantastisch dat je ook zo ‘snedig’ reageert, als vurige pleitbezorger lijk je echter van methodiek het doel te maken in plaats van het als één van de vele methoden om een doel te bereiken te zien. Nu was mijn reactie vooral bedoeld om ‘lector’ methodieken te verleiden tot een response maar leuk dat ook jij je aangesproken voelt. Je zandbak retoriek aangaande managers die alles geperverteerd hebben lijkt me echter niet te kloppen als ik kijk naar addendum op manifesto met de Declaration of Interdependence: http://pmdoi.org/
Hoewel link met open source niet gezien wordt is het grappig om te constateren dat dezelfde problematiek met agile ontwikkel projecten speelt omdat het zoals Steve Ballmer over GPL licenties zei: “a cancer is that attaches itself in an intellectual property sense to everything it touches” En dit geldt met name voor wijze waarop de agile methodiek verkocht wordt, er wordt een community geleverd die ‘kralen gaat rijgen’ als niet rekening gehouden wordt met het aspect van IP. Opmerkelijk vaak blijkt er dan ook niet van leverancier gewisseld te kunnen worden na een iteratie en worden dit soort projecten stilletjes een afdeling. Betreffende OpenSSL bleek dat software meer is dan de code en dat het governance model in grote mate de betrouwbaarheid en onderhoudbaarheid bepaald. En vaak wijzigt de governance van een project als het zakelijke gebruik van oplossing toeneemt, zeg maar het toepassen van addendum wat hier dus nagelaten was.
@Joost
Mijn metafoor was een antwoord op schrijven van auteur die quote van Thomas Edison gebruikte aangaande het vinden van 10.000 manieren die niet werken. Betreffende het richten is het natuurlijk wel aardig dat je niet alleen een doel hebt, je opmerking aangaande keuze van ontwikkel methodiek onderschrijf ik, maar vooral is het belangrijk dat je weet waar de afgeschoten kogel terecht komt. De impact van heartbleed bleek veel groter dan de ontwikkelaar bij aanvang bedacht had.
Agile is niet meer of minder dan een werkwijze die uitgaat van het principe van voortschrijdend inzicht. Enerzijds kan dit goed uitpakken, namelijk bij situaties die erg onvoorspelbaar zijn of zeer veranderlijk. Anderzijds kan het een inefficiënte methode zijn, waarbij veel wordt gewerkt met trial and error, en dat opent perspectief voor mensen met weinig verstand van de materie, en voor ongeduldige mensen die direct resultaat willen zien. Het positieve aan agile is dat je niet vastgeketend zit aan een geheel uitgewerkt (theoretisch) plan, tegelijk is het negatieve dat je heen en weer slingert in de oplossing en de code moeilijker te onderhouden is.
Agile sluit meer aan op de natuur van de mens, terwijl waterval meer vanuit de logica en ordening plaatsvindt. Agile is meer intuitief, terwijl waterval bijna wetenschappelijk genoemd kan worden. Agile moet het vooral hebben van deskundigheid en ervaring, waterval van een goede analyse en goed georganiseerde structuur. Voor allebei is wat te zeggen. De ene keer zal agile beter uitpakken, de andere keer de waterval. Zaak is om goed te kunnen bepalen wanneer welke aanpak het beste resultaat (kwaliteit, geld, doorlooptijd) oplevert.
Daarnaast hangt het af van de professionele volwassenheid van het team of de teamleden. Hoewel agile meer aansluit op de menselijke vaardigheden, is het beter om een meer onervaren team meer op een watervalachtige manier te laten werken. Pas bij voldoende ervaring kunnen de meer intuitieve manieren van werken tot hun recht komen en levert agile werken ook meer resultaat op.
Net zo goed als dat je een onervaren voetbalteam niet gelijk en masse aanvallend laat spelen, maar eerst goed de defensie organiseert (minder verliezen), en pas later meer risico neemt met aanvallender voetbal (meer winnen). En ook hier houdt je rekening met de omstandigheden (de tegenstander, het weer etc.).
Kom hier steeds het misverstand tegen dat Agile een methode zou zijn, Agile is een filosofie zoals beschreven in het warrige manifesto. Het beste is nog de letterlijke verstaling van agile: lenig en wendbaar. En dat is passend bij het software ontwikkeling want hierbij is voortschrijdend inzicht een gegeven. Zolang de computer al bestaat. Scrum, Lean, dat zijn proces begeleidings methodes. Geen software ontwikkeling methodes, vandaar die inhoudelijke verwarring die deze methodes brengen. Hoewel in het manifesto staat dat de mens belangrijker dan het proces is, lijkt wel het tegendeel waar als het om Scrum, Lean etc gaat.
Ook in de artikel is het welhaast een geloof wat gepredikt wordt en naar mijn mening ook nog los van de realiteit. Het team dat beslist. Laat me niet lachen, nu ben ik een salon communist, maar ik geloof niet in deze vorm van arbeiderszelfbestuur en in de praktijk werkt het zeker niet zo. Zoveel mensen, zoveel meningen en uiteindelijk moeten er beslissingen genomen worden. En wie doet dat? De product owner?
Het is denk ik goed om te realiseren dat dit soort proces methodes juist vanuit management geinitieerd worden. Deze methodes gaan over controle en vat krijgen op iets ongrijpbaars als een ict project. Volgens een strakke lijn van sprints geleid vanuit de business die de doelen bepaalt bij monde van de productowner. En dat levert betere kwaliteit software op? Als het over kwaliteit gaat, dan praat je over hele andere doelen, die meer in de software zelf liggen, niet in de geleverde functionaliteit. Daarom ben ik ook wel benieuwd hoe de schrijver erbij komt dat de kwaliteit van Agile/Scrum projecten beter is.
Als ik de reacties lees dan is het nogal lastig om als organisatie Agile (wat dat ook mag zijn…) te werken. De schrijver suggereert nieuwe rollen. We hebben al de scrummaster, de productowner maar nu ook de verandermanager. En ik mis dan nog de continu verbetercoach en de dependency manager. Die heb ik dan weer gezien in de agile/scrum praktijk. En dan bekruipt me het gevoel dat ICT vooral heel veel praten is door heel veel mensen waarbij het niet om ICT kennis gaat. Dit lijkt mij meer het Poolse Landdag Model, wat in van de eerdere reacties ook al las. De ICT realiteit vrees ik maar ik ben geneigd om te zeggen, weg met dit soort rollen.
Is het dan allemaal slecht? Nou nee, het goede aan deze methodes is dat de vinger aan de pols gehouden door de verplichte bijeenkomsten. Maar goed management of leiding heeft dat natuurlijk helemaal niet nodig en weet wat er moet gebeuren.