a.s.r. Cross Team Feature Delivery

Context

Nieuwe verzekeringsdekking is een commerciële belofte voordat het een backlogitem is. De datum staat vast en het product is geprijsd, en het platform moet klaar zijn op de dag zelf. Dit traject voegt die functionaliteit toe aan hetzelfde platform waarop de aanvraagflow en de calculatietool draaien, in hetzelfde scrumteam van 7 developers en 9 mensen in totaal.

De uitdaging

Vrijwel geen van de risico's zit hier in de code. Het zit in de delen die andere teams bezitten: de APIs die deze functionaliteit leest en schrijft zijn van hen, staan op hun roadmaps, tegen hun eigen toezeggingen. Een datum die je niet in de hand hebt en afhankelijkheden die niet van jou zijn: dat is de combinatie die stilletjes uitmondt in een late oplevering, en dat blijft alleen uit als iemand de ongemakkelijke vraag vroeg genoeg stelt om er nog iets aan te hebben.

Wat ik deed

• Het traject van planning tot oplevering opgepakt, wat hier betekent dat de gesprekken voordat het eerste ticket er is net zo zwaar tellen als het engineeringwerk daarna.
• Bewust eerst op hoofdlijnen gekeken, en de tijd genomen om de hele vorm van de vraag te begrijpen voordat ik het team aan een deel ervan vastlegde.
• De planning samen met de projectmanager uitgewerkt, zorgvuldig en herhaaldelijk, want een datum die buiten engineering is bepaald is alleen geloofwaardig als het plan erachter eerlijk is over wat er past.
• Met de andere teams afgestemd over de API-afhankelijkheden, wat ze beschikbaar zouden stellen, wanneer, en wat dit platform in de tussentijd doet als daar iets in verschuift.
• Het op het platform gebouwd, in .NET achter de Vue.js-flowstappen, op de services waarop de aanvraagstraat en de rekentool al draaien.
• De functionaliteit zo opgesplitst dat waarde vroeg wordt opgeleverd, in plaats van in één keer aan het eind, waardoor releasebatches klein blijven en stakeholders iets concreets krijgen om op te reageren.

Het resultaat

• Afhankelijkheden met andere teams afgesproken in plaats van aangenomen, en juist daar gaat zo'n datum meestal verloren.
• De business ziet wat er wanneer wordt opgeleverd, op basis van een planning die ze mee heeft opgebouwd.
• Loopt nog op het moment van schrijven, en dat is de eerlijke stand van zaken.

Gebruikte technologieën

• .NET: De backendservices achter de nieuwe functionaliteit.
• C#: De taal van die services.
• GraphQL: De API-laag over het platform.
• API-ontwikkeling: De koppelingen tussen dit platform en de andere teams.
• Azure: Het cloudplatform waarop het werk wordt gebouwd, uitgebracht en gedraaid.
• Azure Pipelines: De deployment-pipelines achter de releases.
• CI/CD: Het releasepad waarlangs de increments naar buiten gaan.
• TypeScript: De taal in de hele applicatielaag.
• Vue.js: De stappen die de gebruiker ziet.
• Playwright: Geautomatiseerde dekking van de flows die worden uitgebreid.
• SCRUM: Hoe het team werkt en hoe de increments worden gepland.

Als je leveringsrisico in de roadmaps van andere teams zit in plaats van in je eigen code, dan is dat precies het soort traject dat ik gewend ben te leiden.