Blog

Hoe krijg ik grip op een IT-project met scrum?

Nog altijd zijn er veel IT-projecten die mislukken, zowel in het bedrijfsleven als bij de overheid. Eén van de oorzaken is dat er nog altijd teveel wordt gestuurd op tijd en kosten, in plaats van op de opgeleverde functionaliteit. Om dit te ondervangen en beter te kunnen sturen op functionaliteit, zijn er steeds meer organisaties die de principes van scrum omarmen. Scrum belooft meer slagvaardigheid, focus op kernpunten en meer motivatie en samenwerking binnen teams. Dit klinkt natuurlijk mooi, maar pakt het in de praktijk ook zo uit en aan welke randvoorwaarden moet worden voldaan om scrum succesvol in te zetten?

Het belangrijkste uitgangspunt van de klant is dat er een kwalitatief goed systeem, dat wil zeggen een systeem dat voldoet aan zijn verwachtingen, wordt opgeleverd. Om de kwaliteit van het op te leveren systeem te kunnen waarborgen, moet het spanningsveld tussen functionaliteit (scope), capaciteit (geld) en tijd (planning) goed worden gemanaged. Bij een traditionele waterval-aanpak wordt de functionaliteit vooraf nauwkeurig bepaald en vastgelegd en wordt gedurende het project duidelijk wat de uiteindelijke kosten en doorlooptijd zijn. Bij een agile scrum-aanpak wordt gewerkt met een fixed price-/fixed date-aanpak, waarbij geld en doorlooptijd worden bevroren en juist de op te leveren functionaliteit nog kan variëren. De klant weet bij een agile aanpak dus zeker wanneer en tegen welke kosten het systeem in productie zal gaan, maar nog niet welke functionaliteit het systeem zal bevatten.
Ondanks dat bij scrum de focus ligt op de functionaliteit, blijkt in de praktijk dat als de bevroren onderdelen van de driehoek niet goed worden gemanaged dit ten koste gaat van de kwaliteit van het systeem. Eerder moeten opleveren dan gepland, teamcapaciteit die niet beschikbaar is of de scope uitbreiden, zijn zaken die de kans vergroten dat het opleverde systeem uiteindelijk niet voldoet aan de verwachtingen van de klant. Wil scrum in de praktijk goed uitpakken, dan moeten alle betrokkenen weten wat van hen wordt verwacht, moet er inspectie van (tussen)resultaten mogelijk zijn zonder dat het ontwikkelproces wordt gefrustreerd en moet men durven de werkwijze gedurende het project aan te passen.
Deze drie aspecten, transparantie, inspectie en aanpassingsvermogen, vertaal ik doorgaans naar acht concrete adviezen die als leidraad kunnen dienen om scrum op een goede manier in te zetten voor meer grip op IT-projecten:

1. Team – Formeer één kern team dat niet te groot is en met korte lijnen.
Voor een scrum-team worden in theorie drie rollen onderscheiden: product owner, scrum master en ontwikkelaar. In de praktijk zijn vaak ook nog een opdrachtgever, senior eindgebruikers, IT-medewerkers, een delivery manager en support engineers betrokken. De ideale omvang is vier tot zes teamleden, dus verdeel deze rollen slim over een beperkt aantal betrokkenen.
2. Product – Zorg voor één gedeelde visie en afbakening ervan.
Om dit te bewerkstelligen, is het raadzaam om ‘IT-oplossing’ uit te werken in een product visie, product roadmap en product backlog. In de productvisie beschrijft de producteigenaar waarom het project wordt gestart en wat de gewenste eindsituatie is. Een product roadmap is een tactisch plan waarin wordt beschreven hoe het product de komende maanden of jaren zal gaan groeien. De product backlog is een prioriteitenlijst met de te ontwikkelen items voor de eerste release(s).
3. Project – Gebruik een duidelijke fasering van start tot nazorg.
Om verrassingen te voorkomen, dient voordat met de eigenlijke ontwikkeling wordt gestart een korte analyse (sprint 0) plaats te vinden. Daarnaast dienen ‘acceptatie en implementatie’ als een volwaardig projectonderdeel te worden benaderd waarbij net als bij de ontwikkeling de eindgebruikers en functioneel beheerders intensief worden betrokken.
4. Analyse – Focus op ‘bouwrijpe’ requirements en denk ook aan de niet-functionele eisen.
De functionele eisen moeten worden voorzien van een bedrijfswaarde, verwachte ontwikkelinspanning, acceptatiecriteria en prioriteit. Omdat niet-functionele eisen, zoals performance, onderhoudbaarheid, schaalbaarheid en gebruiksvriendelijkheid, in de praktijk nog wel eens onderbelicht blijven, is het goed deze bewust te benoemen en op dezelfde gestructureerde manier te behandelen als de functionele eisen.
5. Bouw – Houd de sprints bewust om de doelrealisatie te blijven toetsen.
Een sprint is een vaste timebox waarbinnen een bruikbaar en potentieel uitleverbaar productincrement met een bepaald sprintdoel wordt gerealiseerd. Een timebox van 2 tot 3 weken blijkt doorgaans goed werkbaar. Belangrijk hierbij is dat ook de sprint retrospective (evaluatie) niet wordt vergeten om de werkwijze voor de volgende sprint gelijk te kunnen verbeteren.
6. Test – Blijf hameren op een gezamenlijke definitie van ‘klaar’.
De definitie van ‘Klaar’ dient op verschillende niveau’s te worden gedefinieerd door het scrum team: per user story, per sprint en per release. Alleen door als opdrachtgever en projectteam expliciet te maken waaraan iets moet voldoen kan een systeem tijdig geaccepteerd worden en naar productie gaan.
7. Beheer – Implementeer release wise development.
Een systeem dat wordt gerealiseerd op basis van scrum is in principe nooit af. Bij de start moet duidelijk worden gecommuniceerd dat door middel van meerdere releases per jaar er telkens nieuwe functionaliteit bij zal komen om een invulling te geven aan de productvisie en product roadmap.
8. Tools – Gebruik technologie die een agile scrum manier van werken ondersteunt.
Omdat er continu verschillende versies, zoals een productieversie, testversie en ontwikkelversie, van een systeem zijn, is een OTAP-straat op locatie of in de cloud noodzakelijk. Maak ook gebruik van goede Rapid Application Development en Maintenance tools.

Door bovenstaande adviezen in acht te nemen, zorg je voor grip op IT-projecten waarbij een scrum-aanpak wordt gehanteerd. Het helpt onder meer om systeemeisen stapsgewijs te ontdekken en te verfijnen, een team adequaat in te richten en op een goede manier te laten samenwerken, op basis van de juiste projectinformatie tijdig bij te sturen en bedrijfsvoering en ICT optimaal op elkaar aan te sluiten. Dit alles draagt bij om uiteindelijk een systeem op te leveren dat in alles voldoet aan de verwachtingen van de opdrachtgever.
 

Deze blog is geschreven door Joachim Vandecasteele. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van JoachimVandecasteele
Joachim Vandecasteele
Anderson MacGyver - Adviseur

Joachim Vandecasteele is adviseur bij Anderson MacGyver heeft een passie voor business innovatie én structurele organisatieverbetering met IT. Anderson MacGyver realiseert meer businesswaarde met IT. Door advies- en managementdiensten vergroot Anderson MacGyver de waarde van IT en informatie voor organisaties. Daarvoor was
hij CTO bij COOLProfs, specialist in het bouwen van bedrijfskritische informatiesystemen op maat op basis van OutSystems en CA Gen modelgedreven RAD-tooling. Vandecasteele was voor zijn tijd bij COOLProfs senior consultant bij KPMG Consulting op het gebied van World Class IT en consultant ISES International op het gebied van CASE-tools voor systeemontwikkeling. Hij heeft verschillende publicaties op zijn naam staan over de toekomst van de IT-organisatie, over strategierealisatie met de balanced scorecard en over maatwerk systeemontwikkeling. Vandecasteele studeerde Bestuurlijke Informatiekunde aan de Katholieke Universiteit Brabant en Bedrijfsinformatica aan de Haagse Hogeschool. Zijn vrije tijd besteedt hij aan zijn gezin, alles volgen wat met IT te maken heeft en triathlons, trails en marathons. Altijd gedreven, scherp en vrolijk!

Twitter: jvandecasteele
Email: joachim.vandecasteele@andersonmacgyver.com

 
Reacties
Harry op donderdag 27 november 2014 13:52

Hoi Joachim,

Goed stuk, de genoemde aanbevelingen voor het uitvoeren van een IT project met scrum zijn nagenoeg 1 op 1 terug te voeren op Prince2.

Akkoord voor de volgende fase is alleen mogelijk na goedkeuring/ acceptatie van de producten uit de lopende fase. Volgens mij is de integratie van Scrum met een overkoepelend PM methode zoals Prince2 onvoldoende belicht bij de meeste organisaties. Wellicht is de reden afkeer van doorgeschoten bureaucratie en een overkill aan overhead ...

gr
Harry

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.