Dit zijn de redenen waarom Agile zo eenvoudig mislukt

In de afgelopen jaren heb ik de kans gehad om Agile te implementeren in vele soorten organisaties van verschillende omvang, in twee verschillende landen en zelfs in mijn eigen bedrijven. De successen en mislukkingen die ik in deze tijd heb gekend stelden me in staat om een lijst te samen te stellen van feiten en gedachten die me helpen bij de succesvolle implementatie van processen in de geest van de voorgestelde principes en waarden uit het Agile Manifest.

Agile zijn vóór Agile doen

Het doet er niet toe welke methodologie het team op dit moment gebruikt. Het is belangrijker om te begrijpen hoe het team dagelijks opereert, hoe teamleden samenwerken om problemen aan te pakken en hoe zij veranderingen en nieuwe ideeën accepteren en erkennen. In het algemeen geldt dat wanneer een team zich niet in hetzelfde tempo ontwikkelt als vergelijkbare marktspelers, het hoogstwaarschijnlijk niet geschikt is voor een Agile werkwijze, althans niet voordat er andere kleine wijzigingen worden doorgevoerd om de snelheid en een waardegedreven mentaliteit te verbeteren.

“Als je echt iets wilt begrijpen, probeer het dan te veranderen.” — Kurt Lewin

Agile is een mentaliteit en draait volledig om cultuur. Het is moeilijk en pijnlijk voor ons, mensen, om daar ook maar iets aan te veranderen. Het vraagt ons om uit onze comfortzone te stappen en de status quo ter discussie te stellen. Het vereist inspanning en betrokkenheid, niet alleen van het ontwikkelingsteam, maar ook van alle andere stakeholders. Als je interesse hebt om meer te lezen over de menselijke factoren die komen kijken bij gedragsverandering, dan raad ik je aan het boek Changing for Good te lezen, geschreven door dr. James Prochaska.

Voordat je Agile doet, is het noodzakelijk om Agile te zijn. Telkens als ik probeerde een nieuwe werkwijze in te voeren vóórdat ik de principes en waarden van Agile inzichtelijk had gemaakt voor de personen die er niet mee vertrouwd waren, had ik een moeizame weg te gaan. Ik heb het vele keren en in verschillende omgevingen geprobeerd, zoals publieke en private sectoren, kleine en grote teams, van start-ups tot grote ondernemingen. Kleine stapjes en kleine teams bleken altijd de beste route te zijn en het minst schadelijk voor de relatie met de opdrachtgever, inclusief de stakeholders en het ontwikkelingsteam.

Vaak hoorde ik leidinggevenden vertellen dat hun teams al Agile bezig waren, omdat ze staande besprekingen, Kanban-borden of sprints hadden ingevoerd, om maar een paar van de meest bekende termen rond te strooien. Als ik dan nader onderzoek deed, kwam ik erachter dat ze dat eigenlijk helemaal niet deden. Ze werkten niet aan het leveren van waarde, maar alleen aan het opleveren van geplande werkzaamheden, het team was niet gemotiveerd, continu leren maakte geen deel uit van hun proces, deadlines werden nog steeds gehandhaafd, er waren ‘sprints’ die maandenlang duurden en producteigenaren die opdoken om alleen maar meer taken op te leggen, levering was een pijnlijk proces, communicatie tussen team en stakeholders bestond niet, en dan waren er nog allerlei andere zaken die binnen de traditionele omgevingen plaatsvonden.

Waarom dachten deze teams dat ze Agile bezig waren? Agile is geen recept of een vast kader dat je kunt volgen door stappen te implementeren. Het staat open voor interpretaties, waardoor er snel misvattingen kunnen ontstaan die onder het mom van ‘trendy’ of ‘pseudo-motivatie’ worden overgenomen. Als je nooit de kans hebt gehad om het originele Agile Manifest te lezen, dan raad ik je met stipt aan om dit te doen. Het zijn slechts vier waarden en twaalf principes, een kwestie van vijf minuutjes lezen, die je leren dat het bij Agile allemaal draait om vertrouwen, samenwerking, leren, kwaliteit, communicatie, teamprestatie en niet in de laatste plaats: innovatie.

Als je bij je teams twee of meer van de volgende zaken kunt identificeren, ben je niet Agile bezig:

• Talloze initiatieven met spoedeisende deadlines in plaats van het toekennen van de hoogste prioriteit en er twee of drie kiezen om aan te pakken
• Managers die teambesluiten opzijzetten
• De beste talenten zijn verspreid over te veel projecten
• Te veel vergaderingen met teamleden, waardoor ze minder werken aan het project
• Buitensporig veel beoordelingslagen
• Bestaande of te ontwikkelen rapportagemechanismes/controles om te zorgen dat fouten niet herhaald worden
• Managers en leidinggevenden praten meer dan dat ze luisteren
• Niet-essentiële ideeën worden gepromoot, vooral de ideeën die het team eerder heeft overwogen en verworpen
• Gebrek aan communicatie veroorzaakt conflicten en dubbel werk
• Kwaliteitsborging maakt geen deel uit van het gehele proces
• Veranderingen worden niet goed geaccepteerd door het team
• Wijzigingsverzoeken lijken niet gerechtvaardigd of gekwalificeerd te zijn
• Levering of inzet is zeer moeizaam: er moet buiten kantooruren worden gewerkt, er is gebrek aan automatisering of er zijn te veel goedkeuringen vereist
• Feedback van klanten of eindgebruikers wordt genegeerd ten gunste van het oorspronkelijke plan of de oorspronkelijke reikwijdte

Het scenario waarin leidinggevenden menen dat ze Agile bezig zijn, terwijl ze dat in feite niet zijn, komt nog steeds vaak voor. In zulke gevallen was de uitdaging veel arbeidsintensiever, omdat er een enorme inspanning nodig was om de leidinggevenden te overtuigen dat ze op het verkeerde spoor zaten, en om hun het echte Agile en de voordelen daarvan te laten zien. Het kwam dan ook wel eens voor dat iemand in dat geval zei dat Agile gelijkstond aan anarchie, dat het alle kanten opging zonder enige aansturing en dat er sprake was van kwaliteitsverlies. Zoals ik eerder heb aangegeven, vereist het invoeren van Agile een cultuurverandering, vooral in traditionele sectoren die nog steeds erg hiërarchisch zijn en waar besluiten uitsluitend door de top van de piramide worden genomen. Leidinggevenden moeten hun teams in staat stellen om Agile met succes te implementeren.

Een gemakkelijk besluit met hoge kosten

Helaas bestaan top-down besluiten nog steeds en komen ze vaker voor in de publieke sector en bij traditionele organisaties. Ik zou niet willen zeggen dat bij een dergelijk besluitvormingsproces de implementatie gedoemd is te mislukken. Het werkte zelfs in meerdere gevallen, voornamelijk vanwege de pseudo-motivatie die ontstond doordat het ging om een opdracht van het senior-managementteam. Echter, elke keer dat het Agile-proces van start ging op grond van een soortgelijk besluit, kostte het meer inspanning en tijd om het gehele team aan boord te krijgen en de nieuwe werkwijze en het gekozen kader te volgen.

Top-down besluitvorming wordt vaak genomen met KPI’s van andere bedrijven als maatstaf, die een toename in gebruikerstevredenheid, productiviteit, codekwaliteit, snelheid of vergelijkbare meetgegevens laten zien. Mijn ervaring is dat vijf op de tien teams die Agile invoeren, betere productiviteit, klanttevredenheid en kwaliteitsverhoging op de middellange termijn en een afname van de totale kosten op de lange termijn realiseren, om nog maar te zwijgen van andere KPI-verbeteringen. Dat percentage verandert in acht op de tien wanneer ik mijn gegevens selecteer op teams waarbij het besluit om Agile te implementeren een democratisch besluit was, zodat alle leden van het team deel werden van het proces.

Het idee verkopen, de voor- en nadelen presenteren, het uitvoeren als een proef in een specifiek project of het onderwerp bespreken zijn altijd de beste manieren gebleken om het aan te pakken. Het is tijdrovend, maar op een goede manier, omdat de motivatie en betrokkenheid van het team vanaf dag één wordt opgebouwd door iedereen te betrekken bij het besluitvormingsproces.

Het belangrijkste punt is dat Agile geen raamwerk of proces is op basis van gevestigde regels, dat dicteert hoe dingen gedaan moeten worden. Teams moeten de vrijheid hebben om het uit te voeren op de wijze die het beste past bij hun project, waarbij ze kunnen kiezen voor een bestaand raamwerk (Scrum, Kanban, XP, Lean, SAfe…) of zelfs een nieuw raamwerk kunnen creëren op basis van bestaande raamwerken. Ze moeten ook vrij zijn om tools te kiezen die de dagelijkse praktijk beter ondersteunen.

Falen moet een tool zijn om te verbeteren en te leren, niet als schaamte, bestraffing of een excuus om de Agile-implementatie ongedaan te maken. Teams moeten de vrijheid hebben om elk proces en elk vereiste in twijfel te trekken en om nieuwe aanpakken uit te proberen. Wanneer ze falen, hebben ze genoeg materiaal om te leren van fouten en te verbeteren in de volgende cyclus.

“Falen is gewoon de kans om opnieuw te beginnen, ditmaal intelligenter.” — Henry Ford

Soms is Agile niet het antwoord

Het is een feit dat er geen goede of verkeerde manier van werken is. Elke methodologie kan op verschillende wijzen werken, afhankelijk van teams en organisatiecultuur. Het is belangrijk op te merken dat Agile kan worden toegepast op elk bedrijf, elk product en elke dienst, niet alleen op softwareontwikkeling. Bedrijven gebruiken de filosofie om vliegtuigen en liften te bouwen, om nieuwe marketingcampagnes op te zetten of zelfs om een gehele conglomeratie te moderniseren.

Er zijn echter enkele omstandigheden, niet gerelateerd aan mensen of cultuur, die ongunstige scenario’s opleveren voor het implementeren van Agile, en dat zijn de volgende:

• Problemen kunnen achtereenvolgens worden aangepakt, in afgeschermde teams, of de prioriteit om ze op te lossen is enkel een zaak van urgentie
• Eindgebruikers kunnen het product of de dienst niet gebruiken voordat het volledig afgerond is
• De organisatie dient te werken als een machine, erg hiërarchisch, waarin voortdurende veranderingen en innovatie niet noodzakelijk zijn
• Klanten of eindgebruikers zijn niet beschikbaar om mee samen te werken
• Wijzigingen doorvoeren op een laat moment in het proces is te duur of zelfs onmogelijk
• Mislukkingen en fouten kunnen onomkeerbare schade veroorzaken
• De markt is stabiel en voorspelbaar
• Bestaande oplossingen zijn stabiel en verhelpen het probleem op een manier waaraan innovatie niets zou veranderen of toevoegen
• Digitale transformatie is niet noodzakelijk voor de soort diensten of producten die je bedrijf biedt
• Het brengt geen schade toe aan het bedrijf wanneer veranderingen niet snel of regelmatig worden doorgevoerd

Tenzij je factoren hebt vastgesteld die Agile ongunstig maken voor je bedrijf, dienen mislukkingen te worden verwacht, en ze zullen zich, zo is mijn ervaring, hoogstwaarschijnlijk voordoen als je je niet houdt aan de in dit artikel besproken punten. Als het niet lukt om de werkwijzen van Agile te implementeren, kan dit ten minste leiden tot een beter begrip van je organisatie en andere veranderingsprocessen op gang brengen. Doe je voordeel met deze leerervaringen en vind manieren om je bedrijf te verbeteren. Uiteindelijk is dat immers het primaire doel.

Over de auteur: Willian Corrêa werkt als Technical Director bij Rangle.io.