Het is verdraaid lastig om met de fiets de Alpe d’Huez te beklimmen. Wat helpt? Knip de klim in stukjes en doe het bochtje voor bochtje. Ga niet voor bocht 1 tot en met 21, maar ga eerst voor bocht 1. Eigenlijk is dit een beetje hoe agile werkt. Een béétje, want agile gaat ook – en vooral – over sprinten en dat kun je op die alp maar beter niet doen.
Alles in de IT moet ineens agile. Het betekent letterlijk: behendig, lenig. In de IT-wereld staat het voor softwareontwikkeling in korte overzichtelijke sprints van meestal niet meer dan een maand. In sommige gevallen zelfs van maar een week. Kleine projecten met groepjes mensen om snel een slag te kunnen maken. Maar werkt het?
Vrijwel iedereen is het er wel over eens dat agile ‘ons’ veel goeds heeft gebracht. De gebruikers vanuit de business zijn blij, omdat gewenste veranderingen sneller in de software doorgevoerd worden. De ontwikkelaars zijn blij, omdat ze direct met de gebruikers in contact zijn en software maken die ook echt gebruikt wordt. In de agile werkwijze zijn blijheid en tevredenheid belangrijke targets en dat is bij de meeste stakeholders prima in orde.
Allemaal top dus? Nou, niet helemaal. Blije werknemers en blije eindgebruikers zijn geen garantie voor blije bestuurders. In veel bestuurskamers maakt men zich toch wel zorgen of dat zelfsturende werken in groepjes enthousiaste mensen, behalve tevredenheid nog wel software oplevert die voldoende businesswaarde genereert. In de praktijk betekent de kreet ‘Wij werken Agile’ bovendien nogal eens dat het nog wel even gaat duren voordat het af is. Dit laatste is overigens een bewering van columnist Jacob Spoelstra maar hij staat hierin niet alleen.
Mensen die floreren in een agile team zijn mensen die niet bang zijn voor verandering en minder geneigd zijn te zoeken naar zekerheden. Ergens aan willen en kunnen beginnen zonder dat het eindresultaat helemaal vaststaat is erg belangrijk. En dat is niet helemaal de wijze waarop mensen uit de financiële rapportagelijnen zijn ingesteld, zoals budgethouders en controllers. Voor hen ligt het blije gevoel van de agilisten minder voor de hand. Zij moeten hun beslissers overtuigen om budget vrij te maken voor agile projecten. Zij moeten ervoor zorgen dat zichtbaar wordt dat de agile ontwikkelde software ook echt waarde toevoegt aan de organisatie.
Hoe bepaal je in een agile omgeving de waarde van de opgeleverde software? Vanuit agile kijken we vooral naar gebruikerswaarde. Hierdoor krijgen user stories met de meeste gebruikerswaarde – ten opzichte van de kosten om ze te realiseren – de hoogste prioriteit. Vanuit het financiële kader denken we eerder in boekwaarde waarbij vooral de kosten van het realiseren van de software een belangrijke rol spelen. En de financiële sturing binnen organisaties gaat nogal eens wringen met een agile aanpak. Afhankelijk van de mate waarin het agile gedachtengoed is doorgedrongen binnen een organisatie ontstaat er ergens een ‘torsiemoment’ tussen het agile gedachtengoed gericht op het creëren van waarde, en de financiële verantwoording.Het is dus de kunst om de balans te vinden tussen de flexibiliteit die je met agile werken wilt bereiken en de voorspelbaarheid die bestuurders zoeken. En dan bij voorkeur op een manier die recht doet aan de drijfveren aan beide kanten. Win-win, inderdaad.
Wat overigens een groot voordeel is: agile software ontwikkelen biedt je de mogelijkheid om te stoppen als de software voldoende businesswaarde biedt. Goed is goed genoeg. Het is dan de kunst om op tijd te stoppen en je aandacht te richten op iets wat meer businesswaarde oplevert.
Daarom is het goed om af en toe eens een frisse blik van buiten te laten kijken naar de agile organisatie. Wordt er wel voldoende waarde geleverd? METRI kan dit vergelijken met andere bedrijven en helpen om de organisatie zo vorm te geven dat er maximale waarde geleverd kan worden.
Geen opmerkingen:
Een reactie posten