De afgelopen jaren heeft de Processing-afdeling van Thales in Hengelo een transitie doorgemaakt van multidisciplinaire projectteams naar gezamenlijk het werk aanpakken en parallel de gewenste functionaliteit realiseren middels één backlog voor alle projecten. René van Hees en Sandra Roijakkers delen hun ervaringen tijdens deze reis, zowel de ontberingen als de successen.
De businesslijn Sensors van Thales Nederland ontwerpt radarsystemen en andere sensoren die deel uitmaken van een compleet, geïntegreerd verdedigingssysteem. De productportefeuille varieert van kleine draagbare sensoren voor bijvoorbeeld grens- of objectbewaking tot complexe driedimensionale radars die honderden kilometers ver kijken op zee. Binnen de businesslijn is de Technical Unit Processing verantwoordelijk voor de ontwikkeling van de digitale processing in de sensoren. Na positieve ervaringen met Agile in studentenprojecten, researchopdrachten en relatief kleine specifieke radarontwikkelingen wilden we de aanpak graag invoeren binnen de hele afdeling.
De ontwikkelgroep waar de TU Processing binnen valt, werkt echter in projecten met een fixed price, fixed scope en fixed lead time. Ontwikkelwerk komt op een watervalmanier via de afdeling systeemengineering binnen bij Processing en de twee andere TU’s. De processingarchitect verdeelt het over de zeven verschillende deelkennisgebieden die er binnen de afdeling zijn. Een software-integrator integreert de deelleveringen, waarna een processingtester alles functioneel test. Vervolgens levert de TU op aan de systeemtester van systeemengineering, die het werk samenvoegt met de leveringen van de andere TU’s en het geheel op systeemniveau test. Hierbinnen overstappen op Agile bleek niet triviaal.
Heringericht
Vóór de overgang naar Agile alloceerden we ontwikkelaars aan projectteams die fysiek gescheiden van elkaar werkten. Een projectteam bevatte hierbij van elk deelkennisgebied één of enkele engineers. De nadelen laten zich raden. Binnen een projectteam konden pieken en dalen in de werkzaamheden op een deelkennisgebied niet worden opgevangen. Als een project een deadline niet dreigde te halen, claimde het de hoogste prioriteit en moesten kennisdragers uit een ander projectteam bijgeschakeld en ingewerkt worden. Ook was de kennisuitwisseling op hun deelkennisgebied tussen de engineers in verschillende projectteams beperkt, waardoor er meerdere oplossingen ontstonden voor eenzelfde probleem.
De transitie naar Agile-projectteams zou deze nadelen niet oplossen. Daarom kozen we ervoor om van elk van de deelkennisgebieden een scrumteam te maken. Deze zogeheten componentteams zetten het werk van de lopende projecten dat binnen hun deelkennisgebied lag in een eigen backlog en pakten de taken op in volgorde van prioriteit. De externe leveringsmijlpalen van de diverse projecten bepaalden hierbij de volgorde.
Nu hadden we een aantal Agile-teams, de componentteams, die onafhankelijk van elkaar werkten (Figuur 1). Zoals verwacht, loste dit enkele nadelen van de vroegere werkwijze op: planning binnen een deelkennisgebied pakten we over projecten heen aan en er was kennisdeling binnen het deelkennisgebied. We kregen er echter nieuwe nadelen voor terug, met als belangrijkste dat de hoeveelheid werk die we als afdeling verzetten eerder kleiner dan groter werd en dat de systeemtesters ontevreden waren over de kwaliteit en snelheid van de leveringen.
Tijdens de evaluatie waarom onze aanpak geen succes was, kwamen we uit bij het eerste principe van het Agile Manifesto: ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’. We realiseerden ons dat wij met de nieuwe werkwijze niet meer gefocusseerd waren op het creëren van ‘waarde’ voor de (interne) klant; de onafhankelijke leveringen van de componentteams hadden immers pas waarde als ze geïntegreerd en getest waren.
In de oude situatie werkten de software-integratoren en processingtesters mee in het projectteam en pakten zij de leveringen van een deelkennisgebied meteen op om ze tot waardevolle input te maken voor de systeemtester. Met de nieuwe werkwijze lagen deelleveringen vaak lang te wachten en werden ze geïntegreerd en getest als de componentteams alweer bezig waren met ander werk. Zij konden daardoor veel minder efficiënt ondersteuning bieden. We concludeerden dat we leveringen moesten maken die waarde hebben voor de systeemtester, dat we ons dus moesten richten op geïntegreerde en geteste combinaties van deelleveringen van meerdere componentteams.
Daarom hebben we de afdeling nogmaals heringericht. De componentteams bestaan nog steeds, maar pakken het vanuit de projecten aangeleverde werk gesynchroniseerd op (Figuur 2). De software-integratoren opereren projectonafhankelijk en deels in de componentteams en de processingtester doet mee in de afdelingssprint. Net als in de oude projectteams stemmen zij hun werk dus nauw af met de ontwikkelaars.
Boeggolf
Projecten hebben een releaseplanning waarbij we drie à vier keer per jaar functionaliteit moeten leveren. Hieruit volgt een-op-een de externe mijlpaalplanning voor de afdeling. De in een release gevraagde functionaliteit splitsen we op in een geprioriteerde lijst van features die waarde hebben voor onze interne klant, de systeemtester. Het heeft enige tijd geduurd voor het ons lukte om het werk zo op te delen dat de features voldoende klein zijn om gerealiseerd te kunnen worden in één sprint en toch waarde hebben.
Een feature bestaat uit story’s die allemaal met de expertise van één componentteam zijn te realiseren. Elk team heeft dus nog steeds een storybacklog, maar de samenhang van de teambacklogs hebben we expliciet gemaakt middels bovenliggende features (Figuur 3). We hebben een formule uitgewerkt waarbij we featurepunten toekennen aan een feature op basis van het gewogen gemiddelde van de storypunten van de teams die aan het betreffende feature werken. Voor elk project hebben we zo een backlog met projectspecifieke features, die we samenvoegen tot één afdelingssprintbacklog (Figuur 4).
Aanvankelijk voegden we tijdens de vierwekelijkse sprintplanning steeds een volgend feature toe aan de sprintbacklog tot een componentteam volledig beladen was; we probeerden de teams maximaal vol te plannen. Helaas slaagden we er maar zelden in om een sprint te halen. Het bleek dat de inspanning om te komen van opgeleverde en geteste story’s tot een werkend feature niet in de afzonderlijke storypuntschattingen zat. Deze schattingen omvatten alleen het werk om deelleveringen te maken, niet de bijdrage die vanuit de componentteams nodig was om ze te integreren en te testen.
In het begin haalden we weliswaar zelden een sprint, maar wel altijd ongeveer hetzelfde aantal featurepunten. Dit aantal hebben we daarom tot het criterium gemaakt om te bepalen of een sprint vol zit of niet. We plannen teams nu zo ver vol dat ze naast het realiseren van story’s voldoende ruimte hebben om te assisteren bij de realisatie van werkende features. Als ze dan nog ruimte over hebben, helpen ze andere teams, en als dat niet mogelijk is, werken ze vooruit. Zo veel mogelijk features van de afdelingssprintbacklog halen (in prioriteitsvolgorde) staat echter voorop.
Een ander probleem hadden we met de probleemrapportages (pr’en) die terugkomen van opgeleverd werk. Door onze focus op het halen van de afdelingssprint kregen deze vaak lage prioriteit. We hebben daarom geïntroduceerd dat we de problemen die we vinden in een sprint moeten oplossen in de volgende sprint. Hiermee voorkomen we dat er een boeggolf aan pr’en ontstaat en waarborgen we de kwaliteit van het reeds geleverde werk. Doordat pr’en voortkomend uit fouten in ons eigen werk of restpunten op dat werk niet meetellen in de velocity, is dit een maat voor hoeveel featurepunten we per sprint foutloos kunnen realiseren.
Productiviteitsverhoging
Met onze herziene werkwijze hebben we de drie assen levertijd, geld en kwaliteit onder controle en zijn we voorspelbaar geworden. We willen echter blijven verbeteren, met name in de productiviteit. We willen voorspelbaar sneller worden. Omdat de huidige Agile-aanpak voor ons goed voldoet, moet de gewenste productiviteitsverhoging vooral komen uit inhoudelijke verbeteringen in de softwareontwikkeling, zoals efficiënter worden door meer code te genereren en de kwaliteit van leveringen verhogen door een verbeterde en uitgebreidere automatische teststraat.
Met het management hebben we afgesproken dat we iedere sprint één featurepunt ‘investeren’ in verbeteringen. Vanaf december 2016 zullen we hierdoor stapsgewijs drie featurepunten in velocity hebben gewonnen. Concreet en meetbaar. De verbetervoorstellen komen uit de teams zelf en plaatsen we uiteraard op de afdelingsbacklog.