Ga direct naar inhoud

De 4 grootste onzinargumenten tegen Agile Scrum weerlegd

Rick Jager
2019-10-22

Waarom Agile werken?

Agile is gebaseerd op het werken in veranderlijke IT-omgevingen. De belangrijkste principes zijn opgeschreven in het Agile Manifesto. Er zijn veel verschillende frameworks, zoals SAFe, Kanban en Scrum die gebaseerd zijn op de Agile filosofie. Hierbij wordt Scrum gekenmerkt door het werken in korte sprints, het gebruik van vaste rituelen en drie vaste rollen in het Scrum Team. Deze rollen zijn het Development Team, de Scrum Master en de Product Owner. Scrum heeft duidelijke voordelen, zoals direct contact en feedback van de eindgebruiker, kleine, incrementele stappen (elke 2-4 weken) die waarde toevoegen aan het product, snel kunnen bijsturen als veranderingen van buitenaf impact hebben op het project en een verhoogde effectiviteit van het team. De Scrum Guide geeft hier uitgebreide uitleg over.

Het is duidelijk dat Agile werken toegevoegde waarde biedt aan elke organisatie (vergeet hierbij niet de ondersteunende afdelingen!) mits deze organisatie open staat voor (vergaande) veranderingen ten opzichte van de waterval methode. Een aantal van de argumenten tegen de Agile manier van werken weerleg ik hieronder.

“Agile Scrum werkt niet voor grote projecten met vastgestelde deadlines”

Zoals hierboven uitgelegd is Agile Scrum het meest geschikt in veranderlijke, complexe omgevingen. Als de omgeving en de scope van het project kan veranderen, dan helpt Agile om snel waarde toe te voegen op een iteratieve en incrementele manier. Door het prioriteren van de requirements (de vereisten binnen het project) en het aanbrengen van focus, wordt waarde toegevoegd op de belangrijkste onderdelen van het project en wordt de deadline gehaald. Met de klassieke waterval methodiek moet er volgens een gedetailleerd plan aan alle requirements binnen het project worden voldaan. In een complexe omgeving is de kans groot dat niet alleen de prioritering van deze requirements verandert, maar ook de inhoud hiervan! Juist hierdoor wordt de deadline vaak niet gehaald en loopt het project vertraging op.

“Agile Scrum zorgt voor schijnzelfstandigheid”

Een vaak gehoord punt is dat Agile schijnzelfstandigheid opwekt bij het Development Team; het Development Team mag werken op hun eigen manier, zolang de baas die manier maar goed vindt. Dit is een argument dat makkelijk te weerleggen is: De Product Owner (dus niet de baas of manager!) is aangewezen om uitgebreid en constant contact te hebben met stakeholders, te weten wat er speelt in de organisatie en daarmee te bepalen waar de prioriteiten liggen. Maar hóe iets opgeleverd wordt, dat is de expertise van het development team! Het Development Team beslist de hoeveelheid die opgeleverd kan worden en op welke manier. Hierbij heeft ook het Development Team contact met de klant tijdens de Sprint Review voor een feedbackmoment. Andere stakeholders buiten het team hebben niks te zeggen over de werkwijze van het Development Team.

“Agile Scrum is niet holistisch”

Een ander argument is de beperking van de multidisciplinaire teams binnen Scrum. Development Teams in Scrum hebben tussen de 3 en 9 leden, zodat teamleden elkaar makkelijk kunnen vinden en er efficiënt gewerkt kan worden. Maar als organisaties echt Agile en holistisch zouden zijn, moeten in dit team dan ook HR, sales en andere afdelingen zitten?

Dit is een duidelijke misconceptie: elk Scrum team heeft zijn eigen purpose (doel). Dit doel bepaalt de scope van het team en hierop moeten de expertises in het team afgestemd zijn. Op deze manier heeft elk team zijn eigen (interne) klant voor wie hij waarde toe voegt. In een volledig Agile organisatie zijn deze teams, met elk hun eigen purpose en scope, goed op elkaar afgestemd, zodat elk team bijdraagt aan het gemeenschappelijke doel van de organisatie. Dit heet ‘Scaling Agile’ en organiseert verschillende Scrum teams op een manier om complete waarde toevoegen en holistisch te zijn.  Een van de bekendste voorbeelden van Scaling Agile is die van Spotify.

“Implementatie van de Agile manier van werken duurt te lang”

Het zou te lang duren om een Agile team te vormen (dit zou 3 tot 4 jaar duren) terwijl veranderingen in de omgeving veel sneller gaan. Op het moment dat het team gevormd is, zou deze alweer overbodig zijn. Het vormen van een eerste Agile team zou inderdaad enige tijd kunnen duren, omdat veel organisaties al jaren gewend zijn aan de huidige manier van werken en hierdoor terughoudend zijn om te veranderen.

Agile Coaches helpen om de transitie naar een Agile manier van werken zo efficiënt mogelijk te laten verlopen. Deze coaches helpen niet alleen het Scrum Team met hun mindset, gedrag en Agile kennis, maar kijken ook breder naar omliggende afdelingen en managers. De Agile Coach bezit alle tools om de transitie snel en gestroomlijnd te laten verlopen.

Als een organisatie ‘volwassen’ is in Agile, dan is het oprichten van nieuwe teams en veranderingen in de teams snel gerealiseerd. Door de manier waarop Scrum georganiseerd is, weten medewerkers precies hoe het best gewerkt kan worden en wat ze van elkaar en de organisatie mogen verwachten. Het Scrum framework blijft immers hetzelfde en rollen zijn duidelijk gedefinieerd. De doorlooptijd voor het maken van een nieuw Scrum Team zal dus minder tijd kosten dan verschuivingen van en tussen teams in een traditionele organisatie. Reden hiervoor is dat bij deze organisaties de rollen, tradities en gebruiken telkens opnieuw uitgevonden moeten worden.

Dus ga aan de slag!

Agile Scrum is een methodiek. Indien juist geïmplementeerd, zorgt Agile Scrum voor grote voordelen in flexibiliteit en kwaliteit. Door verkeerde implementatie of traditioneel denken worden Scrum Teams vaak niet op de juiste manier gevormd, waardoor niet alle mogelijke voordelen behaald worden. Voor organisaties die beginnen met Scrum is het aan te raden om de methodiek volledig te implementeren, ondanks eventuele tegenargumenten en hiërarchische veranderingen binnen de organisatie. Als de manier van Scrum eenmaal geïmplementeerd en geaccepteerd is, dan kunnen er elementen veranderd worden om te voldoen aan de wensen van de organisatie. Op deze manier zijn de voor- en nadelen voor Scrum, die per organisatie verschillen, inzichtelijk en is de organisatie in staat zich verder te ontwikkelen.