Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Vijf jaar Agile: hosanna of drama? (1)

28 oktober 2014 - 13:135 minuten leestijdOpinieSoftware & Development
Leo van der Aalst
Leo van der Aalst

Agile is het antwoord op alles. Zo wordt alom gesproken. Hoe dan ook zou de traditionele softwareontwikkelaanpak niet meer geschikt zijn voor deze tijd. Is dat terecht? Ik heb onderzoek gedaan naar driehonderd agile projecten in de afgelopen vijf jaar. Succesvolle projecten, en helaas ook faliekante mislukkingen. De belangrijkste misvattingen en valkuilen komen aan de orde in dit verhaal. Uiteraard met het doel deze de wereld uit te helpen. In deel 2 van mijn verhaal zet ik de voordelen en succesfactoren op een rij. Drama kan worden voorkomen als we onderstaande misvattingen en valkuilen serieus nemen.

Helaas, in de praktijk blijkt Agile niet het antwoord op alles  te zijn. Vooral in hiërarchische omgevingen met vastomschreven procedures en processen. Of waar certificering een belangrijke rol speelt zoals in de luchtvaart- of beveiligingsindustrie. Dan is Agile minder geschikt dan een traditionele aanpak. In bijna de helft van de Agile-projecten in deze strak gestuurde organisaties is men niet tevreden over het resultaat.

In Agile-omgevingen ontbreken processen, wordt er niet gepland en is discipline ver te zoeken. Dit wordt vaak geroepen. Maar het  zijn allemaal misverstanden. In een Agile-aanpak bestaan wel degelijk processen, net als in een traditionele aanpak. Dit zijn weliswaar lichtgewicht processen. Het Agile-team past processen naar eigen behoefte aan. Ook is er wel degelijk sprake van discipline. Ga maar na, hoe kun je in een iteratie van bijvoorbeeld twee weken werkende software opleveren zonder planning en discipline? Inderdaad. Niet dus. Release- en iteratieplanningen zijn een vast onderdeel van Agile. Daarbij worden scrum- of kanban-borden, burndown charts en daily scrum gebruikt om werkzaamheden transparant te maken en af te stemmen. Dit alles ondersteunt de planning om te komen tot het gewenste resultaat. Zo vraagt deze aanpak juist om een ijzeren discipline van Agile-teamleden.

Een hardnekkig vijfde misverstand is dat er in Agile niet wordt gedocumenteerd. Dit misverstand is waarschijnlijk ontstaan omdat het Agile-team alleen documenteert wat nodig is om als Agile-team het werk te kunnen doen of waar stakeholders een belang bij hebben. In het ene geval is dat minimaal, omdat de teamleden precies weten wat ze moeten doen en wat ze van elkaar kunnen verwachten. In het andere geval kan dat meer zijn. Bijvoorbeeld als er eisen zijn gesteld aan onderhoudbaarheid of overdraagbaarheid van producten. Of omdat er sprake is van wet- en regelgeving-, of certificeringseisen die meer documentatie vragen dan voor het team nodig was om het product te maken. Er wordt dus wel degelijk gedocumenteerd, maar niet meer dan nodig.

Valkuilen

Je zult maar als softwareontwikkelaar al jaren met een bewezen goedwerkende aanpak werken. En dan beslist het management op een dag dat Agile nu de aanpak wordt. En dat ‘by the way’ die goedwerkende aanpak de prullenbak in kan. Het overboord gooien van bestaande softwareontwikkelprocessen is een vaak voorkomende valkuil. Want wat staat er allemaal in het Agile-manifest of in de Scrum-aanpak over hoe je software moet ontwikkelen? Over hoe je requirements, functionele specificaties als user stories of use cases, technische specificaties, datamodellering, systeem- en software architectuur, software, tests, moet opstellen en maken? Niets toch? Dus dan lijkt het verstandig het kind niet met het badwater weg te gooien. Blijf daarom goedwerkende onderdelen van de software-ontwikkel- en testaanpak gebruiken,  of aan te passen aan de Agile-situatie.

Vrijwel alle methoden zijn goed doordacht en werken prima als ze worden gebruikt, zoals ze zijn bedoeld. Denk bijvoorbeeld aan SDM, JSD, RUP, of PRINCE2. Bij de implementatie van een Agile-aanpak zoals Scrum is veelal een gedeeltelijke adoptie te zien. Even zo vaak blijkt dat een bewuste als onbewuste keuze te zijn. Zelfs een bewuste keuze van ‘cherry picking’ leidt in de meeste gevallen tot minder succes dan een volledige adoptie. Het bekende gezegde ‘hinken op twee gedachten’ doet hier opgeld. Dat is een notoire valkuil.

Programmeren tot de laatste minuut. Wie komt dat niet bekend voor? Dit is een diepe valkuil, want dit betekent per definitie dat er geen werkende software aan het eind van een iteratie wordt opgeleverd. In iets afwijkende bewoordingen van elkaar, zeggen alle Agile-aanpakken dat een product pas gereed (‘done’) is als alle stakeholders akkoord gaan met het product. Het korte termijn denken betekent meer risico op het gebied van test- en technical debt. Door wel snel ‘iets’ – omdat bijvoorbeeld de ‘product owner’ dat wil – op een ‘quick and dirty’ wijze aan het eind van de iteratie op te leveren, kunnen code-, architectuur- en testgerelateerde onvolkomenheden in volgende iteraties aan het licht komen. Dat leidt tot grote, kostbare of tijdrovende herstelactiviteiten.

En ineens zit je niet meer in een traditioneel ontwikkelproject, maar in een Scrum-team. Nu maar hopen dat de andere teamleden hiermee kunnen omgaan, denk je. Dit is een heel typische valkuil, alles verandert, behalve …  ik. Een menselijke eigenschap is dat mensen al gauw van zichzelf vinden dat ze iets wel kunnen, terwijl ze denken dat andere mensen daar meer moeite mee hebben. In Scrum is het van belang dat je zelf ook mee verandert. Dat gaat niet vanzelf. Daar moet je echt iets aan doen.

Leo van der Aalst, senior testing consultant bij Sogeti Sogeti en lector software quality & testing aan de Fontys Hogeschool

Meer over

AgileScrumSoftwarebeheer

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Design Sprints: 4 dagen van idee naar prototype

    Hoe zet je in vier dagen tijd een gevalideerd prototype neer met Design Sprints?

    Computable.nl

    Resultaatgericht Samenwerken (RGS).

    RGS is een gestructureerde methode die vastgoedprofessionals direct ondersteunt bij kwaliteitsverbetering, kostenefficiëntie en verduurzaming.

    Computable.nl

    De principes van cloud-native techniek

    Cloud-native technologieën voegen flexibiliteit, schaalbaarheid en beveiliging toe en verlagen de operationele kosten voor de IT-omgeving. Hoe dragen Kubernetes, KEDA en AKS hieraan bij?

    Meer lezen

    Computable.nl
    ActueelCarrière

    The Future Group start Agile-maatschap

    5 reacties op “Vijf jaar Agile: hosanna of drama? (1)”

    1. atillav schreef:
      29 oktober 2014 om 11:56

      Stoppen met een one-size fits all oplossingen te bedenken! Ga dan op zoek naar “de Heilige Graal” of “Eureka”. Waar ik overigens wel een trend zie is dat we terug moeten naar “het boerenverstand”. Maar wat dat dan is, is nog niet zo heel eenvoudig te beschrijven of uit te leggen.

      Ik zal een poging wagen: laten we balans brengen in alle relevante aspecten van elk belangrijk organisatievraagstuk dat op de directietafel komt. Voor de puristen, relevant hier slaat op aspecten die met het vraagstuk te maken hebben (dus geen Poolse landdagen). En belangrijk heeft te maken met de impact die het vraagstuk heeft op alle belanghebbenden.

      Die balans aanbrengen leidt tot een overall oplossing(ruimte) (dan alleen technologie) en de daarbij behorende aanpak (er leiden meer wegen naar Rome). Hieruit kan je dan ook bepalen of je een “Agile” aanpak of een traditionele waterval methode moet gebruiken.

      Praktisch gezien: zet de belanghebbenden in een “hok” en met een beetje begeleiding ben je er binnen 2 uurtjes uit. Dat betaalt zich dubbel en dwars later terug.

      Login om te reageren
    2. kj schreef:
      29 oktober 2014 om 13:32

      @Atillav
      Die approach heet “involvement” en is heel lastig te verkopen.

      Login om te reageren
    3. Pascal schreef:
      29 oktober 2014 om 15:04

      @KJ ik noem het gewoon vakinhoudelijke kennis, en die is dan weer wegens gebrek heel lastig in te kopen.

      Login om te reageren
    4. Felix The Cat schreef:
      29 oktober 2014 om 18:52

      laat deel II maar zitten. Je hebt ons al overtuigd 😉

      Login om te reageren
    5. Frits Greuter schreef:
      30 oktober 2014 om 19:16

      ‘Quick and dirty’ bestaat niet. Iedereen noemt fixes voor een deadline zo maar maar komen er dan na klantklachten toch weer werkzaamheden achteraan. Het is alleen een smoes om niet na te denken over betere oplossingen. Eerst nadenken en dan doen. Ik begrijp werkelijk niet wat het nut is van het halen van een deadline als je weet dat het toch weer terug gaat komen.

      Login om te reageren

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs