Agile werken heeft de wereld veroverd. Je ziet het overal. Maar! Is het wel succesvoller dan de reguliere methoden? En hoe is het met die methoden?

Het is duidelijk: de bekende watervalprojecten hebben nadelen: de gebruiker is uit beeld en krijgt veel later dan gepland, niet wat hij had gedacht, zo is nogal eens te horen. Met een watervalmethode ga je nat, zo lijkt het. En met agile gaat het veel beter, nietwaar?

Als we daar wat op inzoomen, zie je toch wat anders. In de vergelijking tussen watervalprojecten en agile projecten wordt meestal niet over de omvang van de projecten gesproken.

Lees ook:

Er is zoveel meer dan alleen Agile of Waterval

Projecten die gebruik maken van agile worden afgezet tegen projecten die volgens een watervalmethode werken. Het algemene beeld hierbij is dat agile projecten veel succesvoller zijn. Recent onderzoek van de Standish Group laat zien dat dat anders is als je naar de omvang van de projecten kijkt. De Standish Group heeft de succes-rate van watervalprojecten afgezet tegen die van agile projecten. Dan blijken over het algemeen agile projecten beter te scoren. Maar als je de omvang van de projecten meeneemt in de overweging, ziet het er anders uit. En waarom zou je de omvang niet meenemen? Een groot watervalproject is een project en een klein agile project ook, maar er zijn natuurlijk wel grote verschillen.

Als je de omvang van een project mee in beschouwing neemt, zie je dat de agile projecten toch iets minder succesvol zijn. Daar komt nog bij dat er, ook bij agile, afstemming nodig is om delen in het geheel te passen: prima als je een klein projectje op een agile manier doet, maar als je in een grote organisatie zit, moet het resultaat wel voldoen aan de bestaande architectuurafspraken. Hoe zorg je ervoor dat jouw puzzelstukje in de architectuur past?

Een ander punt is dat agile werken ook weer niet zo gemakkelijk is. Het werken in een Scrum-omgeving vraagt om gedragsverandering van alle betrokkenen. Het gaat om samenwerken, vrijheid in communicatie en zelfsturend kunnen werken. Er is geen projectmanager.

Agile projecten kunnen op een aantal elementen de mist in gaan. De belangrijkste zijn compliance en architectuur. Compliancy, het voldoen aan de spelregels, krijgt steeds meer aandacht. Maar hoe betrek je de Compliance Officer nu bij het agile werken? Niet door achteraf te vragen of het zo goed is.

Bij architectuur geldt iets vergelijkbaars: teams moeten bij de start verkennen welke architectuur geldt. Zijn er standaards, en welke? Is er een Chief Architect die checkt en regels geeft? Consulteer die dan vóór de start en niet pas op het eind!

De conclusie is: zorg ervoor dat agile meer is dan een hype, zorg voor de benodigde aandacht voor compliance, pas op de architectuur. Dan is prima denkbaar dat agile projecten over de hele linie  succesvoller worden dan de traditionelere methoden!

Kennisbank onderwerpen:

Kennisbank onderwerpen:

 

Reageer

Na het plaatsen kunt u uw reactie nog 30 minuten aanpassen.

Reacties

Goed om te lezen dat wat iedereen al vermoedde ook met cijfers kan worden onderbouwd. Ik snap jouw zorgen over compliance en architectuur, maar ik vraag me wel af of je de oplossing daarvoor in staffuncties en controle moet zoeken. Dat zijn nou net weer oplossingen die in een traditionele bureaucratie thuis horen en niet in een wendbare organisatie. Zo’n oplossing tast toch weer het eigenaarschap en de autonomie van de teams aan.

Een mooie conclusie: niet afserveren maar doordenken. Eerst de nodige aandacht op de pijnpunten. Wel ben ik benieuwd naar de groei van de organisatie daarna. Op naar een succesvollere aanpak van grote (agile) projecten!

x
x