del.icio.us	Digg
Furl	Netscape
Yahoo! My Web	Technorati
Google Bookmarks	Newsvine
BlinkList	reddit
Blogmarks	ma.gnolia
Tailrank	Windows Live
Linkedin

JFall 2009: How do I introduce Agile in my organization?

De meeste developers, testers en projectleiders zijn niet moeilijk te overtuigen van de verworvenheden van Agile. Maar de rest van de organisatie heeft aanmerkelijk meer koudwatervrees. Daaronder ook de managers, en al met al nou juist de mensen die je mee moet zien te krijgen wil je het ontwikkelproces blijvend kunnen veranderen.

Maar vrees niet, er is hoop. Als je het bovenstaande herkent, zit je precies in de doelgroep ("those who are stuck in a waterfall") van de JFall sessie van Erwin van der Koogh. Aan een nog ochtendfris publiek - eerste sessie na de opening keynote - onthulde hij 3 eenvoudige stappen om je uit deze misère te helpen, en into Agile nirvana.

Stap 1: "Lean a new language (Businessy)"
Als je de business wilt overtuigen, blijkt het absoluut essentieel dat je zonder met je ogen te knipperen volzinnen kunt voortbrengen als "By improving Business/IT Alignment, we can shorten our Time-to-Market and realize a significant increase in Return on Investment" (helaas geen woordelijke kopie van het juweeltje op de slide, maar de strekking moge duidelijk zijn). Voor ons techneuten is zo'n zin natuurlijk allereerst hilarisch, maar de business denkt, voelt en ademt in deze begrippen en je kunt dus beter zorgen dat je je Agile verhaal ermee kan vertellen.

Als we bovenstaande zin ontleden: "Time-to-Market" betekent meer inkomsten door sneller nieuwe functionaliteit in de markt te kunnen zetten. "Business/IT alignment" betekent kostenbesparing door een IT afdeling die kan luisteren naar de business, begrijpt hoe ze haar kan ondersteunen en geen "dat moeten ze helemaal niet willen" roept (ai, touché..). En "Return on Investment" is kort door de bocht die inkomsten min die kosten. Zonder het vooruitzicht op een vette Return waagt men zich niet aan een Investment. En dus zeker niet als je niet in staat bent uit te leggen hoe Agile practices (denk bijv. aan zeer frequente releases, veel en snelle feedback en focus op running software) zich verhouden tot deze begrippen.

Stap 2: "Start small and start big"
Je kunt niet een hele organisatie in 1 keer veranderen, maar je hebt uiteindelijk wel de hogere regionen nodig om die verandering te bewerkstelligen. Start binnen je eigen invloedscirkel. Begin bijvoorbeeld met het houden van daily standupmeetings. Boek daar (meetbare) resultaten mee. Vind hiertoe een metriek die mensen triggert, die buiten je initiele cirkel het bewustzijn over waar je mee bezig bent zal vergroten. Rinse and repeat. Betrek eerst de developers, dan testers, dan ontwerpers, dan de beheerders, etc, en werk als een soort olievlek door de organisatie. Schuw daarbij de inzet van middelen als gossip - netwerken, en niet per se 1 persoon direct proberen te overtuigen - en het zinvol gebruik van emoties niet. En hèlp organisatieonderdelen die nog niet met jouw aanpak om kunnen gaan. Script bijvoorbeeld eens de door jou, met je korte cycli, zeer frequent geworden deployments voor de vaak toch al zwaarbelaste beheerorganisatie.

Stap 3: "The magic formula of Action = Pain x Money"
Oftewel, de verandering die je teweeg kunt brengen is groter naarmate de pijn (bij de verantwoordelijken) groter is, en er meer geld beschikbaar is.

Pijn is groter naarmate een project verder achterloopt op schema, de deadline dreigt of het belang van het project groter is. En waar vind je het geld? Dat blijkt op veel plaatsen te zitten, voor wie er oog voor heeft. Op onbelangrijke projecten is men vaker bereid wat risico te nemen, wat je kunt aangrijpen om je Agile aanpak te bewijzen. Op grote projecten is het daarentegen makkelijker om tijd te krijgen, die je kunt gebruiken om te experimenteren of te leren. Daarnaast zijn er vaak process improvement budgetten, en wie een beetje creatief is kan vaak binnen zijn eigen budget ook nog wat schuiven om zo geld/tijd vrij te maken.

Een spijjker-op-zijn-kop-erlebnis had ik bij de term 'schijnzekerheid', die op meerdere punten in het verhaal opdook. Veel weerstand is hierop terug te leiden. Managers zien bijvoorbeeld graag grote up-front planningen van meerdere maanden of zelfs jaren, omdat dit een gevoel van zekerheid geeft over waar ze hun geld aan uitgeven. Dat gevoel is echter ongegrond omdat deze papieren kunstwerken vrijwel nooit overeenkomen met het echte verloop of eindproduct van het project. Met Agile weet je van tevoren minder vastomlijnd wat je aan het einde van de rit hebt, maar je hebt onderweg wèl voortdurend daadwerkelijke controle over wat dat wordt.

Een goede vraag uit de zaal ging over het moeilijk kunnen 'verkopen' van Agile, omdat dat het risico bij de opdrachtgever zou leggen terwijl fixed-price/date/functionality het risico bij de opdrachtnemer legt. Maar eigenlijk is dat ook weer een schijnzekerheid, want in beide gevallen ligt het risico bij de klant. Het niet op tijd hebben van de software die een bedrijf wel nodig had is vooral een klap voor dat bedrijf, hoe je het contract ook inricht. En Agile contracten vragen wellicht een andere benadering maar blijken in de praktijk zeker niet onmogelijk.

Hoewel er nog veel meer is besproken, hoop ik de belangrijkste punten er wel uit gevist te hebben. Ik vond het persoonlijk erg prettig dat de nadruk niet zozeer lag op waarom Agile een Good Thing^tm is, as that would be preaching to the choir ('the dark side' leek massaal te zijn weggebleven?), maar op het invoeren ervan in situaties die veel aanwezigen met mij zullen hebben herkend. Erwin vertelt duidelijk uit eigen praktijkervaring en kiest ook in zijn betoog voor sustainable pace, in plaats van je links en rechts om je oren te slaan met schreeuwende slides, cijfers en oneliners.

Erwin, als je dit leest: bedankt voor je inzichten en een erg goed verhaal. Ik heb er in ieder geval een aantal dingen uitgehaald waarvan ik stond te popelen om ze in de praktijk te proberen (hoe was het ook alweer? Oh ja, start small Jeroen, start small.. ;-)