Bouwen aan klantgerichte teams

Algemeen

Bouwen aan klantgerichte teams

Alexander Vermeulen heeft aanzienlijke ervaring met het werken binnen Agile/Scrum teams. Voorheen vaak interne teams, maar tegenwoordig zijn het complete teams die specifiek voor één klant werken, waardoor de schaalbaarheid van IT wordt vergroot. Drie jaar geleden startte Alexander bij de Dienst Terugkeer en Vertrek (DT&V) als een van de smaakmakers in een compleet Agile/Scrum team. Daar vervulde hij eerst de centrale rol van Scrum Master en nu als business analist. Het team wordt ingezet voor de renovatie van een kernapplicatie in Microsoft .Net technologie. We gingen in gesprek met Alexander over zijn ervaringen met het werken in een dedicated team dat als dienst wordt aangeboden.

Vliegende start 

‘Om een team een vliegende start te geven in een nieuwe klantorganisatie maak ik gebruik van een onboarding-programma. Zo raakt het team snel vertrouwd met de IT-omgeving van de klant, waardoor ze naadloos kunnen integreren. Allereerst is het belangrijk dat de teamleden en de klantorganisatie kennismaken met elkaar. De basis voor een succesvol team is dat men elkaar kent en weet te vinden. Communicatie is de sleutel tot succes. In de onboarding vindt ook een rondleiding plaats en bezoeken we de werkplekken van gebruikers. Daarnaast bouwen we kennis op van de producten of diensten die de organisatie levert en welk proces daarvoor gebruikt wordt. Wat is het doel van de organisatie, waarom doen ze wat ze doen? Dit is belangrijk, want alleen zo kan het team meedenken met de product owner en andere stakeholders om waarde toe te kunnen voegen. Er zijn altijd enthousiaste mensen die hier graag over vertellen, naast dat er ook altijd wel informatie is om te lezen.’ 

Reliable scrum werkwijze 

Bij de onboarding wordt ook aandacht besteed aan het aansluiten van de werkwijze van het team op de werkwijze bij de IT-organisatie. ‘Als team zijn we ingewerkt op elkaar en volgen daarbij onze Reliable Scrum werkwijze. Bij de start passen we onze werkwijze in, in de werkwijze bij de klant. Denk hierbij bijvoorbeeld aan het aanpassen van de sprintduur, de sprintwisseldag. Ook stemmen we de Definition of Ready en de Definition of Done af met de Product Owner. Al deze zaken dragen bij aan een soepele start als team in een nieuwe klantomgeving.’ 

Van onboarding naar productief team 

 Een team heeft altijd een onboardingfase nodig om uit de startblokken te komen. ‘Afhankelijk van de grootte van de organisatie en de complexiteit van de processen, duurt dit een á twee weken. Daarna gaat het team meedraaien in het sprint-ritme dat bij de klantorganisatie gebruikelijk is. Onze Reliable Scrum werkwijze is erop gericht om productiviteit als kern van de rapportage te stellen. Vanaf de eerste sprint gaan we de productiviteit van het team dan ook meteen meten. Een team heeft altijd minimaal drie sprints nodig om te settelen. In deze periode wordt steeds meer kennis opgebouwd van de processen en hoe deze met IT worden ondersteund. Na drie sprints merk ik altijd dat de schattingen beter beginnen te worden en daarmee onze voorspellingen betrouwbaarder. Na drie maanden kan een team voorspelbare prognoses geven over de velocity van het team. De product owner kan dat gebruiken om de product backlog te organiseren en releases te plannen.’ 

"Ik maak het nogal eens mee dat de onboarding als een 0-sprint wordt ingezet"

Samenwerking binnen en buiten het team  

Binnen de agile werkwijze is dagelijks afstemmen een essentieel onderdeel van de samenwerking. ‘Ons team bestaat uit tien mensen met daarnaast nog de Product Owner en een Business Analist van de klant, dat is een heel fors team. Een duidelijke rolverdeling en duidelijk overlegstructuren zijn dan van groot belang. Alhoewel ik er altijd naar streef dat het hele team betrokken wordt in het beslissingstraject, moet het uiteindelijk helder zijn wie verantwoordelijk is voor het doorhakken van bepaalde knopen en het maken van keuzes. Het team kan er van alles van vinden, maar uiteindelijk liggen functionele keuzes bij de Product Owner en technische keuzes bij de lead-developer.’ 

 

Hybride samenwerking 

Als groot team is het ook belangrijk om afspraken te maken over hybride werken. ‘Bij DT&V hebben we ervoor gekozen om één dag per week als team live bij elkaar te komen. We noemen dat de ‘Samenwerkdag’. Deze dagen helpen mee om naast elkaar te zitten en een band met elkaar op te bouwen. Om goed samen te werken, hebben we een limiet ingesteld voor het aantal taken dat tegelijkertijd wordt uitgevoerd (WIP-limit). We werken met maximaal vijf taken tegelijk, waardoor minstens twee mensen aan hetzelfde item moeten werken. Dit bevordert samenwerking en kennisdeling, wat cruciaal is voor ons team, zeker omdat we veel vanuit huis werken.’ 

Teamwisselingen 

Het DT&V team bestaat al drie jaar, een periode waarin het onvermijdelijk is dat er wisselingen in het team plaatsvinden. ‘We zijn een groot team in een groot programma en als iemand het team verlaat is het belangrijk dat er tijdig een passend nieuw teamlid aansluit, bij voorkeur met een overlapperiode van één sprint. Ik let daarbij goed op of het teamlid past bij de rest van het team, terwijl de lead-developer controleert of de technische kennis en kunde matcht met wat we nodig hebben.’ 

 
Snel aansluiting vinden 

‘Als een nieuw teamlid aansluit, organiseren we daar ook een onboarding voor en vindt er een kennismaking plaats met de belangrijkste contactpersonen en de organisatie. Daarnaast hebben we in een wiki vastgelegd welke stappen allemaal nodig zijn om technisch aan te sluiten. Hier staat precies omschreven welke afspraken er gemaakt zijn, hoe je je ontwikkelmachine inricht en welke stappen bij oplevering van code genomen worden. Mijn ervaring is dat nieuwe teamleden met één sprint al productief worden en vanaf de tweede sprint volop meedoen.’ 

Afspraken over de resultaten 

 Door duidelijke afspraken te maken op de output, krijg je meer grip. ‘Word je als team beoordeeld op bestede uren in plaats van op de geleverde resultaten, dan is het lastig om te bepalen of de uren ook daadwerkelijk effectief zijn gebruikt, hoe volwassen je als team ook bent. Dit geeft de klant ook weinig controle over het resultaat, en daarom verkiezen wij voor het maken van afspraken over de resultaten. Hierdoor kunnen we flexibeler met team-bemensing omgaan. Garanties op de resultaten helpen om te beoordelen of het team op schema ligt. Afspraken over resultaten geven het team meer verantwoordelijkheid, omdat je dan niet wordt afgerekend op je inspanning, maar op het resultaat van je inspanning. Uiteindelijk draait het om de service die je levert.’ 

Extra Topbanner Image 04 (1)

Afspraken over het serviceniveau

Bij een ‘Team-as-a-service’ gaat het erom het juiste serviceniveau te behouden. Hiervoor is het belangrijk om duidelijke afspraken te maken over het serviceniveau. ‘Bij DT&V is de belangrijkste afspraak dat de opgeleverde functionaliteit voldoet aan de afgesproken Definition of Ready en de broncode kwalitatief op orde is. Het eerste wordt door de Product Owner gecontroleerd. Het tweede wordt bij DT&V vastgesteld door aan te tonen dat er 80% van de code door geautomatiseerde testen afgedekt is (Code coverage) en daarnaast dat de broncode een 4-sterren SIG-score heeft. SIG doet onafhankelijke code checks en geeft daaraan een score tot maximaal 5 sterren, waarbij 3-sterren markt gemiddeld is.’

Streven naar kwaliteit

‘Voor het ontwikkelteam leeft het werken van de functionaliteit altijd het meest. Dat heeft een direct relatie met het gebruik van de applicatie en over het algemeen positieve reacties van gebruikers. Het meten op de code kwaliteit wordt meer als een last ervaren. Uiteraard willen de developers graag nette code opleveren. Maar als het metertje dan zegt dat het net niet aan het beoogde niveau voldoet, dan wordt er wel eens ‘waarom’ verzucht. Dan is het van belang om het lange-termijn doel ook in beeld te brengen en af en toe ook met het team te vieren dat ze werkelijk een bijzonder goede prestatie leveren. Zo is het team ook echt trots op de award van SIG die we recent gekregen hebben, waarbij we onderscheidenlijk goede software maken binnen de Overheidsector.’

Roblipsiusxgaransys 0009 Marjon

Meer weten? Neem contact op!

Marjon van Schaik

Business Development
06-10922020
m.schaik@garansys.nl