Artikel

Business case voor agile aanpak

Indien u bij aanvang van een project van enige omvang en complexiteit, alle relevante variabelen kent, alle consequenties van belangrijke beslissingen kunt overzien, (blijvend) kan beschikken over de juiste informatie en benodigde middelen (mensen, tijd en geld), en dus de voortgang en de uitkomst van het gehele traject nauwkeurig kunt voorspellen - dan is dit artikel niet interessant voor u. Ik neem namelijk afstand van het idee dat een project alleen kans van slagen heeft wanneer het controleerbaar is, en dat er een methodiek bestaat die ervoor zorgt dat de geest van onvoorspelbaarheid weer terug in de fles kan worden gebracht.

Scheuren in het bastion van de maakbaarheid

Het afgelopen decennium zijn er behoorlijk grote scheuren ontstaan in het bastion van de maakbaarheid van softwareprojecten. Voorspelbaarheid, eens de heilige graal van de traditionele ontwikkelmethodologie, speelt al lang niet meer de eerste viool in een wereld vol verandering en onzekerheid.

Het controle-denken is wat mij betreft ingehaald door het agile gedachtegoed: een denkwijze die niet ‘voorspelbaarheid’, maar juist ‘adaptiviteit’ als oplossing presenteert om de effectiviteit en slagkracht te verhogen en daarmee project risico’s te verlagen.

Verandering: vriend of vijand?

De traditionele, plangedreven aanpak, kan per definitie niet goed overweg met onverwachte zaken die de geplande voortang van een project danig kunnen verstoren. De gevolgen hiervan kennen we maar al te goed: project niet op tijd en/of over budget, kwaliteitsoffers, haastwerk, stress, ontevreden klanten.

Daarentegen is de agile werkwijze er juist op ingericht om adequaat te kunnen reageren op onvoorziene veranderingen in de ‘boze’ buitenwereld. Het gaat zelfs nog verder: agile verwelkomt veranderingen als mogelijkheid om een voorsprong te nemen op de concurrentie. Hoe dit in de agile benadering in essentie zijn beslag krijgt, heeft alles te maken hoe wordt omgegaan met het initiële pakket van eisen, in casu de door de klant gevraagde functionaliteit van het eindproduct.

Plan-driven: Het vooraf vastleggen van specificaties

De traditionele benadering kenmerkt zich door het vooraf volledig vastleggen van de gewenste functionaliteit in een omvangrijk requirements-document. Op basis van deze ‘blueprint’ wordt een inschatting gemaakt van de benodigde inspanning, en krijgt de klant te horen wanneer het gespecificeerde product zal worden opgeleverd, en tegen welke prijs. Op zich uiteraard een valide gang van zaken, ware het niet dat de realiteit een stuk weerbarstiger is. Slechts weinig projecten zijn op het afgesproken tijdstip klaar, en vaak is het met de deadline in zicht, alle hens aan dek om toch de beloofde functionaliteit op te kunnen leveren. En nog voordat iedereen weer is uitgehijgd, blijken de productspecificaties toch voor meerdere uitleg vatbaar, met ontevredenheid of teleurstelling bij de opdrachtgever als mogelijk gevolg.

Maar zelfs al zou het eenduidig vastleggen van alle specificaties bij aanvang van het project goed te doen zijn, dan is het niet gezegd dat de klant tevreden is bij oplevering. Hij krijgt weliswaar wat er is afgesproken, maar in de tussentijd heeft de wereld niet stilgestaan, en het opgeleverde product voldoet niet meer aan de actuele marktvraag.

Change-driven: Rekening houden met voortschrijdend inzicht

De agile aanpak houdt juist expliciet rekening met voortschrijdend inzicht, en kan tussentijdse aanpassingen in de specificaties zonder al te veel kleerscheuren verwerken. In plaats van het vooraf fixeren van de functionaliteit, worden nu de doorlooptijd en de resources vastgelegd, en is de scope van het project variabel.

Dit is nu echter een heikel punt voor veel opdrachtgevers die dan in koor zullen roepen: “Ja, maar dan weet ik dus vooraf niet wat ik krijg voor mijn geld!” Daar zit een kern van waarheid in, maar de andere kant van de medaille wordt dan wel over het hoofd gezien. De opdrachtgever kan tijdens het gehele traject namelijk grote invloed uitoefenen op de functionaliteit die op het afgesproken tijdstip opgeleverd gaat worden, en kan tot die tijd wijzigingen in de specificaties doorgevoerd krijgen zonder additionele kosten.

In plaats van gehakketak over contracten en meerwerk, wordt de energie gestopt in de realisatie van een product dat op het moment van oplevering zoveel mogelijk voldoet aan de actuele marktvraag.

Figuur 1: Plan-driven versus Change-driven

Agile: wederzijds vertrouwen tussen uitvoerder en klant

Eerlijkheid gebiedt mij te zeggen dat het behoorlijk veel kruim kan kosten om deze aanpak te laten werken. Belangrijkste voorwaarde is natuurlijk de directe betrokkenheid van de opdrachtgever. Zonder regelmatige feedback en bijsturing van de klant of eindgebruiker wordt het een lastig verhaal. Vandaar ook dat de agile aanpak een incrementele werkwijze voorstaat, opdat er in een zo vroeg mogelijk stadium feedback van echte gebruikers kan worden verzameld. In de agile wereld zult u geen projecten aantreffen waarbij de bemanning in een duikboot zit die na weken of maanden weer eens boven komt om te zien hoe het er boven water uitziet. Aangezien de project scope in onderling overleg tussen uitvoerder en klant wordt geoptimaliseerd, zijn regelmatig contact, wederzijds vertrouwen en openheid noodzakelijke voorwaarden. Hoewel er mogelijkheden zijn om ook non-believers over de streep te trekken - met een klant die uitsluitend fixed price, fixed time en fixed scope contracten wil afsluiten, blijft het kwaad kersen eten.

Agile: niet een exclusief R&D feestje

De motivatie om over te stappen op de agile manier van werken is in vrijwel alle gevallen gestoeld op een aantal, met elkaar samenhangende, commerciële drijfveren, zoals verbetering van de ‘time-to-market’, beter aansluiten bij de wensen van gebruikers, en het bieden van een hogere ‘customer value’.

In deze doelstellingen zien we direct het ‘change-driven’ aspect van de agile aanpak weerspiegeld, gekoppeld aan een sterke proactieve focus op de actuele behoeften van de klant of gebruiker.

Helaas blijft de introductie en het uitrollen van de agile werkwijze vaak beperkt tot de R&D afdeling. Wil een organisatie het volle profijt hebben van de nieuwe aanpak, dan zal ook een volgende stap gezet moeten worden: het in lijn brengen van de overige afdelingen en competenties (sales, marketing, service, etc.) met de agile manier van werken op de R&D afdeling. Wanneer de ontwikkelaars een agile oase vormen in een non-agile organisatie, dan is er sprake van suboptimalisatie.

De agile architect

We hebben het nog niet gehad over de rol en verantwoordelijkheid van de architect in een agile werkomgeving. De relatie tussen agile en architectuur blijft een heikel punt. De grote boze wolf van veel agile adepten is het ‘BDUF’ (Big Design Up Front), een ontwikkelmethode waarbij het algemene ontwerp eerst wordt afgemaakt, voordat met de implementatie wordt gestart. Helemaal ongelijk hebben ze niet, want er bestaan verstokte architecten die moeite hebben om achter de kristallen bol vandaan te komen, en vasthouden aan een langdradig en topzwaar architectuur proces.

Ik denk dat ook hier de architect valt voor de verleiding om de geest van onzekerheid en verandering zoveel mogelijk terug in de fles te krijgen. Natuurlijk is architectuur onmisbaar bij de realisatie van complexe en omvangrijke software-intensieve systemen. Het kan echter geen kwaad om eens met een agile bril op naar architectuur te kijken.

Het huwelijk tussen agile en architectuur

Architectuur is vooruit zien. De vraag is alleen hoe ver, en in welke richting. Dankzij het agile gedachtegoed groeit gelukkig het bewustzijn dat klanten en eindgebruikers een prominente rol dienen te hebben bij de totstandkoming van de architectuur. Hierbij is het aan de architect om uit te vissen wat vastligt, en waar in de nabije toekomst wijzigingen of uitbreidingen zijn te verwachten. Dit onderscheid leidt tot een stroomlijning van het architectuurproces. Wat vaststaat, wordt zonder verdere toeters en bellen ontworpen en gerealiseerd. Waar vraagtekens zijn, worden architecturele maatregelen getroffen om de noodzakelijke flexibiliteit en adaptiviteit van het systeem te waarborgen.

Deze verhoogde aanpasbaarheid kan een aanzienlijke besparing op het onderhoud van softwaresystemen opleveren. In een wereld waarin gemiddeld meer dan de helft van de ‘Total Cost of Ownership’ van softwaresystemen voor rekening komt van maintenance, een niet te onderschatten aspect bij het opstellen van een business case.

Dus juist door het toepassen van agile principes op de architectuur zelf, zijn architecten in staat om de agility van systemen en producten te vergroten. De bijdrage van architecten gaat daarmee een stuk verder dan alleen de optimalisatie van het ontwikkelproces. Het huwelijk tussen agile en architectuur levert dus een vruchtbare combinatie op van procesinnovatie en productinnovatie!

De agile manager

De toetssteen voor elke business case voor agile is de beoogde mate van ‘agility’ op handelingsniveau bij iedereen in de organisatie. De realisatie hiervan is volgens mij de werkelijke uitdaging, die in mijn optiek een stuk verder gaat dan alleen de introductie van de agile aanpak op de R&D afdeling.

Een belangrijke doelstelling van agile is immers het aanmoedigen van ‘self-empowerment’, en het werkelijk delegeren van verantwoordelijkheden aan de mensen die het werk moeten doen. Het duurt vaak wel even voordat bij medewerkers het kwartje valt dat zij werkelijk de ruimte en ook de verantwoordelijkheid hebben om hun eigen werk naar eigen inzicht te organiseren. Voor sommige managers is de stap naar agile leiderschap echter nog veel groter. Zeker de wat conventionele manager zal maar met moeite afstand kunnen nemen van de behoefte aan controle en voorspelbaarheid.

Natuurlijk is dit patroon sterk verweven met de bedrijfscultuur, die onder de oppervlakte sterk kan botsen met de agile mindset.

De daadwerkelijke invoering van het agile gedachtegoed in een organisatie is op de eerste plaats een veranderproces. Hierbij hoort de valkuil dat de aangekondigde verandering weliswaar wordt toegejuicht, als de eigen afdeling maar buiten schot blijft. Daarom is het van groot belang dat iedereen, inclusief het hoger management, volledig op de hoogte is van de essentie van het agile gedachtegoed, de impact op de organisatie, en de eigen rol daarin open en eerlijk oppakt. Overigens kan de architect in dit proces een doorslaggevende rol spelen.

Watervrees

Ten slotte nog een bemoedigend bericht voor de wat traditionele manager of architect met watervrees. Het klinkt misschien paradoxaal, maar de agile werkwijze verschaft vaak meer inzicht in de actuele status en werkelijke voortgang in een project in vergelijking met de conventionele project tracking methodes. Juist door los te laten krijg je meer grip.

Categorie:   
Auteur(s)
afbeelding van erikphilippus
Erik Philippus
ImprovemenT BV - Eigenaar & Agile Project Coach

Erik Philippus heeft ruim 30 jaar ervaring in de technische automatisering, en biedt zijn klantenkring een combinatie van expertise op het gebied van software/systeem architectuur, kennis en ervaring bij het introduceren en uitrollen van de agile/lean werkwijze, en professionele coaching.

www.improvement-services.nl

www.agile-architecting.com

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.