Buzz, buzz, buzz. De digitale sector zit vol van ‘buzzwords’. Alle producten worden in een ‘Saas’ gegoten, alle diensten moeten ‘smart’ worden, we staan voor een revolutionaire revolutie met ‘IoT’ (Internet of Things) en ga zo maar door. Binnen het gebied van projectmanagement zijn er ook een aantal van die buzzwords, waaronder ‘agile’ één van de meest voorkomende is.
Alles moet tegenwoordig 'agile' zijn. Maar wat betekent dit nu precies? Agile is een filosofie, die verschillende vormen kan aannemen. Zoals bij elk buzzword is het belangrijk om te duiden waar het precies over gaat.
Het meest gebruikte model om een project vorm te geven, is het ‘watervalmodel’. Elk aspect van het project krijgt zijn eigen tijd en plaats binnen de hiërarchie. Als één aspect klaar is, wordt dit doorgegeven aan de volgende en is er weinig mogelijkheid om terug te keren (in theorie althans). Eén van de meest bekende methodes hiervan is PRINCE2. Je ziet hieronder het model van deze methode. Ik raad je aan om hier eerst even voor neer te zitten …
Bij projecten in continue ontwikkeling en met veel externe factoren, zorgt deze methode voor heel wat nadelen. Het zijn deze frustraties die enkele software ontwikkelaars aangezet hebben om in 2001 het ‘Agile Manifesto’ neer te schrijven. Het bevat vier kernwaarden die een duidelijke reactie zijn op het watervalmodel en de zware bureaucratie die daar vaak mee gepaard gaat.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Als ik dit in mijn eigen woorden mag samenvatten staat er: praat met elkaar, maak intuïtieve producten, communiceer transparant met de klant en aanvaard dat er onverwachte dingen gebeuren. Merk zeker op dat deze vier zinnen niet mogen gelezen worden als een soort van ‘vier geboden’. Het woordje ‘over’ bevat hier veel belang en geeft aan dat men de voorkeur geeft aan de linkse manier van werken, maar enkel als deze past binnen de omgeving of het project waar je zit.
Het belangrijkste binnen dit manifest is voor mij dat het ruimte geeft om fouten te maken, ook vaak verwoord als ‘fail fast’. Fouten worden altijd gemaakt. Het is belangrijk om daar steeds lessen uit te trekken. Hoe sneller dat je tot deze fouten en deze lessen komt, hoe sneller dat je dan ook meteen weet welke andere richting je moet aanpakken.
Heel vaak worden ‘agile’ en ‘SCRUM’ als synoniemen gebruikt. Het is belangrijk om het onderscheid hierin te kennen. Bij de ontwikkeling van software zijn er twee belangrijke componenten te onderscheiden: het projectmanagement en de oplevering van een project. Onder projectmanagement verstaan we het aligneren van de verschillende aspecten van een project, zorgen dat het budget, de timing, de functionaliteit en de kwaliteit correct opgevolgd worden. Bij oplevering bedoelen we de manier waarop we de producten beschikbaar stellen en beheren.
Agile is de theorie en SCRUM is één van de vele manieren om het in de praktijk om te zetten. Het beschrijft welke rollen er nodig zijn en hoe die optimaal samenwerken om de te ontwikkelen software tot een goed einde te brengen. Dit op basis van nauwe samenwerking (individuals and interactions), geïntegreerd testen (working software), transparante communicatie via sprint review en planning momenten (customer collaboration) en commitment op een korte tijdspanne (responding to change).
SCRUM is een heel gemakkelijk te implementeren manier van werken als je voor een lange periode aan een project werkt. Het geeft ook meteen resultaat. Maar elk bedrijf die ooit de omschakeling probeert te maken, botst wel eens op de vraag “Wie leidt dit nu allemaal?” Bij SCRUM is het duidelijk dat iedereen werkt naar één doel: een mooi product. Wie houdt zich dan bezig met ‘the bigger picture’? Wie overziet het budget, de timing en de langetermijnstrategie?
Voor het component ‘projectmanagement’ van een project bestaat er de ‘agilePM-methode’. Deze helpt bij het managen van en communiceren over projecten die agile werken en is perfect combineerbaar met SCRUM als methode voor de oplevering. Onderstaande afbeelding geeft een mooie samenvatting van de aanpak van de traditionele watervalmethodes t.o.v. de agilePM-methode (DSDM is de meer technische naam). Het is duidelijk dat de tijd (werken in sprints), het budget (mogelijk een vaste prijs per sprint) en de kwaliteit (door geïntegreerd testen) vast staan. Enkel de functionaliteit is variabel.
Het projectmanagement in deze methode bevat dus ook veel minder overhead aan plannen en rapporteren. Enkel bij de start (in de afbeelding te zien onder pre-project, feasibility en foundations fase) voorzien we een kleine voorbereidingstijd die de verschillende modaliteiten van het iteratieve werkproces definieert. Hier worden de volgende afspraken gemaakt.
- Strategie: wat is het doel en de prioriteit van de componenten van dit project?
- Ontwikkeling: hoe pakken we de technische uitwerking aan en hoe wordt er getest?
- Opvolging: op welke wijze en tijdstippen wordt er gecommuniceerd over de voortgang; wat wordt er verwacht van de verschillende betrokken partijen?
Agile is een buzzword en ik heb geprobeerd om met de duiding van hierboven dit wat concreter te maken. Veel mensen worden er vaak enthousiast van en willen er meteen mee aan de slag gaan. Het is echter wel belangrijk om de juiste keuzes hierin te maken. Niet elk project is geknipt om op agile-wijze uit te voeren.
Wanneer kies je voor agile?
- Als je onmiddellijk wilt kunnen reageren op elke wens van je gebruiker of wijziging in de markt.
- Als je als bedrijf en tijdens de ontwikkeling van het product sterk betrokken wilt zijn.
- Als je product continu verbeterd en onderhouden moet worden.
Wanneer kies je niet voor agile?
- Als je product opgebouwd moet zijn op basis van een vooropgesteld plan.
- Als je niet continu betrokken kunt zijn bij de ontwikkeling van het product en diens verloop.
- Als het product na ontwikkeling weinig updates of nieuwe functionaliteit moet bevatten.
Bij de start van elk project gaan we als projectmanagers bij Duo steeds op zoek naar de juiste werkmethode. Deze keuze gebeurt steeds op basis van de noden van de klant en de samenstelling van het project. Het is ook belangrijk dat elk project zijn eigen ‘variant’ van een werkmethode heeft, er zijn nooit twee identieke projecten. Het vastleggen van deze werkmethoden geven enkel de houvast en moet je behandelen als een ‘gereedschapskist’ waarop je de juiste aanpassingen maakt om een optimale werkomgeving te hebben.