Als je alle succesverhalen en voordelen van scrum en agile hoort, zou je bijna denken dat agile de silver bullet is. Over de nadelen, gevaren en randvoorwaarden van agile werken hoor en lees je weinig.
Rini van Solingen en ik hebben daarom een artikel over de gevaren en randvoorwaarden van agile werken gepubliceerd in AG Connect. Hier lees je een samenvatting van het artikel met de titel ‘Verborgen gevaren van agile – De eerste projecten laten vaak tegenvallende resultaten zien’.
In dezelfde serie in AG Connect is ook ons artikel De schone schijn van documentatie verschenen.
Rini van Solingen is keynote spreker, auteur, CTO bij Prowareness en deeltijdhoogleraar aan de TU Delft. Rini heeft de bestseller De Kracht van Scrum op zijn naam staan en de boeken Het agile werkvormen boek, Agile werken in 60 minuten, Scrum voor Managers en Agile.
Randvoorwaarden agile werken
Weet jij welke randvoorwaarden gelden om met succes agile te kunnen werken? En welke inspanningen nodig zijn om aan die randvoorwaarden te voldoen?
De meeste mensen en organisaties ontdekken dat pas als het te laat is. Wat dat betreft lijkt agile op gezond willen leven. Denk maar aan al die mensen die in januari een jaarabonnement in de sportschool nemen. Hoeveel van hen lukt het ook écht om fit te worden?
Rini en ik maken je graag deelgenoot van de 8 verborgen gevaren van agile.
1. Agile werken is veel moeilijker dan het lijkt
De regels en principes van agile zijn eenvoudig te begrijpen. De moeilijkheid openbaart zich pas tijdens het toepassen ervan. Voordat je tot een grootschalige transitie besluit is rondkijken bij organisaties die veel verder met agile zijn een goed idee.
2. De weg naar agile is onduidelijk
Agile onder de knie krijgen gaat met vallen en opstaan. Het is een leerproces, een ontdekkingsreis. Bijsturing is nodig wanneer de eerste resultaten tegenvallen. Door het gebrek aan ervaring is vaak niet duidelijk welke aanpassingen vereist zijn. Veel teams en organisaties vallen op dat moment terug op de vertrouwde watervaltechnieken.
3. De eisen aan een product owner zijn onrealistisch
Agile stelt zeer hoge eisen aan de product owner en legt veel vertrouwen, verantwoordelijkheid en mandaat bij hem of haar neer. In de praktijk is het vrijwel onmogelijk deze rol perfect in te vullen. Creatieve oplossingen zijn daarom nodig om agile projecten te laten slagen.
4. Vakmanschap kan tegenwerken
Agile werken vraagt niet alleen extra competenties en samenwerkingskwaliteiten van medewerkers, maar ook een fundamenteel andere kijk op hun vak. De basisprincipes en werkwijzen die architecten, analisten, ontwerpers, testers en ontwikkelaars tot dusver hanteerden, zullen ze voor een belangrijk deel los moeten laten.
5. Uitstelgedrag ligt op de loer
Door de focus op het snel opleveren van functionaliteit is het risico op overmatig korte termijn handelen inherent aan agile. Lange termijn effecten op kwaliteit, wendbaarheid en productiviteit worden dan genegeerd. Dit manifesteert zich pas als het te laat is. De schade is dan alleen met een bovenmatige inspanning te herstellen.
6. De impact blijkt veel groter dan gewenst
Voor zowel medewerkers als organisaties als geheel is de verandering naar agile veel groter dan het op het eerste gezicht lijkt. Agile heeft impact op zowel het werkproces als de inhoud van het werk. Agile vergt in de techniek uiteindelijk een ander voortbrengingsproces (continuous delivery) en een ander systeemlandschap (architectuur voor agility). Daarnaast heeft agile meestal een sneeuwbaleffect naar HRM, portfolio management, budgettering, structuren, contracten, systemen etc.
7. De randvoorwaarden zijn een brug te ver
Agile gaat uit van een ideale wereld, maar die bestaat helaas niet. Mensen en organisaties moeten zich aanpassen aan agile om tot de potentiële voordelen te komen. Bijvoorbeeld het werken met vaste stabiele teams waar het werk naartoe stroomt, in plaats van het toewijzen van medewerkers aan projecten.
8. Van schijnbare zekerheid naar heldere onzekerheid
Bij de start van het project is niet bekend hoe de te ontwikkelen software eruit gaat zien. Dat wordt pas gaandeweg het project bepaald. Veel opdrachtgevers ervaren dat als een groot risico. Organisaties die niet met deze onzekerheid om kunnen gaan en niet bereid zijn hun sturing daarop aan te passen, zullen agile niet goed van de grond krijgen.
Download hier het volledige artikel in pdf.
Nicole de Swart
De gevaren zijn in min of meer grote mate aanwezig. De eisen die gesteld worden aan de product owner zijn zowel de hoeksteen als de achilleshiel van Agile. Daarnaast zijn er de eisen aan de business (heldere onzekerheid).
Een groot probleem is ook de initiële product backlog, nog een achilleshiel. Agile vertrekt op het moment dat die bestaat, waar die echter vandaan komt is een grote vraag. Het probleem van goede requirementsanalyse blijft cruciaal en ook grotendeels onopgelost. Daar biedt Agile niet echt een antwoord op (de vele publicaties in dit verband zijn naar mijn mening een bewijs, als Agile dit goed zou afhandelen waren die niet nodig en zonder toegevoegde waarde).
De meeste problemen hebben niet veel met softwareontwikkeling en technologie te maken.
Na de eerste quick wins en de (tijdelijke) noodverbanden om dit te kunnen bereiken, verliest het gebruikersmanagement vaak de aandacht voor het project om andere prioriteiten aan te kunnen pakken of er komen nieuwe managers met afwijkende plannen. Een Agile aanpak leidt regelmatig tot brij van moeilijk te onderhouden systemen doordat er geen interesse of prioriteit meer is voor structurele verbeteringen.
Er kan beter worden gekozen voor Agile systemen die op zich zelf al de mogelijk bieden om snelle aanpassingen te kunnen doen: Dat zijn systemen die gebaseerd zijn op voor de gebruiker inzichtelijke business rules. Met Agile systemen werk je automatisch Agile en kan je alle Scrum-sores achter laten.
Beste Nicole (en mede reageerders)
Jullie geven allemaal eigenlijk aan dat een Agile werkwijze, zoals beschreven in het manifesto, niet zou kunnen werken en allerlei aanpassingen behoeft.
Dit begrijp ik niet, daar we dan niet voor Agile moeten kiezen. vanuit mijn expertise, uitgaand van het ketenprincipe, ken ik eigenlijk alleen maar situaties die niet werken op deze manier.
Ik zal het simpel houden, 2 Agile projecten die elkaar kruisen, maar dus duidelijk afhankelijkheden hebben, maar verschillende Productowners, en Agile team…hoe wil je dit oplossen. Elke duidelijk met hun eigen opdracht, Requirements of features…
Natuurlijk is dit oplosbaar, maar dit kun je dan niet meer Agile noemen, of hoe zien jullie dit??
Beste flutsch-it,
Naar mijn ervaring kan je geen goed huis bouwen “kamer-na-kamer”: Je zal eerst goed alle eisen op een rij moeten hebben om dan vanaf de fundering de zaak grondig op te bouwen. Veranderende eisen op detailniveau in een laat stadium, kunnen de zaak en het bijbehorende kostenplaatje fors verstoren. Hetzelfde is volgens mij van toepassing op software-ontwikkeling. Vandaar dat ik pleit voor een Agile systeemplatform in plaats van Agile software-ontwikkeling. Eigenlijk zou je volgens mij zo min mogelijk software moeten willen ontwikkelen, zeker als het anders kan!
Flutsch-it, dan heb ik mijn boodschap niet duidelijk overgebracht. Het gaat me erom om de verwachtingen te managen. De verschillende tussen een traditionele en een agile werkwijze zijn een stuk groter dan veel mensen (die net met agile beginnen) zich realiseren. Agile is bij uitstek geschikt in complexe en snel veranderende omgevingen, maar dan moet je wel bereid zijn om echt anders te gaan werken. Dat zou geen lichtvaardige keuze moeten zijn en je zou al helemaal niet voor agile moeten kiezen omdat het hip is en iedereen het tegenwoordig ‘doet’.