Het is een set van eenvoudige projectregels/activiteiten (best-practices) zodanig dat tijdens het productontwikkelproces flexibel en proactief gereageerd kan worden op veranderingen.
Het ontwikkelproces wordt meer beschouwd als een creatiefproces waarbij de mens centraal staat dan een technocratisch-proces.
Wat maakt een project dan Agile?
Hier onder volgt wat meer verdieping rondom de historie en betekenis van Agile.
De letterlijke vertaling van de engelse term agile is vlug en lenig, behendig, flexibel, maar als we spreken over projecten of over softwareontwikkeling kunnen we deze vertalingen niet gebruiken. "Behendige software ontwikkeling" of "Flexibel Project Management" hebben niet dezelfde gevoelswaarde. Vandaar dat we voorlopig de term agile hanteren.
Laat ik beginnen met een (vertaald) citaat van Jim Highsmith, een van de grondleggers van de agile beweging:
"De toekomst van onze informatietijdperkeconomie behoort toe aan de agile organisaties, degene die verandering kunnen creëren voor hun concurrenten en misschien zelfs een beetje chaos. Als je beter en sneller kunt innoveren, creëer je verandering voor je concurrenten. Als je snel kunt reageren op initiatieven van de concurrentie, op nieuwe technologie en op eisen en wensen van je klanten, creëer je verandering voor je concurrenten. Als je langzamer bent, minder innovatief en minder snel kunt reageren, dan ben je aangewezen op overlevingstrategieën in een zee van chaos die door anderen is veroorzaakt. Gaat uw bedrijf het tempo van de veranderingen aangeven, of gaan uw concurrenten dat doen? In een wereld van voortdurende verandering zijn traditionele, inflexibele methoden voor projectmatige softwareontwikkeling niet meer toereikend voor succes."
Dit citaat gaat over een van de belangrijke aspecten van een agile aanpak, namelijk reageren op verandering. Een agile aanpak probeert niet om verandering buiten het project te houden, maar vráágt om verandering omdat verandering meestal ook verbetering van kwaliteit betekent. En kwaliteit is tenslotte niet wat de opdrachtgever nodig heeft aan het begin van het project, maar aan het eind. Door rekening te houden met de onvermijdelijke veranderingen in de omgeving van de organisatie en in de eisen en wensen van de opdrachtgever, verhogen we de kwaliteit van de op te leveren producten.
Wat is écht belangrijk in een project?
In 2001 kwam een aantal professionals uit de softwareontwikkeling samen in Utah in de VS om te zoeken naar gemeenschappelijke waarden. Diverse ontwikkelmethoden waren vertegenwoordigd, zoals DSDM, eXtreme Programming (XP) en Scrum. Het resultaat was het Agile Software Development Manifesto. Omdat de ondertekenaars allemaal uit de software-industrie kwamen, gaat het manifest over softwareontwikkeling. Een agile aanpak is echter niet alleen maar geschikt voor IT projecten. In dit artikel is het woord 'software' dan ook vervangen door 'product’, in het bijzonder in de vertaling van het manifesto en de principes. Daardoor is de aansluiting met niet-IT projecten goed te maken. De inhoud van het manifesto was:
We ontdekken betere manieren om producten te ontwikkelen
in de praktijk en door anderen daarbij te helpen.
Door dit werk hebben we geleerd meer waarde te hechten aan
Individuen en interactie dan aan processen en hulpmiddelen
Werkende producten dan aan uitgebreide documentatie
Samenwerking met de klant dan aan contractonderhandelingen
Reageren op verandering dan aan het strikt volgen van een plan
Dat wil zeggen: de zaken aan de rechterkant zijn zeker belangrijk,
maar we hechten meer waarde aan de zaken aan de linkerkant.
Dit manifest is de grondslag voor de agile beweging. Het geeft aan dat we prioriteiten moeten stellen tijdens ons werk in projecten en dat we geneigd zijn die prioriteiten verkeerd te leggen. Verhogen we de (schriftelijke) rapportagefrequentie als we niet goed meer weten wat er in het project gebeurt? Of gaan we praten met de teamleden? Pinnen we onze leverancier vast en kleden we hem uit voordat we gaan samenwerken? Of richten we ons op een goede relatie met de leverancier binnen een wat ruimer contractueel kader? Eisen we van de gebruiker dat zij vooraf precies kan aangeven wat ze wil en dat dit ook niet meer verandert? Of realiseren we ons dat ze pas weet wat ze wil als ze ziet wat ze krijgt?
Samen zo weinig mogelijk doen
Na de publicatie van het Agile Manifesto werkten de opstellers verder aan de Agile Principes. Hieronder een korte uitleg van deze twaalf uitgangspunten.
1. De hoogste prioriteit is de klant te bedienen door het vroegtijdig en frequent opleveren van bruikbare producten.
Uit onderzoek blijkt dat er een verband is tussen uiteindelijke kwaliteit en het vroegtijdig opleveren van gedeeltelijk functionerende systemen. Hoe minder functioneel de eerste oplevering, hoe hoger de kwaliteit van het uiteindelijke product. Een ander verband werd gevonden tussen kwaliteit en het frequent opleveren van groeiende functionaliteit. Hoe vaker er opgeleverd werd, hoe hoger de uiteindelijke kwaliteit.
2. Werkende producten frequent opleveren, liefst in een paar weken, hooguit in een paar maanden.
Dit principe sluit aan op het voorgaande. Een agile proces levert werkende producten op, en geen pakken documentatie en plannen.
3.Werkende producten is de belangrijkste maat voor vooruitgang.
Vooruitgang wordt gemeten aan het deel van de gevraagde functionaliteit dat werkt. De fase waarin het project verkeert of de hoeveelheid plannen of documenten zijn dus geen maat.
4. Sta open voor veranderende eisen, zelfs laat tijdens de bouw. Agile processen benutten verandering en leveren zo een concurrentievoordeel voor de business.
Deelnemers aan een agile project zijn niet bang voor verandering. Ze doen er alles aan om zo flexibel mogelijk te blijven, zodat wijzigingen kunnen worden aangebracht met zo weinig mogelijk inspanning. Zo in kunnen spelen op veranderingen verhoogt de kwaliteit van het uiteindelijke product.
5. Vertegenwoordigers van de business en ontwikkelaars werken dagelijks samen gedurende het gehele project.
In een agile project ligt de nadruk op de communicatie tussen alle betrokkenen. Deze communicatie is zo veel mogelijk face-to-face. 'Dagelijks' betekent overigens niet 'heel de dag'.
6. Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en de ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
De belangrijkste factor voor succes in een agile project vormen de mensen. Alle andere factoren passen zich aan als dat nodig is. Als een proces bijvoorbeeld een belemmering vormt voor het team, wordt het proces aangepast, niet het team.
7. De meest efficiënte en effectieve manier om informatie te delen in een ontwikkelteam is via praten met elkaar.
In een agile project praten de mensen met elkaar. Plannen, ontwerpen en specificaties kunnen worden gemaakt als daar behoefte aan is, maar de standaard is conversatie.
8. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
Een agile team is een zelfsturend team. Alle teamleden werken aan alle aspecten van het project en zijn dus ook allemaal verantwoordelijk voor alle aspecten. Er is dus niet één teamlid verantwoordelijk voor de architectuur of voor het testen.
9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.
Door constant kwaliteit te leveren blijft de snelheid in een project hoog. De producten moeten zo clean en robuust mogelijk blijven. Opschonen van software bijvoorbeeld wordt niet uitgesteld 'tot er meer tijd is'. Dat is alleen schijnbare tijdwinst.
10. Agile processen maken doorgaande ontwikkeling mogelijk. Opdrachtgever, ontwikkelaars en gebruikers moeten een constant tempo eindeloos kunnen volhouden.
Een agile project is geen sprint, maar een marathon. Alleen dan is de snelheid ook vast te houden tot het einde van het project. En kan een volgend project weer rekenen op een snelle start. In een agile project wordt dus ook niet overgewerkt.
11. Eenvoud – de kunst van het maximaliseren van het werk dat niet gedaan wordt – is essentieel.
Een agile team kiest altijd voor de eenvoudigste weg om haar doel te bereiken, het doel zoals dat nú bekend is. Het houdt geen rekening met eventuele toekomstige problemen of uitdagingen, maar houdt de oplossing wel flexibel voor die toekomst.
12.Regelmatig onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.
In een agile project is veel aandacht voor leren. Het team evalueert haar functioneren in de veranderende omgeving voortdurend en past regels, afspraken en organisatie aan om effectief en agile te blijven.
Het pad ligt achter ons
Als een agile team zelfsturend is, is er dan geen projectmanagement meer nodig? Zeker wel! Ook de agile processen waar een agile project gebruik van maakt, kunnen niet zonder projectmanagement. Maar het is wel een ander soort management.
Bij veel projecten kan de projectmanager niet voorspellen hoe de wensen en eisen zullen veranderen, welke technische kwesties zich zullen voordoen, hoe de omgeving zal veranderen, enzovoort. Hier kunnen we geen gebruik maken van de klassieke voorspellende methoden die gebaseerd zijn op gedefinieerde processen, het tegengaan van verandering en kennis van de werking van die processen in eerdere projecten. We hebben empirische management methoden nodig, dat wil zeggen methoden die we steeds kunnen aanpassen en waarmee we ons steeds kunnen aanpassen aan de veranderingen die we op de projectweg tegenkomen.
Ken Schwaber, de grondlegger van de agile methode Scrum, heeft eens een aantal traditionele software ontwikkelmethoden voorgelegd aan experts in de proces-controle-theorie bij Dupont. Hij beschrijft het verschil in gebruik van afgebakende managementmethoden ('defined') en empirische managementmethoden ('empirical') aan de hand van hun reacties. De experts zagen meteen de mismatch tussen de realiteit van software ontwikkeling en de traditionele methoden. Geen van de processen en taken in softwareontwikkeling ligt voldoende vast om het afgebakende model te gebruiken. In dit licht wordt ook duidelijk waarom zaken als "softwarefabriek" of "ontwikkelstraat" gedoemd zijn te mislukken. Zij beschouwen softwareontwikkeling als een afgebakend proces. Het empirische model echter verwacht het onverwachte en geeft controle door het steeds monitoren en aanpassen van de processen, die niet volledig vastgelegd zijn en ook onvoorspelbare en niet-herhaalbare output opleveren.
Het gaat er niet om, een waardeoordeel te hechten aan een van beide. In stabiele, niet veranderlijke omgevingen kunnen we een afgebakende methode goed gebruiken, samen met een klassieke vorm van projectmanagement. De vraag is wel waar we dit soort omgevingen nog tegenkomen.
Het zal ook duidelijk zijn dat de empirische methoden die we nodig hebben in een veranderlijke omgeving ook een ander projectmanagement nodig hebben. Hier is de projectmanager gericht op het samenstellen van het team, het goed in beeld houden van het projectdoel, omgaan met onzekerheden, authentiek communiceren, faciliteren, stimuleren, vertrouwen opbouwen met en tussen alle betrokkenen en het afschermen van het team, zodat het zijn werk kan doen.
We kennen allemaal wel voorbeelden van de projectmanager die het grootste deel van zijn tijd bezig is met het aanpassen van de gedetailleerde planningen, na de zoveelste verandering in het project. Met de uitgebreide change control procedures en het veelvuldig rapporteren over de afwijkingen. Samen met de urenverantwoording en de controle daarop blijft er weinig tijd over voor de belangrijker taken van de projectmanager, waardoor het team haar focus verliest en het project in gevaar komt. Daar reageert het (project)management dan vaak weer op met méér controle, méér procedures en méér rapportage, terwijl het gaat om de mensen in en rond het project. Er komt meer aandacht voor de documentatie, terwijl het opleveren van werkende producten op de achtergrond raakt. Er wordt opnieuw en scherper onderhandelt over de contracten, waardoor er nog minder wordt samengewerkt. En we gaan ons nog strakker aan de planning houden, waardoor we niet meer met veranderingen kunnen omgaan.