Follow Us on Twitter

Goed agile is snel (maar ook moeilijk)

Gepubliceerd in

Januari 2014 – Agile is erg populair aan het worden. Veel organisaties zijn al agile of zijn begonnen met agile. Toch ervaren wij in de praktijk dat lang niet altijd alle beloftes van agile waargemaakt worden. Blijkbaar is het toch niet zo makkelijk allemaal. Dit Whitebook zet nog eens op een rijtje wat de agile belofte inhoudt, wat organisaties weerhoudt om de voordelen van agile te plukken en wat je kan doen om bepaalde hindernissen weg te nemen.

Wat is ook alweer de agile belofte?

Het kernthema binnen agile is het (snel) realiseren van waarde. Door een kort-cyclische aanpak worden in hoog tempo producten of deelproducten gerealiseerd. Hierbij worden producten die de meeste waarde creëren als eerste gerealiseerd.
Agile wordt ook wel eens andersom benaderd. Door de kort-cyclische aanpak worden snel problemen zichtbaar bij het realiseren van een product (of project). Doordat die problemen snel zichtbaar zijn, ben je ook snel in staat de oorzaken van deze problemen weg te nemen. Dat is effectiever dan wanneer je pas aan het einde van een project tegen die problemen aanloopt. Een agile project zal daarom uiteindelijk meer waarde opleveren.

Een belangrijke randvoorwaarde voor het creëren van waarde is echter dat het opgeleverde (deel)product daadwerkelijk in gebruik genomen wordt. Daar is het project uiteindelijk toch voor bedoeld.

In PRINCE2 en MSP (Managing Successful Programs) staat goed beschreven wat het verschil is tussen het leveren van producten en het daadwerkelijk creëren van waarde.

Product benefits

Projecten leveren producten. Hiermee ontstaan capabilities ("vaardigheden" of "mogelijkheden") in de business. Echter, pas als die producten daadwerkelijk gebruikt worden ontstaan benefits (waarde).

Het is dus cruciaal bij een agile project ook een agile implementatieaanpak te volgen. Ieder opgeleverd product moet zo snel mogelijk in gebruik genomen worden, zodat waarde ontstaat.

Hindernissen

Snel waarde creëren blijkt echter in de praktijk nog niet zo makkelijk te zijn. Er zijn allerlei redenen die de snelheid van opleveren en in gebruik nemen van producten verhinderen. Onderstaand een opsomming van de belangrijkste hindernissen en de maatregelen die genomen kunnen worden om deze hindernissen weg te nemen.

Business Case denken

Ook bij een traditionele projectaanpak is het moeilijk voor veel mensen om vanuit een business case filosofie te denken. Het gaat hierbij om de afweging te kunnen maken met welk (deel)product de meeste waarde gecreëerd wordt, zodat er juist geprioriteerd wordt.

In mijn ervaring is het zo dat mensen te moeilijk kijken naar het business case aspect bij agile projecten. Bij een traditionele watervalaanpak is het wel moeilijk. De aanpak vraagt bij de start om een projectbudget voor in één keer veel functionaliteiten, waarbij waarde pas ontstaat aan het einde van het project. Je neemt hiermee veel risico en je wilt dat risico afdekken met een tot in de details uitgewerkte business case.

Als deze manier van denken toegepast wordt op agile projecten duurt het erg lang voordat een project goedkeuring krijgt om te starten (waardoor later waarde ontstaat) en wordt het belang van prioriteren binnen het project minder. De focus verschuift van "wat kunnen we morgen in productie nemen?" naar "wanneer hebben we alles gerealiseerd?".

Agile business case denken werkt anders:

  1. Na iedere iteratie willen we waarde creëren;
  2. Er is een hoeveelheid aan minimale functionaliteiten waarmee het project zich terugverdient;
  3. Er is een bepaalde hoeveelheid aan functionaliteiten waarvan het aardig is als we die ook krijgen, maar dat is niet strikt noodzakelijk;
  4. We stoppen het project als we het goed genoeg vinden.

Een agile business case zet het projectbudget initieel ergens in het schemergebied van de "extra" functionaliteiten. De minimale functionaliteiten zijn dan altijd gerealiseerd en mogelijk meer. Als het product goed genoeg is, wordt het project stopgezet. Aangezien in een agile project de projectkosten een constante zijn per iteratie (als het alleen gaat om resourcekosten), kan men zich concentreren op het realiseren en in gebruik nemen van functionaliteiten en daarmee het creëren van waarde.

Architectuur

Snel waarde willen creëren is een ding, het ook daadwerkelijk kunnen is iets heel anders. Over agile en architectuur is al veel geschreven. Een agile architectuur geeft richting aan een iteratieve manier van productontwikkeling en groeit tegelijkertijd mee gedurende het project. Het opzetten en doorontwikkelen van een agile architectuur vergt kennis en ervaring.

Waar ik in dit Whitebook echter over wil praten is de businesskant van architectuur.

We hebben geconstateerd dat waarde pas ontstaat als (deel)producten daadwerkelijk in gebruik genomen worden. Daarmee is de prioritering binnen een agile project primair een businesskeuze in plaats van een IT-keuze. Helaas worden veel softwareprojecten gezien als een IT-feestje en juist bij agile projecten is bovengemiddeld veel aandacht nodig voor de businesskant van architectuur. De oplossing is eenvoudig: beleg de verantwoordelijkheid voor de business architectuur vanaf de start van het project en houdt de business architectuur actueel gedurende het project. Zo kan bijvoorbeeld goed overwogen worden of een bedrijfsproces eerst wordt afgemaakt in een basisversie (scenario A in onderstaande afbeelding), of een processtap eerst wordt verrijkt (scenario B).

Architectuur keuzes

Verandervermogen en verandermanagement

Agile projecten vergen een groot verandervermogen van zowel de business-afdeling die gaat werken met de oplossing, als de beheerafdeling die het gaat beheren. Als een project iedere twee weken nieuwe en/of gewijzigde software oplevert, dan moeten deze afdelingen ook in staat zijn iedere twee weken deze software te gebruiken en beheren. Dat is voor veel organisaties (nog) te veel gevraagd. De situatie die dan ontstaat is dat de business implementatie achter loopt op de releasefrequentie van het project, of dat er minder vaak opgeleverd wordt naar productie. Er wordt dan gekozen voor de minder moeilijke "alles of niets" aanpak. "We gaan pas live als het bedrijfsproces volledig is ondersteund".

Het is duidelijk dat op deze wijze later waarde wordt gecreëerd dan mogelijk was geweest. Een ander probleem is dat er potentieel achterstallig onderhoud ontstaat. Omdat software pas gebruikt wordt weken of zelfs maanden na realisatie, ontstaat de kans dat dan pas geconstateerd wordt dat er problemen of aanvullende wensen zijn met deze software. Intussen is het project wel verder gegaan en wordt aan andere functionaliteiten gewerkt.

Agile vraagt een volwassen verandermanagementaanpak, maar ook het project kan veel doen om de drempels om nieuwe software in gebruik te nemen te verlagen:

  • Vroege afstemming van functionaliteiten
    Multidisciplinaire samenwerking tussen business, beheer en project is essentieel. Hoe eerder in het voortbrengingsproces van software wordt samengewerkt, hoe groter de voorspelbaarheid van het eindresultaat, hoe beter de implementatie voorbereid kan worden;
  • Kleine iteraties
    Een kortere doorlooptijd van iteraties leidt tot nóg meer veranderingsmomenten, maar de omvang van de verandering per iteratie is wel kleiner en daardoor beter beheersbaar. Veranderingen moeten geen vervelende onderbreking zijn, maar een normaal onderdeel van de werkzaamheden.

Transparantie, problemen, doorzettingsvermogen en cultuur

Een kenmerk van een agile aanpak is dat het zichtbaar wordt hoe de project- en beheerprocessen écht lopen. Dat betekent ook dat zaken die niet goed gaan en in het verleden niet opgemerkt werden, opeens wel zichtbaar worden. Er "ontstaan" opeens een heleboel problemen en dat is lastig. We willen geen problemen maar oplossingen. Wij zien regelmatig bij organisaties die het agile pad opgaan dat agile principes geschonden worden om daarmee problemen "op te lossen":

  • Als het maken van een release lang duurt, dan wordt de iteratie langer gemaakt zodat het team "efficiënter" kan werken (in plaats van te werken aan het verbeteren van releasemanagement en daarmee het team echt efficiënter wordt);
  • Als er veel testbevindingen zijn, dan wordt de acceptatietest verschoven naar de volgende sprint (in plaats van ervoor te zorgen dat er minder testbevindingen ontstaan);
  • Als er veel misverstanden zijn over functionele eisen, dan wordt meer documentatie van te voren geschreven (in plaats meer samen te werken in de sprint);
  • De retrospective aan het einde van een iteratie wordt een rituele dans of wordt zelfs in het geheel weggelaten omdat "het toch geen zin heeft iedere keer dezelfde problemen te melden" (in plaats van het daadwerkelijk uitvoeren van verbeteracties in iedere iteratie en dat iedere keer te evalueren).

Om daadwerkelijk de voordelen van agile te plukken is een basishouding nodig van continu verbeteren: ieder probleem is een kans om te verbeteren en de agile inrichtingsprincipes helpen om die problemen zichtbaar te maken. Dat vergt discipline, doorzettingsvermogen, ondersteuning en begrip vanuit het hogere management en wellicht zelfs een cultuurverandering.

Er zijn veel andere voorbeelden te bedenken waarbij de benefits van een agile aanpak in gevaar komen, maar daarmee zou dit Whitebook te lang worden. De rode draad in het geheel is dat er een relatie is tussen snelheid en waarde enerzijds en inspanning/verandervermogen anderzijds.

Snelheid

Korte iteraties waarbinnen direct geaccepteerd wordt en waarna direct opgeleverd wordt naar productie leveren veel waarde op, maar zijn tegelijkertijd moeilijk realiseerbaar. Als de organisatie nog niet (agile) volwassen is ingericht, worden veel problemen zichtbaar. Er ontstaat een hoog "verbeterpotentieel". Het is dan aan de organisatie om te bepalen hoe hoog de lat wordt gelegd.

Het pad waar de meeste waarde ontstaat is het moeilijke pad: het vasthouden aan de agile principes en het wegnemen van hindernissen op dat pad. Dat wegnemen hoeft niet in één keer te gebeuren (en is vaak zelfs af te raden), het kan ook in kleine stapjes.

Conclusie

Uiteindelijk gaat het, ook bij IT, altijd over mensen. Mensen die een oplossing willen en mensen die een oplossing maken. Mensen willen daarbij geen problemen, ze willen oplossingen. De agile aanpak is daarom een moeilijke aanpak. Agile belooft het snel creëren van waarde, maar om daar te komen worden veel problemen zichtbaar die opgelost moeten worden. Snelheid is het sleutelwoord waarmee het ambitieniveau wordt bepaald. Hoe sneller, hoe meer waarde, maar ook hoe moeilijker: "goed agile is snel (maar ook moeilijk)".

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.