Interview: Ted Oliekan
Het Kadaster komt vanuit een klassieke demand & supply-IT-omgeving en heeft de laatste jaren toegewerkt naar een agile omgeving. Daarin maakt het gebruik van Scrum- en DevOps-methodieken. Ook het management doet actief mee aan de toepassing van agile.
Kengetallen
| Agile sinds | 2012 met een aantal teams en sinds 2014 wordt op grotere schaal het gedachtegoed van agile omarmd. |
| Aantal agile teams | 18 (doel is dat 90 procent van de applicatieontwikkelteams overgaat op agile werken) |
| Gemiddelde grootte van een team | 8 personen |
| Voorkeur sprintlengte | 2 weken |
| Gemiddelde time-to-market | Time-to-market is maximaal een jaar voor de ontwikkeling van een product voor grote IT-ontwikkelingen. Het Kadaster is ook bezig met agile portfolio-ontwikkeling die hierin voorziet. |
Hoe is bij het Kadaster het agile werken ingericht?
Het Kadaster komt vanuit een klassieke demand & supply-IT-omgeving en heeft de laatste jaren toegewerkt naar een agile omgeving. Agile bij het Kadaster is ondergebracht in vaste teams die samenwerken en verantwoordelijk zijn voor zowel ontwikkeling als beheer. Hiervoor moet het Scrum-team, inclusief product owner, ervaren genoeg zijn om naast vernieuwing ook de continuïteit te waarborgen. Het Kadaster gebruikt zowel Scrum- als DevOps-methodieken en ziet het belang in van een goed functionerend prioriteringsproces in de vorm van bijvoorbeeld een scrum of scrums.
Wat zien jullie als de belangrijkste voordelen van agile werken?
Het belangrijkste voordeel van agile is dat softwareontwikkeling effectiever wordt. Een goede samenwerking tussen business en IT maakt het mogelijk wendbaarder te zijn in het ontwikkelproces. Sneller zichtbare (tussen)resultaten geeft mogelijkheid tot bijsturing. Accepteer dat er onzekerheden zijn bij softwareontwikkeling. Daarnaast denken we dat het een meer realistische vorm is van ontwikkeling van projecten ten opzichte van de klassieke watervalmethode. Omdat het team vaststaat, kijk je meer naar de prioritering van functionaliteit. Dit is een belangrijk verschil met hoe vroeger IT-projecten verliepen, projecten waarbij de functionaliteit vaststond en het team schaalbaar was.
Wat is voor jullie lastig bij het agile werken? Wat levert de meeste hindernissen op?
De grootste hindernis is een gefaseerde vervanging van grote legacysystemen die als een monoliet gebouwd zijn. Het is een worsteling om dat in sprints op te knippen. Daarnaast is een cruciale factor dat de rol van product owner met overzicht en mandaat van de business goed is ingevuld. Dat heeft tijd en begeleiding nodig.
Houden jullie kengetallen bij? Meten jullie? Zo ja, wat?
Elk team houdt onderling zijn eigen gedefinieerde storypoints bij en meet binnen het team de performance (velocity). Het Kadaster houdt daarnaast ook nog vast aan een meting op basis van functiepunten om de performance van verschillende teams te vergelijken. Hierin zie je dat het Kadaster niet alles van agile omarmt en ook nog sterke punten uit het verleden blijft hanteren.
Hoe voeren jullie testen uit? Voeren jullie acceptatietesten uit na iedere iteratie? Betrekken jullie ook eindgebruikers bij het testen?
Het Kadaster koppelt agile aan continuous delivery en DevOps. Voor ons is dat de ultieme vorm van agile, waarbij teams ontwikkeling dagelijks naar een productieomgeving kunnen brengen. Bij het continuous delivery process hoort geautomatiseerd testen, waarbij testen geen belemmering meer mag zijn in de gang naar productie. Na iedere iteratie worden acceptatietesten uitgevoerd waarbij eindgebruikers minder belast worden met behulp van geautomatiseerd testen. De testcapaciteit wordt bepaald aan de hand van de zwaarte van de release.
Hoe gaan jullie om met continue verbetering binnen/over de teams?
Omdat agile teams niet van de ene op de andere dag dit volwassenheidsniveau bereiken, werkt het Kadaster met een change-managementfasering waarbij ieder team een agile coach heeft en een spindiagram. Daarnaast maakt het Kadaster gebruik van een agile transitieteam, SWAT-team genoemd, dat de teams ondersteunt om de omslag naar agile te maken.
Figuur 1. Spindiagram agile team.
Heb je nog een goede tip voor andere organisaties?
Het is misschien een open deur: agile ontwikkelen is een manier van denken. Het moet breed in de organisatie begrepen worden. Dan pas kan er begonnen worden met een omslag. Het bevalt ons goed om dat gefaseerd te doen maar wel steeds terug te keren naar het fundament van agile denken.
Het is een investering in mensen en techniek. Ik denk dat de samenhang met continuous delivery voor ons een succesfactor is. Een team dat in staat is wekelijks (of zelfs nog vaker) zonder gedoe naar productie te gaan, kan een ritme ontwikkelen waar iedereen enthousiast over wordt. Agile geeft de mogelijkheid business en IT meer te integreren. De rol van product owner is daarbij wel cruciaal. Ook is een succesfactor dat je als management actief meedoet aan agile. Wij hebben ons IT-reorganisatieplan en de uitvoering daarvan ook op een agile manier tot stand gebracht. Dit is een mooi voorbeeld van hoe agile ook te gebruiken is buiten softwareontwikkeling. Hiermee leer je als organisatie om op een nieuwe manier te werken. Je kunt agile pas begrijpen als je het zelf meemaakt.
Ron Kolkman is sinds oktober 2013 directeur IT van het Kadaster en was daarvoor directeur IT bij de Rechtspraak. Voor het Kadaster is het belangrijk om business en IT te verbinden. Voor deze organisatie is IT onlosmakelijk verweven met de performance van het Kadaster. IT zal in de toekomst een steeds grotere rol gaan spelen, onder andere door de opkomst van nieuwe datagerelateerde producten.