In dit artikel worden de Agile fundamenten toegelicht en kan jij bepalen of jij Agile bent.
We horen de laatste tijd steeds meer over een Agile projectaanpak. Wat is dit? Is Agile een project management methodiek zoals Prince2 of moeten we ons hier toch iets anders bij voorstellen? Dit artikel geeft je meer achtergrond over wat Agile inhoudt en wat dit betekent voor jouw project.
Het Engelse woord Agile betekent behendig, lenig. De Agile projectaanpak is dan ook een aanpak waarin behendigheid in de aanpak voorop staat. Een Agile projectaanpak gaat ervan uit dat de wereld tijdens het project verandert en probeert deze veranderingen zo goed mogelijk te faciliteren zonder daarbij het projectresultaat uit het oog te verliezen.
Het eindproduct bij een Agile project staat vooraf niet volledig vast maar past zich gedurende de periode van de projectuitvoering aan aan de eventueel veranderende omstandigheden of wensen van de klant. Ten opzichte van een traditionele projectaanpak onderscheidt Agile zich door veranderingen tijdens het project te omarmen in plaats van deze zoveel mogelijk te vermijden. In een traditionele projectaanpak probeert men veranderingen (changes) tegen te gaan door enerzijds de specificaties in detail vast te leggen en anderzijds een heel formeel change management proces in te richten om daarmee veranderingen te ontmoedigen.
De Agile aanpak komt voort uit IT gerichte projecten met software ontwikkeling maar de principes kunnen ook zeer goed gebruikt worden in andersoortige projecten.
Agile kenmerken
Een Agile project heeft een aantal specifieke kenmerken. Het helpt om deze te beschrijven en te communiceren maar dit is niet genoeg want mensen die eenmaal te maken hebben gehad met een Agile aanpak kijken hier toch anders tegenaan dan mensen die hier nog weinig tot niet mee te maken hebben gehad. Het is een gevoel, een manier van werken, een bepaalde kijk op projecten. Je hebt daarom bij Agile projecten een bepaald type mensen nodig, mensen die uit zichzelf minder geneigd zijn naar zekerheden te zoeken en bereid zijn ergens aan te beginnen zonder dat vast staat wat het eindresultaat zal zijn. Ditzelfde geldt natuurlijk ook voor organisaties die de Agile aanpak willen hanteren. Ervaring met Agile projecten is dus van wezenlijk belang om succesvol te kunnen zijn.
Waar Prince2 zich vooral richt op de sturing van projecten richt Agile zich op het creatie proces van de producten die binnen het project worden opgeleverd. Agile is ook geen specifieke methodiek zoals Prince2 maar meer een verzameling van principes / methodieken die binnen het project gebruikt wordt om de op te leveren producten zo goed mogelijk te laten aansluiten bij de wensen en eisen van de klant. Er bestaan diverse methodieken die allen binnen hetAgile spectrum vallen. Iedere methode heeft zo zijn eigen specifieke kenmerken. De bekenste zijn: Scrum, DSDM, (R)UP, Extreme programming (XP). De methodes kenmerken zich echter allemaal wel door uit te gaan van dezelfde basisprincipes. Deze basisprincipes zijn vastgelegd in het zogenaamd ‘Agile manifesto’.
Dit zijn:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile principes
- Individuals and interactions over processes and tools:
De traditionele systeemontwikkeling is veelal gebaseerd op een zeer strakke procesinrichting waarbij ook het gebruik van de tools zeer voorschrijvend is voor de uitvoering van het project. Gevolg is dat het eindresultaat vaak niet aansluit bij het bedrijfsproces en er het bekende gat tussen business en IT ontstaat. Agile gaat ervan uit dat als je de individuen bij elkaar zet in een project en de juiste interactie tussen deze individuen faciliteert, het eindproduct beter aansluit bij de primaire bedrijfsprocessen.
Om de interactie tussen de teamleden te bevorderen is het uitgangspunt bij een Agile project dat het gehele team op 1 projectlocatie zit bij voorkeur in 1 ruimte. Deze ruimte heeft voldoende faciliteiten (whiteboards e.d.) om met elkaar te communiceren maar biedt ook de mogelijkheid om geconcentreerd te werken. Persoonlijk prefereer ik een grote projectruimte met veel wanden met whiteboards of brown papers met stick-it velletjes daarop, bureaus in het midden en één of twee aangrenzende kamers van men zich kan afzonderen indien men even geconcentreerd wil werken en niet afgeleid wil worden. Gebruikers en IT’ers zitten samen in de projectruimte waardoor ruime gelegenheid ontstaat voor informele communicatie.
- Working software over comprehensive documentation.
Traditionele, waterval, methodieken als SDM gaan uit van een software ontwikkelingsproces waarbij eerst alles uitgebreid in functionele specificaties wordt vastgelegd en daarna wordt geprogrammeerd. De beoordeling van te ontwikkelen functionaliteit gebeurt dus op basis van de functionele specificaties. Bij het testen van de systemen blijkt vervolgens vaak dat de software toch niet of slecht aansluit bij het primaire bedrijfsproces. Agile gaat er daarom vanuit de werkende software die goed aansluit bij het bedrijfsproces belangrijker is dan uitputtende documentatie. Dit neemt niet weg dat software alleen goed kan blijven werken als er voldoende documentatie opgeleverd wordt om de software onderhoudbaar te houden. Een Agile projectaanpak mag dus nooit een alibi zijn om geen of te weinig documentatie op te leveren. Agile gaat er echter wel vanuit dat de software iteratief wordt ontwikkeld en dat de functionaliteit wordt beoordeeld aan de hand van prototypes en niet op grond van uitputtende documentatie.
- Customer collaboration over contract negotiation.
Veel projecten, met name IT projecten kenmerken zich door een groot gat tussen opdrachtgever en opdrachtnemer. Onderzoek heeft aangetoond dat veel klanten vinden dat IT projecten geen ‘value for money’ hebben opgeleverd. Als reactie hierop werden afspraken aangescherpt en werd alles nog strakker onderhandeld en vastgelegd in contracten. Het resultaat bleef echter nog steeds onbevredigend. Agile projecten zijn gebaseerd op een goede interactie tussen organisatie en projectteam. Een juiste samenwerking leidt tot het best mogelijke eindproduct onafhankelijk van wat er contractueel is vastgelegd. Als beide partijen tevreden zijn over het eindproduct dan zijn over het algemeen de onderhandelingen over contracten niet meer zo moeilijk. Natuurlijk moeten er vooraf afspraken worden gemaakt over de uitvoering van het project. Het gedetailleerd vastleggen van het eindproduct biedt echter slechts een financiële (schijn)zekerheid maar leidt er zelden toe dat het eindproduct ook daadwerkelijk van betere kwaliteit is.
- Responding to change over following a plan.
Tijdens een project veranderen dingen in de omgeving. Tevens kunnen tijdens het iteratief ontwikkelen van producten de inzichten van de organisatie veranderen waardoorzogenaamde change requests ontstaan tijdens het project. Door niet alles vooraf zeer gedetailleerd vast te leggen in uitputtende documentatie faciliteert een Agile project in feite de mogelijkheid tot veranderen. Deze veranderingen worden binnen het projectteam opgepakt mits dit binnen de vooraf afgesproken kaders blijft. Agile projecten gaat uit van het principe van timeboxen, dat wil zeggen dat er vooraf een tijdspanne en een budget wordt afgesproken waarbinnen het project moet worden uitgevoerd. Binnen deze kaders is het projectteam vrij om veranderingen door te voeren. Dit betekent dus automatisch wel dat als het projectteam extra wensen gerealiseerd wil zien men zelf moet zoeken naar ruimte in de bestaande scope. Treedt men buiten deze kaders dan zal de opdrachtgever eerst zijn goedkeuring moeten geven voor een overschrijding van tijd of geld. Om dit proces zo goed mogelijk te faciliteren wordt in Agile projecten de gewenste functionaliteit geprioriteerd. Indien er tijdens het project andere inzichten ontstaan kan er functionaliteit geschrapt worden die niet tot de must have categorie behoort waardoor het project toch binnen de kaders van de vooraf afgesproken tijd en geld een acceptabel product oplevert.
Het principe responding to change over following a plan betekent ook dat niet vastgehouden wordt aan de planning als gebleken is dat deze niet haalbaar is. Hoe vaak hoor ik wel niet dat men achter ligt op planning maar dat dit nog wel ingehaald wordt? In de meeste gevallen werkt dit niet. Als men in het eerste gedeelte is uitgelopen dat is de uitloop in het tweede gedeelte meestal net zo groot of groter. In Agile projecten worden daarom de planningen aangepast aan de ervaringen die met tot dan toe heeft opgedaan. Men noemt dit ook wel evolutionair plannen.
De mensen in een Agile project
Agile ontwikkelingen vergen een bepaalde mentaliteit in het team. Lang niet iedereen is geschikt om mee te draaien in een Agile team. Agile mensen zijn als het ware snelschakers. Ze kunnen intuïtief beslissingen nemen en durven ergens voor te gaan. Mensen die dit niet kunnen en graag zaken goed overdenken voor ze een beslissing nemen voelen zich vaak niet op hun gemak in een Agile team. Bij de meeste organisaties is het echter zo dat de teamleden niet geselecteerd worden op hun gedrag maar meestal op basis van beschikbaarheid en kennis.
Dit betekent dat in de praktijk nogal eens voorkomt dat het management beslist dat iets op tijd af moet zijn, daarmee voorstander is van een Agile aanpak waarbij de oplevering volgens het timebox principe gemanaged wordt terwijl de teamleden bij hoog en bij laag volhouden dat dit toch echt een onmogelijke opdracht is en dat het helemaal niet kan wat het management vraagt. Meestal krijgen ze ook nog gelijk. Ze creëren namelijk hun eigen gelijk door in het team niet de juiste houding aan te nemen. Stel dus voor de start van het project al de potentiële teamleden de vraag of het haalbaar is om binnen de gegeven tijdspanne het gewenste product op te leveren en je weet direct of het teamlid ‘Agile’ is of niet. Van ‘Agile’ mensen krijg je direct een positief antwoord, al dan niet omkleed met voorwaarden, van niet Agile mensen krijg je in principe een negatief antwoord. De instelling waarmee men het project in gaat zal tekenend zijn voor het gedrag gedurende het gehele project. Wat nu te doen met niet Agile teamleden? Het antwoord is heel simpel maar direct ook heel moeilijk. De beste oplossing is deze teamleden vervangen door echt Agile teamleden. Deze zijn echter vaak niet beschikbaar, zeker niet met de vereiste kennis en kunde. Je zult in dat geval moeten bepalen of en hoe je met het team het gewenste resultaat kunt halen. Is de kritische massa binnen het team voldoende Agile om tijdens het traject mee te bewegen in de goede richting of zullen de criticasters de overhand gaan nemen? In hoeverre kan de opdrachtgever het team in een bepaalde richting duwen? Zijn er andere acties uit te zetten om het team de goede kant op te bewegen? Te denken valt hierbij bijvoorbeeld aan het heel bewust wegnemen van de angstcultuur door het management een actieve rol in het project toe te delen. Zo heb ik ooit een voorstel gehoord dat met het maken van fouten wilde gaan belonen. Gaat wellicht wat ver maar het is een interessante gedachte om een team van een angstcultuur af te helpen.
Samenvattend
Agile is dus gericht op mensen en samenwerking. Deze mentaliteit heb je breed in het team nodig om een Agile project tot een succes te maken.
Agile projecten:
- Zijn de leukste projecten om in te werken
- Geven vrijwel altijd tevreden klanten / gebruikers
- Geven je continu nieuwe uitdagingen
Kortom: waarom zou je het ooit nog anders doen!!
Bron: serendipi-tijd.nl
Auteur: Dick Croes
Datum: 6 oktober 2010