‘Onze ontwikkelprocessen moeten geleide projectielen zijn’

Ontwikkelteams die de Agile-benadering volgen, hebben geen plan aan de muur hangen dat ze blind najagen, aldus goeroe Mike Cohn. Ze proberen een goede balans te vinden tussen anticiperen op verwachte veranderingen en aanpassen aan onvoorziene ontwikkelingen. In korte iteraties bouwen ze telkens werkende software die ze aan hun opdrachtgevers kunnen laten zien, want ’klanten zijn bewegende doelen‘. Op uitnodiging van Topic verzorgde Cohn onlangs een avondvullend programma.

’In het begin had Agile een slechte naam. We zouden niet aan documentatie doen, we zouden niet plannen. Flauwekul. Dat doen we wel. Teams die zeggen dat ze agile zijn en daarom niet documenteren en niet plannen, die zijn helemaal niet agile, die zijn gewoon lui. Agile is niet gemakkelijk. De overgang is zwaar. Het is een culturele verandering, die indruist tegen alles wat we onze ontwikkelaars de afgelopen twintig, dertig jaar hebben geleerd. Agile pakt alle problemen in je organisatie en slaat je ermee om je oren.‘

Eind vorig jaar was Agile-goeroe Mike Cohn in Nederland om een lezing te geven over deze lichtgewicht manier van software ontwikkelen. ’Eind jaren negentig werkte ik voor een onderneming die twee of drie bedrijven per jaar opkocht. Een deel van mijn taak was om de ingelijfde engineeringgroepen te helpen bij de overstap naar Agile. Het viel me op dat ze allemaal vol waren van het Capability Maturity Model en het Rational Unified Process en allemaal van die fantastische requirementsdocumenten en geweldige prototypes hadden, en ik begon me af te vragen of wij daar ook niet aan moesten. Daar hield ik snel mee op toen ik me ervan bewust werd dat wij degenen waren die hen kochten, en niet andersom.‘

Inspelen

Maar wat betekent het nu precies om agile te zijn? Een goed uitgangspunt vormt volgens Cohn het Agile Manifest, in 2001 opgesteld om tegenwicht te bieden aan de oprukkende heavy processen. In vier zogeheten value statements noemt dit handboek telkens twee eigenschappen, waarvan de een waardevoller is dan de andere. ’Het individu is voor ons bijvoorbeeld belangrijker dan het proces. We moeten ervoor zorgen dat we onze teams met goede mensen bestaffen en er alles aan doen om ze goed samen te laten werken. Alleen dan krijgen we goede software. Goede software wordt niet geschreven door een of andere omgeving die we kopen, een of ander ontwikkelgereedschap. Processen en tools helpen, maar zijn niet het belangrijkst. We moeten focussen op de individuele interacties.‘

Werkende software is waardevoller dan uitgebreide documentatie, aldus het tweede value statement. ’Hoeveel bedrijven ik niet tegenkom die zeggen dat ze halverwege een project zijn als ze de analyse en het ontwerp achter de rug hebben en alleen nog maar hoeven te programmeren en te testen. Ze hebben immers twee van de vier stappen gedaan. Fout. Je bent pas halverwege als de helft van de features helemaal werkt. Daarom focust Agile sterk op werkende software. In zeer korte iteraties, van twee of vier weken, produceren we iets dat af is en het doet, dat we aan de opdrachtgever kunnen laten zien. Van het zoveelste document worden klanten of eindgebruikers niet warm, wel van werkende features.‘

’Voordeel van deze aanpak is dat we geen last hebben van het 90-procentsyndroom, waarbij we gedurende 90 procent van de projectdoorlooptijd zeggen dat we 90 procent klaar zijn. Je zult agile ontwikkelaars nooit tegen een deadline aan zien lopen en tegen hun baas horen zeggen dat ze ineens zes maanden meer nodig hebben. De korte iteraties maken het mogelijk om eventuele uitloop al in een vroeg stadium te constateren en de planning daarop aan te passen.‘

Samenwerken boven onderhandelen. ’We streven naar een relatie tussen ontwikkelteam en klant die is gebaseerd op samenwerking, niet op onderhandeling. Natuurlijk moeten er wel zaken op papier komen, maar we kennen allemaal de handenbinders van contracten die ieder detail uitspellen. Wij verkiezen overeenkomsten waarin beide partijen verklaren dat ze samen aan de slag gaan, waarin wij aangeven dat we zullen proberen om het juiste product te bouwen. We willen het gevoel hebben dat we samenwerken, niet dat we alles tot in de puntjes hebben vastgelegd in een contract.‘

Het laatste value statement zegt dat reageren op verandering waardevoller is dan een plan volgen. ’Ik houd van plannen. Ik heb er zelfs een boek over geschreven. In mijn optiek is het maken van een planning cruciaal voor het welslagen van projecten, agile of niet. Maar we kunnen van tevoren niet exact weten hoe een project zal verlopen. Vaak weten we niet eens precies wat we gaan bouwen. Eenmaal aan de slag blijken we toch net iets anders te maken dan we voor ogen hadden. Of het duurt langer dan gedacht. Of er is nieuwe technologie. Op die veranderingen moeten we inspelen. Een Agile-team hangt geen plan aan de muur ervan uitgaande dat het perfect is en niet meer wijzigt. In plaats daarvan omarmen we de veranderingen met als doel om daar zo goed in te worden, er zo snel op te reageren, dat we zelf veranderingen veroorzaken in de industrie.‘

Mike Cohn: ‘Agile is een culturele verandering, die indruist tegen alles wat we onze ontwikkelaars in de afgelopen twintig, dertig jaar hebben geleerd.’

Balans

Het Agile Project Leadership Network (APLN) heeft onlangs vastgelegd waar projectleiders op moeten letten bij lichtgewicht ontwikkeling. ’Er wordt vaak gezegd dat Agile-managers alleen maar pizza‘s halen. Dat fabeltje willen we uit de wereld helpen met de statements van APLN. Een projectleider moet de return on investment verhogen door een continue stroom van waarde te genereren in plaats van op het eind de hele investering in één klap proberen terug te verdienen. Je weet nooit wanneer een project wordt afgeblazen of een andere richting uitgaat.‘

’Een manager dient ook betrouwbare resultaten af te leveren door klanten te betrekken bij de ontwikkeling. Te veel projecten zijn verkeerd gelopen omdat de bouwers en de gebruikers van de software niet met elkaar praatten. Een Agile-team laat aan het eind van elke iteratie zien wat het heeft gemaakt, al was het maar aan collega‘s die voor klant spelen. De feedback gebruikt het vervolgens om het product aan te passen. Klanten weten van tevoren ook niet precies wat ze willen. Het zijn bewegende doelen. Dan moeten we geen raketten gaan bouwen die op een voorgeprogrammeerde plek inslaan. Onze ontwikkelprocessen moeten geleide projectielen zijn.‘

Rekening houden met onzekerheid en deze beheersbaar houden middels iteraties, anticipatie en adaptatie is een andere taak voor de Agile-projectleider. ’We weten dat we niet alles kunnen weten over het product. Daarom willen we anticiperen op de verwachte veranderingen en ons aanpassen aan de onvoorziene ontwikkelingen. Traditionele projecten proberen op alles vooruit te lopen; bij Agile is er een balans tussen anticipatie en adaptatie, die voor ieder bedrijf anders is.‘

Verder dienen managers creativiteit en innovatie te stimuleren door hun mensen de ruimte te geven om zich te kunnen ontplooien. ’Ze moeten inzien dat individuen de bron zijn van goede producten en hen loslaten met hun ideeën zodat ze met die goede producten kunnen komen.‘ Tegelijkertijd moet er een groepsverantwoordelijkheid zijn. Dat zal de prestaties van het team verbeteren, aldus Cohn. ’In plaats van ieder individu aan te spreken op zijn specifieke gebiedje willen we hele groepen verantwoordelijk houden. Het team dat software schrijft, is aansprakelijk voor de software en het team dat het totale product bouwt, is daarvoor verantwoordelijk.‘

Sprint

Van alle processen waarvan een Agile-team zich kan bedienen, is Scrum de oudste. De naam is ontleend aan een situatie in het rugby waarbij de sporters letterlijk de koppen bij elkaar steken om de bal terug in het spel te brengen. ’Elke dag komen de leden van een Scrum-team samen om door te spreken hoe ze ervóór staan. Geen grote statusrapporten voor het management, maar gewoon van programmeur tot programmeur of van programmeur tot tester even bespreken hoe het gaat, of we op schema liggen, wat de struikelblokken zijn, waar we elkaar mee kunnen helpen. Deze dagelijkse Scrum-bijeenkomsten mogen niet langer duren dan een kwartier. Een team dat ik ken in San Diego heeft de regel dat de Scrummaster, de projectleider, vijf dollar in een pot moet stoppen als de meeting daar overheen gaan. Aan het eind van het project gebruiken ze dat als biergeld.‘

’Een ander onderdeel is de product backlog, een geprioriteerde lijst met alle requirements. Elke sprint, zoals een iteratie bij Scrum heet, werkt het team aan de acht belangrijkste, de sprint backlog. Aan het eind van de omloop, standaard na twee tot vier weken, komen we uit met een productincrement die in potentie shippable is. Niet dat iemand het zou willen kopen, want twee of vier weken is waarschijnlijk te kort om zoveel toegevoegde waarde te genereren dat die een nieuw product rechtvaardigt. Het kan ook zijn dat er geen coherent geheel staat, maar het deel dat we hebben, werkt, is van hoge kwaliteit, stabiel en goed.‘

’Kenmerkend voor Scrum is dat het zeer sterk gericht is op zelforganiserende teams, die alles zelf uitzoeken. Daarnaast proberen we generatieve regels op te stellen, regels die het gewenste teamgedrag uitlokken. Zo zeggen we bijvoorbeeld dat de groepen aan het eind van iedere iteratie werkende software moeten hebben, of dat ze elke dag vijftien minuten bijeen moeten komen. Geen achthonderd pagina‘s, maar een paar van dat soort algemene voorschriften. Belangrijk is ook dat Scrum een managementframework is. Geen activiteitenlijst, maar een manier om projecten te leiden. Een laatste kenmerk is schaalbaarheid. Grotere organisaties kunnen de dagelijkse bijeenkomsten bijvoorbeeld uitbreiden met twee meetings per week waar alle teams één persoon naar uitvaardigen om hun problemen op een hoger niveau te bespreken.‘

Vrijheid

Het mooie aan Scrum vindt Cohn dat het geen engineeringpraktijken voorschrijft. Dit in tegenstelling tot bijvoorbeeld Extreme Programming (XP), dat ervan is afgeleid. ’Zoals de naam al aangeeft, is XP het meest extreme Agile-proces. Een heel arsenaal aan verplichte onderdelen, waaronder pair programming, continue integratie en testgedreven ontwikkeling, moet ervoor zorgen dat je code schrijft van hoge kwaliteit. Bij Scrum kun je die dingen ook doen, maar het hoeft niet. Daar beslissen teams zelf wat voor hen de beste manier is om software te bouwen.‘

’Extreme Programming is een verzameling van good practices. Het idee erachter is dat als een beetje goed is, een heleboel nog beter is. Code-inspectie is waardevol, dus waarom doen we het niet de hele tijd? Dat is pair programming: ik ga jouw code niet elke driehonderd regels controleren, maar ik kijk en typ gewoon over je schouder mee. Veel van de XP-praktijken blijken het best goed te doen, maar een aantal staan ter discussie. Het is een kwestie van uitproberen en kijken wat voor jou het beste werkt.‘

Een ander Agile-proces is featuregedreven ontwikkeling. ’Een feature is een korte beschrijving van een actie die waardevol is voor de gebruiker van het systeem, bijvoorbeeld ’Bereken de totale kosten van een order‘. Bij feature-driven development maken we van tevoren een – eventueel objectgeoriënteerd – overall model, schrijven we alle features op, berekenen we voor elk de kosten en komen we op basis daarvan met een plan. Vervolgens realiseren we ze een voor een in korte iteraties: design by feature, build by feature.‘

’Door meerdere features samen te voegen in feature sets en die op hun beurt weer te combineren in major feature sets ontstaat een schaalbare aanpak. Elke grotere groep wordt toegewezen aan een of meerdere chief programmers, die daar dan verantwoordelijk voor is dan wel zijn. Dat class ownership of module ownership maakt featuregedreven ontwikkeling zo uniek in de Agile-wereld. Bij Scrum en XP mag iedereen alle code aanpassen en voor veel teams werkt dat goed. In sommige projecten is het echter cruciaal dat iemand de eigenaar is van een module, dat diegene de enige is die daar toegang toe heeft. Dat kan met feature-driven development. Het proces komt uit de UML-hoek en vormt dan ook een goed uitgangspunt voor bedrijven die veel modelleren in UML.‘

Of Agile geschikt is voor een organisatie, hangt er volgens Cohn vooral van af of leidinggevenden kunnen omgaan met de vrijheden die de aanpak met zich meebrengt. ’Bij de meeste Agile-processen draait het om team empowerment, om de bereidheid het team zijn eigen gang te laten gaan. Kunnen de managers die vrijheid aan? Hebben de teams er wel de discipline voor? Agile groepen zijn de meest gedisciplineerde ter wereld. Het zijn geen teams die alleen maar lui willen zijn, alleen de leuke onderdelen willen en niet de moeilijke. Agile is niet gemakkelijk. Als je een cyclus die voorheen twaalf maanden duurde, comprimeert tot twee weken, dan steken alle problemen die je eerst één keer per jaar tegenkwam nu elke veertien dagen de kop op. Je krijgt alles recht in je gezicht. Releasemanagers die daar niet mee om kunnen gaan, zullen dat moeten leren of hun biezen moeten pakken.‘