Sinds het ontstaan van Agile zou je verwachten dat we wel beter zouden weten. Maar we blijven we in de meeste gevallen stevig vasthouden aan een watervalaanpak hoewel we inmiddels toch wel de bijbehorende bekende nadelen ervan kennen. En dat terwijl dit in veel gevallen een uitstekende alternatieve aanpak mogelijk is; de Agile-aanpak. Wat me opvalt is dat vele organisaties er niet toe willen overgaan om de projecten volgens Agile te gaan uitvoeren, ondanks de evidente voordelen.
Het doen van projecten op een traditionele watervalmanier is kennelijk een kwestie van gemak. Iedereen kent het; uitgebreid en gedetailleerd requirements verzamelen, een voorstel maken, een functioneel en technisch ontwerp maken, bouwen, testen, opleveren,en klaar. Impliciet nemen we de volgende zaken op de koop toe: veel te veel requirements (onderzoek heeft aangetoond dat we uiteindelijk bijna de helft niet gebruiken), veranderingen in scope tijdens de uitvoering van het project en de gevolgen voor de prijs en opleverdatum, soms weken tot maanden later dan initieel gepland. Tenslotte blijkt achteraf maar al te vaak dat de klant eigenlijk iets ander bedoelde dan er uiteindelijk geleverd wordt.
Waarom dan toch niet voor een alternatief kiezen? De Agile-aanpak adresseert juist die zaken die in de traditionele aanpak (lees waterval) meestal mis gaan. De Agile-aanpak zorgt voor oplevering binnen tijd en budget en een zeer hoge klanttevredenheid. Agile kan prima omgaan met aanpassingen tijdens de uitvoering van het project en het uiteindelijk resultaat sluit nauw aan bij de verwachtingen.
Bovendien wordt bij de Agile-aanpak veel sneller van start gegaan omdat de uitgebreide requirementsfase beperkt blijft tot het verzamelen van high level requirements. De high level inventarisatie van de requirements wordt vervolgens verwerkt tot een projectscope die in een bepaalde tijd, de timebox, geleverd wordt. Ook de doorlooptijd van Agile-projecten is doorgaans veel korter omdat er gefocust wordt op de features die echte business value brengen. De realisatie vindt plaats in zogenaamde iteraties. Iedere Iteratie, met een typisch duur van twee tot drie weken, zorgt voor een werkende oplossing die direct door de business gebruikt en getest wordt. Iedere iteratie zorgt voor een qua functionaliteit rijker wordende applicatie. De applicatie is gereed als de timebox opgebruikt is.
Voorwaardelijk voor de Agile-aanpak is dat de business zelf actief betrokken is bij de projectrealisatie. Dit is beslist een kritische succesfactor. Door zelf actief deel te nemen aan de verwezenlijking, kan en moet de business direct invloed uitoefenen op het uiteindelijke projectresultaat. Op deze manier zijn change requests tijdens de uitvoering in te voegen. Uiteraard zullen andere features, die een lagere prioriteit hebben, moeten wachten op een volgende release.
Deze Agile-manier van werken garandeert een projectresultaat dat zeer nauw aansluit bij de businesswensen. Dat eist echter wel van de business dat zij mede verantwoording nemen voor het eindresultaat. Hoewel deze werkwijze voor sommigen eng lijkt, zijn de resultaten van Agile-projecten beslist kwalitatief beter. Bovendien is er door een goed Agile-ontwikkelplatform te gebruiken, in combinatie met een ondersteunende projectmanagementomgeving, een aanzienlijke tijd- en kostenbesparing te realiseren!
Kortom Agile is niet eng, meer een kwestie van angst voor het onbekende!
Ruud Hochstenbach
Technical account/partner manager
OutSystems
Heel goed artikel: het is inderdaad een soort van paradox waar de angst voor Agile vandaan komt. Je ziet in de praktijk vaak dat als het spannend wordt er naar het stuur gegrepen wordt, en dat een soort van schijnzekerheden gezocht worden in heel rigide projectmanagement. Ik zeg expres schijnzekerheden, want het wordt er eigenlijk alleen maar erger van. Agile neemt die nadelen weg, maar je moet er wel een beetje dapper voor zijn, of beter gezegd: je moet bereid zijn jezelf niet langer voor de gek te houden.
Leuk artikel en reclame voor Agile
Ik kan me ook goed vinden in de strekking van het artikel. Het is nu eenmaal zo dat veel mensen van nature vasthouden aan wat ze gewoon zijn. Aan de andere kant is niet iedereen en niet iedere organisatie in staat om zomaar over te schakelen op het ‘leven’ van Agile principes. Zo verandert in mijn visie bijvoorbeeld de rol van de traditionele project manager en dat stelt niet iedereen op prijs. En het kan een organisatie veel dieper raken, zij het, wat mij betreft, inderdaad ten goede. Ik heb onlangs bij een Amsterdams gaming bedrijf weer mogen zien hoeveel meer resultaat je kunt realiseren met Agile principes. Voor diegene die meer inzicht willen krijgen over hoe je blijvend succesvol kunt zijn met Agile, download het gratis ebook over dit onderwerp via http://www.empulsys.com/nl/free-reports/48
De winst van agile werken is groot, maar het is een uitdaging en vergt de juiste begeleiding om een agile werkwijze in een traditionele organisatie in te voeren. Het vergt erg veel discipline van IT projectteamleden en business vertegenwoordigers juist omdat er zo interactief en kortcyclisch gewerkt wordt. Het artikel is een mooie reclame voor agile development maar wat mij betreft erg oppassen met het creeeren van een grotere hype dan het al is. Dus niet omdat het niet de juiste weg is, maar omdat het met beleid moet worden ingevoerd in een tempo dat bedrijven maar zeker ook IT leveranciers zelf aankunnen. Zo niet dan leidt het tot falen, teleurstelling en afbreuk van ons vakgebied.
Vooropgesteld dat mijn persoonlijke ervaring in de lijn ligt die Ruud schetst, namelijk dat de Agile-aanpak succesvoller is dan Waterval, wil ik wel waarschuwen dat zijn stelling: “deze Agile-manier van werken garandeert een projectresultaat dat zeer nauw aansluit bij de businesswensen” veel te hoge verwachtingen schept van de Agile-aanpak alleen.
Twee van de belangrijkste principes van Agile zijn: “The best architectures, requirements, and designs emerge from self-organizing teams.” En “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
M.a.w. Agile werken vereist een hoge mate van discipline, deskundigheid en vakmanschap van een op elkaar ingespeeld team van professionals. En een klant en een project manager die het team vertouwt op hun kennis en kunde. Dat cruciale aspect, “trust individuals”, mis ik in het betoog van Ruud.
Je kan Agile niet overlaten aan een willekeurig team met weinig kennis en ervaring. Sta je voor de keus voor een Agile-aanpak zonder de juiste professionals, dan is Agile inderdaad wel eng, en kies je toch liever voor een aanpak met meer armslag … en teveel requirements …
Wat een enorm enthousiasme, zowel in het artikel als in de reacties. Begrijp me goed, ik ben zeker geen tegenstander van Agile, maar je kunt overdrijven.
Alle flexibiliteit van Agile komt tegen een stevige prijs: je hebt aan het begin van het project geen idee wat het eindresultaat wordt, nog wat de totale kosten zijn. Niet dat waterval in deze erg goed scoort, maar dit zijn toch belangrijke aspecten voor een opdrachtgever: wat kost het, hoelang duurt het en wat heb ik aan het einde? De basis voor de business case.
Daarnaast zijn teams bij Agile behoorlijk zelfsturend. Dat is mooi en kan behoorlijk goed uitpakken bij kleinere projecten, maar het is nou eenmaal niet altijd mogelijk projecten in kleine brokjes op te knippen. Bovendien heeft centrale sturing ook zo zijn voordelen, je kunt bijvoorbeeld veel makkelijker met juniors in een team werken.
Ook vind ik het wat kort door de bocht dat in heel wat Agile stukjes (zoals hier) alleen waterval als alternatief wordt genoemd, terwijl dat de andere kant van het spectrum van ontwikkelmethoden is. Tussenwegen als prototyping en RUP zijn in deze nog niet zo slecht, vooral aangezien die ook flink aandacht besteden aan betrokkenheid van de gebruiker, maar wel een betere specificatie en documentatie afdwingen dan Agile.
De paragraaf met de randvoorwaarde voor Agile is meteen de paragraaf die antwoord geeft op de vraag waarom men niet overgaat op Agile. Zolang projecten nog te vaak ICT projecten zijn en dus ‘maar door de ICT afdeling’ opgelost moeten worden wordt de genoemde randvoorwaarde niet gehaald.
Verder missen in bekende Agile methodes nog belangrijke onderwerpen die voor hoog-niveau managers wel relevant zijn:
Weten we goed wat we willen en wat kost het precies?
Er zijn maar weinig financiële managers die een akkoord geven op een project met een onbekend eindresultaat (waarbij ze er voor het gemak maar van uitgaan dat kiezen voor een bekend eindresultaat vaak betekent dat gekozen wordt voor een onbekende eindafrekening).
Verder vinden voornamelijk ICT clubs en ICT afdelingen Agile spannend en de organisatie niet. Zo zijn er wel veel Scrum masters binnen ICT afdelingen maar zie je ze nooit op business development afdelingen.
Ik sta zelf volledig achter de Agile ontwikkelmethode maar we focussen ons te vaak op de voordelen en de uitleg die daarbij hoort. We vergeten vaak dat het kiezen voor Agile betekent dat de projectteams mandaat krijgen, er veel capaciteit van alle disciplines moet worden ingezet (en niet alleen ICT-ers) en dat heeeeeeeeel veel bedrijven hier geen juiste bedrijfscultuur voor hebben. Dat is toch echt controle op papier en akkorderen van documenten: dit is wat je krijgt en het kost zoveel.
Agile gaan werken is een cultuursverandering voor de gehele organisatie tot aan het management team toe. En dat is best eng.
Beste Ruud,
Een goed artikel en zoals in bovenstaande reacties terecht wordt aangegeven is het zaak te weten in welke fase de organisatie zit. CMMI levels kennen steeds meer bedrijven. Vanuit de IPMA-Agile werkgroep hebben we dit al vertaald naar Agile Maturity levels. Dan zien de bedrijven ook welke stapjes ze kunnen nemen.
Beste Peter,
Graag wil ik kort reageren op je tweede alinea. “Weten we goed wat we willen en wat het kost?”
Met juiste ondersteuning kan er wel degelijk vooraf een uitspraak gedaan worden over wat men krijgt en wat het kost. Binnen OutSystems hebben we daarvoor een Scoping en Sizing applicatie ontwikkeld die op basis van metrics een inschatting van de ontwikkeltijd maakt. Deze metrics worden toegeschreven aan bepaalde stukken tekst in de beschrijving van een feature. Die beschrijving vertelt de eindgebruiker in klare taal wat er gebouwd gaat worden. Dat is erg belangrijk omdat hij/zij moet kunnen herkennen wat er nu eigenlijk ‘gekocht’ wordt. Door met metrics te werken (die opgebouwd zijn uit 600+ OutSystems Agile projecten) zijn we in staat vooraf te vertellen wat de klant krijgt en wat het kost.
Als het project eenmaal gestart is en dus het bouwteam bekent is, zullen waar nodig de schattingen worden bijgesteld. Sommige features hebben iets meer tijd nodig en andere blijken te ruim geschat te zijn. In de praktijk zien we dat die dan uitbalanceren.
Verder ben ik het er helemaal mee eens dat het fijn zou zijn als de scrum master een business medewerker zou zijn. De business moet onderdeel van het projectteam zijn. Een ander punt, dat je zeer terecht aanhaalt is het mandaat. Het projectteam moeten beslissingen kunnen nemen. Al met al is het doen van Agile projecten voor de business echt een andere manier van werken die, indien goed toegepast, beslist zijn vruchten afwerpt.
Agile onderkent een aantal overbekende problemen:
– requirements zijn bij lange na niet volledig
– bekende requirements gaan veranderen
– fouten worden gemaakt
Wanneer iemand dan gaat vragen wat een totaal project gaat kosten, kan niemand daar een volledig antwoord op geven, geen mens die weet wat er exact moet worden gebouwd. Dat is met de watervalmethode echt niet anders, alleen doen we dan voorkomen alsof we alle requirements hebben, er niets verandert en er geen fouten worden gemaakt.
Met agile kun je per deeltraject aangeven wat je gaat doen en wat dit stukje gaat kosten. Ook kun je gemaakte fouten herstellen en nieuwe/gewijzigde requirements inpassen. Allemaal zaken die gaan gebeuren, die je toch moet doen. Wanneer je het helemaak goed doet, kun je zelfs halverwege een project (tijdelijk) stoppen, dan zit je met een half product, maar wel met een half product dat iets kan. Met de bekende watervalmethode sta je nog met lege handen, heb je dus niets. Dat is ook een reden waarom bij watervalmethodes de budgetoverschrijdingen nog wel eens heel erg uit de hand willen lopen, men probeert door iets meer budget toch het project klaar te krijgen. En dan nog ietsjes meer, en nog ietsjes meer en nog een klein beetje extra dan zijn we echt klaar… Uiteindelijk wordt de stekker eruit getrokken, vele miljoenen richting riool en geen systeem. Dat kan anders, dat kan beter.