Hoofdstuk 18 Welke agile manieren van werken zijn er? #agile

1 Inleiding en leerdoel

In het hoofdstuk ‘Moeten de projectfases elkaar strikt opvolgen? #waterfallvsiteratief’ haalden we al aan dat iteratieve ontwikkelstrategieën een antwoord bieden op de complexe omgeving waarin we vandaag digitale projecten uitvoeren. Door het werk op te delen in korte cycli, kunnen we korter op de bal spelen en de klant betrekken bij elke cyclus.

Het resultaat is een digitale oplossing die beter aansluit bij de noden van de klant en die minder fouten bevat. Binnen de iteratieve strategie zijn er verschillende agile manieren van werken gedefinieerd. Agile vertaalt zich als wendbaar, en dat geeft ook exact aan wat de kern van deze manier van werken is. Op een agile manier werken zorgt voor een grote flexibiliteit die zich gemakkelijk kan aanpassen aan de veranderende realiteit.

Op het einde van dit hoofdstuk: kan ik de verschillende agile methodes benoemen; … begrijp ik het verschil tussen de verschillende agile methodes en begrijp ik in welke context we die kunnen gebruiken.

2 Beschrijving en doel

Omdat agile werken de laatste jaren de norm is geworden op heel wat digitale projecten, vinden we het belangrijk om de verschillende agile methodes apart te belichten. Merk wel op dat het niet in elk bedrijf haalbaar is om agile te werken en dat de andere ontwikkelmethodes zeker nog hun toepassing kennen in de praktijk. In het hoofdstuk ‘Ontwikkelt elk bedrijf agile of volgens de waterfall-methode? #tussenvormen’ gaan we hier nog verder op in.

Hoewel agile al heel lang bestaat, kreeg het invulling in de huidige vorm bij het opstellen van het Agile Manifesto in 2001. Agile ontwikkelen heeft vier vuistregels die moeten worden nageleefd om goede software te maken:

1 Personen en interacties boven processen en tools.

2 Software die werkt boven lijvige documentatie.

3 Samenwerking met de klant boven onderhandeling over het contract.

4 Omgaan met verandering boven het volgen van een plan.

Agile ontwikkelen is een variant op het iteratieve model waarbij veel aandacht wordt besteed aan de directe inzetbaarheid van de software na elke iteratie. De iteraties worden bewust zeer kort gehouden zodat de klant snel vooruitgang ziet in het ontwikkelproces. Naast de snelle vooruitgang wordt agile ontwikkelen ook gekenmerkt door een sterke directe communicatie. Zowel ten opzichte van de klant als binnen het team wordt de voorkeur gegeven aan korte, directe communicatie boven formele verslaggeving. Feedback binnen het team om bijvoorbeeld bij te leren en vooral feedback van de klant om bijvoorbeeld de kwaliteit te verhogen of nauwer aan te sluiten bij de verwachtingen zijn een cruciaal kenmerk van agile werken.

Er wordt vaak gesteld dat agile ontwikkelmethoden werken zonder een concrete planning. Het klopt dat er geen volledige uittekening gebeurt van de oplossing en er dus bijgevolg geen volledige planning kan worden gemaakt. Agile ontwikkelen betekent zich continu aanpassen aan de veranderende omgeving en vereisten van de klant. Vanwege die aanpassende of agile houding van het projectteam, zal het moeilijk zijn om een gedetailleerde planning op te stellen. Men is er immers bijna zeker van dat die niet zal kunnen worden nageleefd.

Toch is het ook in een agile methode belangrijk dat er een planning en een ontwerp worden opgesteld. Het is immers noodzakelijk vooraf resources vast te leggen voor het project, dus is het belangrijk bij de start te weten hoeveel mensen je nodig zult hebben voor welke periode. Er zal ook geen enkel project kunnen starten zonder een budgetbepaling. Veelal wordt ook gesteld dat de analyse bij agile projecten pas gebeurt op het moment dat de functionaliteiten in de iteratie worden opgenomen. Hoewel de diepere uitwerking van de functionaliteiten pas wordt gedaan in elke iteratie, is het uiteraard wel gewenst om vooraf een lijst te hebben van functionaliteiten die de klant verwacht te krijgen op het einde van het project. Geen enkele beslissingsnemer zal een budget vrijgeven, zonder met de leverancier eerst afspraken te maken over wat men daarvoor in de plaats zal krijgen. In de realiteit kan het analysedocument dus in een lichtere vorm worden opgeleverd, maar de meeste onderdelen zullen nog altijd van toepassing zijn.

Er zijn verschillende ontwikkelstrategieën die werken via het agile principe, in dit boek belichten we drie van de meest gebruikte : SCRUM, KANBAN en RUP.

3 SCRUM (http://www.scrum.org)

3.1 Basisprincipes van SCRUM

In IT-projecten is de SCRUM-methode momenteel de meest gebruikte methode. Grote multinationals zoals Nokia, Philips en IBM hebben de laatste jaren SCRUM opgenomen als dé ontwikkelstrategie en implementeren intussen het grootste deel van de projecten volgens dat principe. Het doel van SCRUM is om zo veel mogelijk toegevoegde waarde te creëren op de kortst mogelijke termijn. Elke iteratie (sprint in SCRUMterminologie) duurt twee tot maximaal vier weken. Na die periode levert het projectteam een stukje werkende software af en kan de klant beslissen om al dan niet verder te gaan in een volgende sprint. De klant bepaalt de prioriteiten, het projectteam organiseert zichzelf op de best mogelijke manier om die prioriteiten na te leven.

Een SCRUM-project start met een product backlog. De product backlog is een verzameling van alle functionaliteiten met inschatting (story points) die in het volledige project moeten worden geïmplementeerd. Die lijst wordt aan het begin van het project vastgelegd maar is uiteraard onderhevig aan veranderingen tijdens het project. Een van de eigenschappen van een agile methode is immers de aanpasbaarheid aan veranderende omstandigheden en vereisten. Aan het begin van elke sprint maakt men dan een sprint backlog op waarin alle functionaliteiten worden opgenomen die in de betreffende sprint moeten worden ontwikkeld. De klant zal de prioriteiten bepalen en op basis daarvan wordt de sprintplanning opgemaakt. Tijdens een sprint zijn er geen wijzigingen meer mogelijk.

Binnen één cyclus worden er verschillende communicatiemomenten georganiseerd:

– Tijdens een sprint wordt er een daily standup meeting georganiseerd. In die meeting, die ongeveer vijftien minuten duurt, vertelt elk teamlid wat hij heeft gedaan, wat hij vandaag zal doen en waar hij eventueel problemen mee ondervindt. De meeting wordt rechtstaand gehouden om zo de communicatie kort te houden en de teamleden alert te houden.

Na de sprint houdt men een sprint review waarin wordt getoond wat er tijdens de sprint werd gerealiseerd. Tijdens een sprint review is iedereen uitgenodigd om te komen kijken.

Na de sprint wordt er bovendien een sprint retrospective gehouden. Daarin wordt, samen met het team en de klant, bekeken wat er wel en niet goed werkte tijdens de voorbije sprint.

Een SCRUM-project heeft geen projectmanager, maar een SCRUM-master. Die waakt erover dat de regels worden gerespecteerd en zorgt ervoor dat het team onder optimale omstandigheden kan (samen)werken. Een SCRUM-team bestaat maximaal uit negen personen die voltijds aan het project worden toegewezen. De leden van het team mogen tijdens een sprint niet worden gewijzigd.

Opvolging tijdens de sprint gebeurt via het SCRUM-board en de burndown chart. Op het SCRUMboard zal elk teamlid met behulp van post-its weergeven of een bepaalde taak in planning, in uitvoering of klaar is. De burndown chart geeft de hoeveelheid afgewerkte taken weer in functie van de tijd. In een goede sprint zou de burndown chart lineair moeten dalen.

Ook in SCRUM worden alle fases van een project nog altijd doorlopen. Het zijn echter alsmaar korte iteraties van (detail)analyse, implementatie, testing en turnover die elkaar opvolgen. In vele gevallen zal het zelfs zo zijn dat de fases binnen één sprint worden doorlopen om op die manier de doorlooptijd in te korten maar alsnog de kwaliteit te garanderen voor de uitkomst van de sprint.

Analyse: de analysefase zal in twee stukken worden opgedeeld. In een eerste fase zal er nog wel een analysedocument worden opgemaakt. Het is immers noodzakelijk te bepalen welke functionaliteiten er in de product backlog zullen worden opgenomen. De klant verwacht ook een overeenkomst waarin vermeld staat wat er zal worden opgeleverd voor het budget dat ter beschikking wordt gesteld. Het analysedocument zal in dat geval vooral de functionele analyse bevatten. De technische analyse wordt pas gedaan bij aanvang van een nieuwe sprint wanneer bekend is welke functionaliteiten er in de sprint backlog zijn opgenomen.

– Implementatie: het bouwen van de software zal worden opgesplitst in groepjes functionaliteiten. In elke sprint zullen er extra functionaliteiten worden toegevoegd aan een werkende toepassing.

– Testen: in SCRUM slorpt de implementatie de testfase volledig op. Ontwikkelen en testen gebeurt continu, en met de tools van vandaag gebeurt het testen vaak ook automatisch. Het is dus moeilijk om de testfase nog apart te benoemen van de implementatie omdat het eigenlijk één geheel geworden is. Er moet wel opgemerkt worden dat de verschillende testtypes nog altijd moeten worden uitgevoerd en dus geldig blijven ook bij de ontwikkeling van SCRUM.

– Turnover: omdat elke sprint werkende software moet opleveren, zal er ook op het einde van elke sprint een turnover moeten gebeuren. De werkende software zal na validatie in productie worden gezet en worden opgenomen door het operationsteam van de klant. De hypercare zal door de beperkte en goed geteste functionaliteit zeer kort zijn.

Vanuit de praktijk merken we heel sterk dat SCRUM-gebaseerd werken een grote impact kan hebben op de organisatie van het bedrijf. SCRUM zal een aantal nieuwe rollen invoeren (bv. SCRUM master, Product owner, …) en zal eveneens nieuwe interactiemomenten vereisen (bv. daily standup, sprint retrospective, …). SCRUM gaat ook uit van het principe van cross-functionele teams, waarbij tijdelijk de juiste resources uit de verschillende afdelingen worden samengebracht in een SCRUM-team. Daarnaast lijkt het voor klanten (product owners) leuk om snel feedback te krijgen of voortgang te zien. Maar SCRUM kan maar goed werken als alle betrokkenen het tempo kunnen volgen en met veel discipline de principes volgen. Dat kan zowel voor bedrijven als voor de mensen erg belastend zijn. Voor veel bedrijven is het dan ook geen evidentie om het roer om te gooien en die veranderingen vlot te integreren in hun huidige werking. Dat wordt nog complexer als slechts één afdeling, typisch de IT afdeling, volgens die ‘afwijkende’ manier zal gaan werken. Zo ontstaat er mogelijk een situatie waarbij de verwachtingen van twee afdelingen – IT versus de anderen – te ver uit elkaar liggen.

3.2 SAFe® SCRUM

(http://www.scaledagileframework.com/)

Naast de traditionele toepassing van SCRUM is er een andere variant die de laatste jaren aan belang wint, SAFe® SCRUM ofwel Scaled Agile Framework®1. SAFe® SCRUM is gebaseerd op de principes van lean management, dat er op gericht is om alle overbodige zaken uit een proces te verwijderen. Het is een methodologie die gecreëerd werd uit best practices en evaluaties van vele implementaties.

De SAFe® SCRUM-benadering ontstond vanuit de uitdagingen die grote bedrijven zien bij het toepassen van SCRUM: veelal werken honderden softwaredevelopers elk aan hun eigen toepassing op een zeer flexibele manier waardoor het voor program managers onmogelijk was geworden om het overzicht te bewaren. Waar een waterfall-methode nog zorgde voor een stabiele aanpak, is er in de SCRUM-methode net heel veel verandering mogelijk. Het Scaled Agile Framework® zorgt er dus voor dat SCRUM ook naar grote organisaties geschaald kan worden door een niveau boven de teams te introduceren. Zo kan een program manager ook het overzicht bewaren van alle teams die in zijn organisatie werken en kan de onderneming ook altijd de economische waarde van alle projecten en ontwikkelingen evalueren.

De bovenstaande figuur geeft de organisatie van een SAFe® SCRUM-methode weer. Onderaan bevinden zich de verschillende teams die op een SCRUM-manier verschillende sprints doorlopen. Dat gebeurt op de manier waarop SCRUM al eerder werd beschreven. Verschillende teams vormen dan een program waarbij op een hoger niveau wordt gekeken welke functionaliteiten nodig zijn om een bepaald businessproces te ondersteunen. Al die functionaliteiten maken deel uit van een release train die volgens een bepaald ritme functionaliteiten oplevert aan de business. Dat ritme wordt bepaald door de flexibiliteit die de organisatie nodig heeft. De verschillende release trains worden dan gegroepeerd in een portfolio. Dat geeft de organisatie een goed overzicht van alle projecten die op dat moment lopen, met de bijbehorende budgetten. SAFe® SCRUM geeft grote organisaties dus de kans om SCRUM te implementeren zonder in te boeten aan overzicht en opvolging.

SAFe® SCRUM is gebaseerd op negen principes:

1 Economisch inzicht

Elke beslissing die in een project genomen wordt, gebeurt vanuit economische overwegingen: zorgt de uitkomst van de beslissing voor waardecreatie en draagt het bij tot de economische waarde van de organisatie? Beslissingen moeten dus gefundeerd worden genomen, met een correcte afweging van alle kosten en risico’s.

2 Pas systeemdenken toe

Projecten komen altijd tot stand in een grotere context. Als er zich problemen voordoen, is dat zelden het resultaat van één oorzaak. Meestal worden ze veroorzaakt door de interacties van verschillende actoren in een systeem. Een probleem staat dus zelden op zichzelf en het onderzoek ernaar moet rekening houden met alle factoren die er invloed op hebben.