Agile lenigt de nood

006-Thumbnail Niagara Falls
In een ideale wereld is het uitvoeren van een software-ontwikkelingsproject een overzichtelijke bezigheid.
De opdrachtgever weet precies wat hij nodig heeft – of beter nog: wat hij over een jaar of twee nodig heeft. De leden van het uitvoerende team begrijpen wat er van hen verwacht wordt, voeren een analyse uit, maken een basisontwerp en een detailontwerp, bouwen en testen en leveren tenslotte op het afgesproken moment het gewenste product op. Alles onder controle en iedereen blij!
De werkzaamheden verlopen hoofdzakelijk lineair, want aan een volgende fase wordt pas begonnen als de voorgaande naar tevredenheid is afgerond.
Deze werkwijze staat bekend als de watervalmethode: het project loopt via een vaste fasering, voorspelbaar en snel, naar het eindpunt.
Ongeveer zo:
006-a - de ideale waterval
 
Niks meer aan doen, zou je zeggen, maar wat wil nu het geval?
Niet alle ICT-projecten worden een doorslaand succes.
Lange tijd is onduidelijk geweest hoe dat nu kon, maar na jaren van ontkenning, twijfel, onderzoek, hypotheses, falsificatie, nieuwe hypotheses en natuurlijk veel out-of-the-box-denken is de verklaring uiteindelijk gevonden: de wereld is niet ideaal.
(En het rare is, als je dat eenmaal weet ga je het op andere terreinen ineens ook zien.)
Daarmee lijkt die waterval niet langer symbool te staan voor snelheid, voorspelbaarheid en ander moois, maar eerder voor de daverende klap waarmee een en ander beneden aankomt – al dan niet bovenop een paar geniepig verscholen rotsblokken – en ook voor het gevoel dat je overvalt wanneer je in een dergelijk traject verzeild raakt: whoeaaAAAAAAAAAAH!
 
Want de opdrachtgever weet vaak helemaal niet zo precies wat hij hebben wil; nu al niet, laat staan over een jaar of twee. Wat kan er in de tussentijd niet allemaal gebeuren: onverwachte concurrentie, gewijzigde politieke prioriteiten, nieuwe technologische mogelijkheden, andere wet- en regelgeving, noem maar op.
Door al die ontwikkelingen gedurende het traject krijgt de opdrachtgever onvermijdelijk het door menig ICT-er zo gevreesde ‘voortschrijdend inzicht’:
006-b - voortschrijdend inzicht bij de opdrachtgever
En als er dan wel een keer een opdrachtgever is die in ruime mate over paranormale gaven beschikt, dan wordt zijn opdracht door het uitvoerende team weer niet helemaal begrepen:
006-c - afwijkende uitvoering
Vanwege de geringe mogelijkheden tot bijsturing leveren veel waterval-ICT-projecten uiteindelijk dan ook niet op waar het de opdrachtgever om te doen was of komen ze zelfs voortijdig krakend en piepend tot stilstand:
006-d - voortschrijdend inzicht en voortijdig projecteinde
Als starheid het probleem is, dan moet lenigheid wel het antwoord zijn.
En inderdaad: agile software-ontwikkeling!
 
Het concept Agile (lenig, behendig) staat beschreven in het Agile Manifest en in de bijbehorende principes.
Een aantal belangrijke kenmerken van dit concept:
 
Voortdurende opleveringen van waardevolle software
Een agile team levert niet één product aan het eind van het project, maar levert voortdurend waardevolle software op. Het team doet dat door achtereenvolgens korte deelprojecten (iteraties) uit te voeren, die elk een aantal weken duren en resulteren in een bruikbaar product.
Op die manier krijgt de opdrachtgever snel waar voor zijn geld en krijgt deze bovendien een steeds beter beeld van het product als geheel. Het is goed mogelijk dat hij daardoor enigszins van gedachten verandert, maar dat is geen probleem, want
 
Verandering wordt toegejuicht
Het voortschrijdende inzicht dat zo bedreigend kan zijn voor watervaltrajecten, wordt in agile projecten juist verwelkomd. Bij de start van iedere iteratie worden de doelen voor die periode vastgesteld; dat betekent dat iedere iteratie de mogelijkheid biedt om de plannen en de prioriteiten aan te passen aan de nieuwste inzichten.
 
Directe communicatie
Gedurende het gehele project werken de mensen in het ontwikkelteam dagelijks samen met mensen uit de business. De communicatie, zowel binnen het team als met de rest van de organisatie, verloopt bij voorkeur mondeling.
 
Zelfsturing
Het team bestaat uit gemotiveerde en deskundige mensen en is zelfsturend. Geen uitgebreide managementstructuren en andere overhead, maar focus op het inhoudelijke werk.
 
Hoge kwaliteit in combinatie met eenvoud
Er is veel aandacht voor technische kwaliteit en goed ontwerp. Daarnaast staat eenvoud hoog in het vaandel: alleen datgene wat werkelijk nodig is, wordt ontwikkeld.
 
Continue verbetering
De eigen werkprocessen worden voortdurend verbeterd; het werken in iteraties biedt daar ook volop mogelijkheden toe. Op gezette tijden kijkt het team wat er is geleerd en past het de werkprocessen daarop aan.
 
En dan ziet een software-ontwikkelingstraject er ineens zo uit:
006-e - agile software-ontwikkeling
Wat wil een mens nog meer…
 
Maar als het Agile Manifest al is opgesteld in 2001 en als diverse agile ontwikkelmethoden als Scrum, Extreme Programming en DSDM zelfs nog ouder zijn dan dat, waarom behoort de watervalmethode dan nog niet voorgoed tot het verleden?
Tja… zoals zoveel dingen in het leven is ook agile gaan werken moeilijker dan het lijkt, onder andere omdat het niet alleen het ontwikkelteam raakt, maar ook de rest van de organisatie. Gelukkig is de implementatie van een agile werkwijze een klus die zelf ook agile kan worden aangepakt.
 
De moeite die het kost, is het in ieder geval zeker waard; een organisatie die agile werkt, is beter in staat om met interne en externe veranderingen om te gaan en om bedreigingen in kansen om te buigen.
Als ‘lenig’ tenminste niet wordt verward met ‘zo de wind waait, waait mijn jasje’.
Doelen en richtingen, ook al zijn ze misschien globaal, blijven altijd nodig.
Anders wordt het, alle lenigheid ten spijt, uiteindelijk toch dit:
006-f - weer niks
 
 
006-Niagara Falls
Watervallen bewaren we maar voor de vakantie

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>