AGILE

Lees hier meer over AGILE 

“Wat is agile? én Wat levert het u op?”
De laatste jaren is er een toenemende interesse voor agile projectmethoden. Vooral in de Angelsaksische landen zien we een stijgende populariteit van een agileaanpak.

Reageren op verandering
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 agileorganisaties, 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?

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.

Een agile project is als een wandeling door de woestijn: er is geen gedefinieerd pad vóór ons, alleen achter ons. We maken zelf de weg en alleen voor deze ene wandeling. We kunnen zien welk pad we gegaan zijn, maar niet hoe we onze weg zullen vervolgen. We leren van de manier waarop we de weg naar het doel hebben gemaakt, zodat we bij een volgende wandeling nog succesvoller kunnen zijn.

Aan de slag met een agile aanpak
Als uw interesse gewekt is, wilt u misschien meer weten. Of u wilt uw projecten meteen al meer agile gaan aanpakken en veranderingen niet meer als uitzonderingen behandelen. In verschillende trainingen, workshops en adviestrajecten, gaan we dieper in op de materie.