Agile samenwerken met een serviceprovider: winst voor beide partijen

 
14 juli 2020

Tekst Erik Bouwer, Mark Koster

Agile doorvoeren in je eigen organisatie is uitdagend. Agile werken met je partners is de volgende uitdaging. Een gebrek aan aansluiting in werkwijzen kan de positieve effecten van agile volledig tenietdoen. Hoe zorg je er samen voor dat je de voordelen van agile werken realiseert? 

Agile werken begint over het algemeen binnen de IT-organisatie. Naarmate er meer volwassenheid is, wordt agile vaak ook door de business omarmd. Het doel: sneller innoveren, verkorten van de time-to-market en meer toegevoegde waarde leveren.

Realiseren van onderscheidend vermogen kan voor steeds meer bedrijven alleen nog over de as van data en software: door slim gebruik te maken van de juiste functionaliteiten van de belangrijkste businessapplicaties. Dat zijn vaak monolithische standaardapplicaties, waar bedrijven steeds meer puntoplossingen aan toevoegen met elk hun eigen integraties, API’s en widgets. In zo’n complex applicatielandschap hebben ondernemingen die wendbaar willen zijn, goede redenen om te kiezen voor de agile -methodiek. Uit de Giarte IT Experience Benchmark van dit jaar blijkt dan ook dat 74% van de onderzochte bedrijven transformeert naar agile werken in IT. Bij de agile -methodiek wordt bij iedere gezette stap (sprints waarin deelresultaten worden opgeleverd) duidelijk of er nieuwe toegevoegde waarde ontstaat. Het sturend vermogen is dus groter dan bij de watervalmethodiek, die dan ook steeds minder wordt gebruikt.

CIO’s en businessmanagers die over succesvolle agile teams vertellen, komen meestal met het plaatje van de kortcyclisch werkende, zelfsturende scrum teams die in een aantal sprints tot nieuwe functionaliteiten komen. In de agile aanpak worden ontwikkelteams niet afgeleid, maar juist gefaciliteerd door het management, hebben teams zeer heldere doelstellingen, hun eigen KPI’s en een eigen kalender. Met grote regelmaat kijken agile teams naar de tussenstand: zowel in stand -ups als in sprints. Het idee is dat er zo effectiever wordt gewerkt en dat er sneller relevante functionaliteit wordt opgeleverd die goed aansluit op de praktijk. Onderzoek laat zien dat agile werken de bedrijfsprestaties kan verbeteren. Agile organisaties hebben volgens Accenture1 een aanzienlijk hogere langetermijn-EBITDA-toename dan non-agile organisaties. En Harvard Business Review2 constateert dat bij agile organisaties zowel omzet als winst 60% hoger zijn dan bij non-agile organisaties. Deze organisaties ontwerpen, bouwen, testen en releasen zonder dat de bedrijfscontinuïteit in gevaar komt. En als er iets fout gaat, lost het team het zelf op.

Uitdagingen 

Bedrijven die met agile aan de slag willen, doen dit idealiter stapsgewijs binnen hun organisatie. Voor deze agile transformatie kunnen ze terugvallen op een enorme industrie aan adviesbureaus en coaches. Al bestaan er verschillende methodieken met elk een eigen jargon (denk aan begrippen als squads, tribes en scrum teams) en zijn er verschillende modellen voor zelforganisatie (zoals circles of cellen), Giarte constateert dat er in deze methodieken en modellen weinig aandacht is voor samenwerking met externe partijen zoals serviceproviders. Dat maakt voor bedrijven die in hun IT-voorziening samenwerken met serviceproviders de agile praktijk van alledag weerbarstig. De ervaring van Giarte is dat de huidige manier van samenwerken de agile transformatie niet goed faciliteert. Voor uitbesteders die agile werken én samenwerken met IT-serviceproviders, ziet Giarte uitdagingen op drie gebieden.  

1. Technologie
De kern van de digitale transformatie is dat software en data een steeds dominantere rol gaan spelen in met name het primaire proces van bedrijven. In sommige gevallen worden ze de drijvende kracht. Zo zijn bijvoorbeeld de investeerders van een vermogensbeheerder tegenwoordig data-analisten. Zij ontwikkelen modellen voor investeringstools die gebaseerd zijn op datamanagementsystemen. Het onderscheidend vermogen van zo’n vermogensbeheerder zit dus in het goed en snel ontwikkelen van software én in het combineren van software en data binnen het investeringsdomein – vandaar ook de naam van de sector: fintech.

Een uitbesteder die snelheid maakt en kortcyclisch nieuwe functionaliteit wil uitrollen, loopt in de praktijk tegen obstakels aan. Interne ontwikkelaars die hun nieuwe software willen testen maar niet over een eigen testomgeving beschikken, hebben vaak te maken met doorlooptijd bij de partij die het infrastructuurbeheer verzorgt. Omdat de werking van missiekritieke applicaties gegarandeerd moet blijven, stuiten nieuw ontwikkelde functionaliteiten op uitgebreide integratie- en acceptatietesten. Deze kunnen, in tegenstelling tot de snelle agile ontwikkeling van deelfunctionaliteiten, maanden in beslag nemen. Terwijl de verschillende scrum teams doorgaan met hun ontwikkelkalender, ontstaan er grootschalige releaseplanningen per kwartaal. Gevolg: de outcomes van de nieuwe functionaliteiten waar de business om vroeg, komen vertraagd tot stand. Iedere versnelling aan het begin eindigt in een vertraging aan het eind.

2. Het contract
Het contract is niet alleen de bezegeling van afspraken, het is ook het startpunt voor de samenwerking tussen uitbesteder en serviceprovider. De onderliggende mechanismen van de huidige contracten, schaalvoordeel en standaardisatie, zijn tegenwoordig echter alleen nog effectief voor de commodity-vormen van IT. Je kunt na een migratie naar de cloud misschien sneller op- en afschalen, maar daarmee ben je nog niet ‘digitaal getransformeerd’ en heb je nog geen agile ontwikkelfabriek. Contracten zijn qua termijn en scope overwegend gericht op output in plaats van op outcomes; de inzet van mensen staat primair in dienst van het laten werken van technologie ofwel vastomschreven dienstverlening. Daarbij is de scope gericht op veiligheid, gedegen beheer, compliance en kosten en leidt dit tot maandelijks rapporteren op SLA’s (service levelagreements). Deze manier van samenwerken paste goed in stabiele omgevingen waarin IT wordt beschouwd als een nutsvoorziening zoals gas, water en licht: het moet het gewoon doen. Bij aanvang van de samenwerking wordt in het contract vastgelegd wat de IT-provider nu, maar ook over drie jaar, precies moet gaan doen. Bij het merendeel van de contracten gaat het vooral om het verplaatsen van verantwoordelijkheden in plaats van het delen van verantwoordelijkheden.

Wanneer je een scrum team in een agile omgeving zou vragen of de leden zouden kunnen uitleggen wat ze over drie jaar precies gaan leveren, dan zal je vooral verbaasde gezichten aantreffen. Een langetermijncontract biedt over het algemeen weinig ruimte voor bijvoorbeeld flexibele scoping en voor business outomes in plaats van standaard output.

3. Samenwerking
De inhoud van het contract is in hoge mate bepalend voor de wijze waarop de samenwerking tot stand komt. Bij agile samenwerkingsverbanden staan snelheid, flexibiliteit en creativiteit voorop, in de vorm van een open scope, kortetermijnprojecten, en een sterke focus op het maken van (business-) impact. Veiligheid, gedegen beheer, compliance en kosten zijn belangrijk, maar dienen bij agile ook het doel om (naast een kostenefficiënte operatie) een solide basis te bieden voor doorlopend innoveren.

Bedrijven die hun IT hebben uitbesteed en agile als methode willen invoeren, zouden eigenlijk éérst moeten kijken naar de samenwerking met hun IT-serviceproviders. Snel innoveren gaat uiteraard beter als de IT-omgeving stabiel is, en als development en operations goed op elkaar zijn ingespeeld; idealiter is dat tweerichtingsverkeer. Daarbij is het de vraag in hoeverre de (externe) beheerorganisatie haar dienstverlening zo heeft ingeregeld dat scrum teams zelf het beheer kunnen doen. Als scrum teams niet de tools hebben om zelf te testen, zijn ze afhankelijk van de beheerorganisatie. Ze moeten dan testcapaciteit aanvragen, wat vaak gepaard gaat met een doorlooptijd van dagen bij de externe infrastructuurbeheerder. Terwijl de ontwikkelaars wellicht on the fly willen testen en geen tijd willen verliezen binnen een sprint. Dit geldt ook voor het beheer, waar scrum teams zelf de tools moeten hebben om de eigen applicaties te monitoren en zelf verantwoordelijk zijn voor de betrouwbaarheid van de eigen applicaties.

Giarte ziet overigens dat steeds meer serviceproviders hun werkwijzen hebben bijgesteld. Opvallend veel serviceproviders spreken van het optuigen van multidisciplinaire klantteams, soms gericht op segmenten, waarbij met name commercie (marketing, sales) en delivery meer samenwerken. Dat betekent echter nog niet dat er beslissingsbevoegdheid en commerciële verantwoordelijkheid op teamniveau is komen te liggen. Waar bij uitbesteders actief wordt gewerkt aan het creëren van T-shaped professionals, wordt dat nog gemist aan de zijde van de serviceproviders.

Er is dus in veel gevallen werk aan de winkel als het gaat om anders organiseren: dat vergt onder meer investeren in andere competenties, ook binnen de commerciële aansturing van serviceproviders. Bij Schuberg Philis en Sentia, bijvoorbeeld, zijn zowel de samenwerking als de onderliggende contracten flexibeler ingericht. Schuberg werkt met autonome cirkels, Sentia is gestart met het toepassen van vested outsourcing, waarbij het gezamenlijk opstellen en realiseren van een roadmap leidend is.

Andere kijk op missiekritieke applicaties  

Om versnelling mogelijk te maken, moeten organisaties op een andere manier omgaan met hun missiekritieke applicaties. Dit betekent een vernieuwende architectuur, andersoortige eisen aan deze applicaties, andere rollen voor de teams die met de missiekritieke applicaties werken en – vaak – een nieuwe manier van samenwerking met IT-providers die de kritische infrastructuur beheren. Wat kunnen organisaties, samen met de IT-providers, doen om de agile transitie te laten slagen?

1. Opbreken van monolithische systemen
Door grote monolithische systemen in microservices op te delen, worden systemen beter schaalbaar en onderhoudbaar. Bij de toepassing van microservices kunnen teams onafhankelijk van elkaar releasen en vervalt de noodzaak van releaseplanningen. Dat maakt het mogelijk om het aantal releases structureel te verhogen. Nieuwe functionaliteiten komen dus eerder in productie en businessresultaten worden sneller behaald, al neemt met grote aantallen microservices ook de complexiteit verder toe.

2. Creëren van veerkracht
Door ervoor te zorgen dat de microservices onafhankelijk van elkaar kunnen werken, leidt het falen van een individuele component niet tot een systeembrede uitval. Het voordeel is dat het totale systeem veel betrouwbaarder wordt, terwijl er een stabiele basis ontstaat die een hogere snelheid van innovatie aankan.

Inzichten over agile werken

Bedrijven die hun IT uitbesteden, zijn bij het realiseren van innovatiesnelheid in belangrijke mate afhankelijk van hun serviceprovider. Uit het onderzoek van Giarte blijkt dat van de organisaties die agile werken, slechts 27% dat gezamenlijk met de serviceprovider doet. Het merendeel van de organisaties neemt de serviceprovider dus niet mee in agile werken.

Verschillen tussen IT-domeinen 
Hierbij zijn er duidelijke verschillen zichtbaar tussen de domeinen applicatiebeheer en infrastructuurbeheer. Binnen contracten waar alleen applicatiebeheer wordt geleverd, wordt bij 77% van de onderzochte organisaties agile gewerkt; binnen infrastructuurmanagement is dat 55%. Dat verschil wordt nog groter als het gaat om de samenwerking met de serviceprovider. Binnen contracten waar alleen applicatiebeheer wordt geleverd, werkt 46% van de organisaties op een agile wijze samen met de serviceprovider; bij infrastructuurbeheer is dat slechts 2%.

Aansturing serviceprovider 
Uit verdere analyses blijkt dat bij niet-agile samenwerkingsverbanden het behalen van technische SLA’s de meest voorkomende vorm van aansturing van serviceproviders is. Hierbij zijn in ruim 81% van de contracten technische SLA’s opgenomen als stuurmiddel. Bij agile samenwerkingsverbanden is in 65% van de contracten sturing op budget en planning de meest voorkomendevorm van aansturing (tegenover 40% bij niet-agile samenwerkingen). Juist in agile samenwerkingsverbanden is sturen op business outcomes erg geschikt. Toch wordt bij slechts 34% van de agile samenwerkingen de serviceprovider op business outcomes aangestuurd. Dit is wel meer dan bij niet-agile samenwerkingen (14%).

Positieve bijeffecten
Wanneer er wel gezamenlijk agile wordt gewerkt – dat wil zeggen: medewerkers van de IT-serviceprovider maken deel uit van de scrum teams – blijkt dit zijn vruchten af te werpen. Agile samenwerkingen zijn vaker een goede deal voor uitbesteders dan niet-agile samenwerkingen. 35% van de organisaties die deze werkwijze aanhouden, is ‘superfan’ van hun serviceprovider, tegenover 17% van de organisaties die alleen intern agile werken. Het mes snijdt aan twee kanten: 1% van de organisaties die agile samenwerken met de IT-provider is ontevreden over de samenwerking, terwijl dat bij de organisaties die niet-agile samenwerken met de IT-provider op 7% ligt. Bovendien leidt de samenwerking waarin de serviceprovider en uitbesteder in een agile team zitten ook tot betere uitkomsten. 63% van de uitbesteders haalt een goede tot zeer goede ‘value for money’ uit de agile samenwerking, tegenover 47% bij een niet-agile samenwerking.

3. Automatiseren en nog meer automatiseren 
Door scrum teams te voorzien van tools waarmee zij het ontwikkelproces kunnen automatiseren, kunnen agile teams zelfstandig een idee naar de productie- en beheerfase brengen (DevOps). Ze kunnen bijvoorbeeld zelf testomgevingen opzetten, zelf software naar productie brengen en zelf realtime eigen applicaties monitoren. Door bijvoorbeeld de stap van acceptatie- naar productieomgeving in vergaande vorm te automatiseren, worden fouten voorkomen en teams in staat gesteld het zelf te doen.

Andere aansturing serviceprovider  

De uitbestedende partij zal de manier van aansturing van de serviceprovider moeten veranderen, zodat deze zich primair richt op het opleveren van (business) outcomes die toepasbaar zijn voor de IT-beheerorganisatie. De KPI’s veranderen dan en zijn bijvoorbeeld gericht op doorlooptijd in het testen, het aantal releases per dag en de kwaliteit, de tijdigheid en het gebruik van opgeleverde automatiseringstooling. Hiermee wordt het risico ook gedeeld in plaats van verplaatst. Lukt het de serviceprovider om een business outcome te realiseren of te verbeteren, dan wint zowel de serviceprovider als de uitbesteder. 

Andere rol van serviceprovider  

Ook de rol van de klassieke infrastructuurengineer en applicatiebeheerder verandert: in plaats van zelf de releasestappen uit te voeren en applicaties te beheren, verschuiven de taken van de engineer naar het ontwikkelen van release- en beheertools en het trainen van agile teams om deze tools goed te gebruiken. Dit vergt andere competenties bij de IT-provider, namelijk het kunnen ontwikkelen van automatiseringstooling op het gebied van testen, releasen en monitoren en het begeleiden van gebruikers van deze tooling.

Samen agile werken

Als je een product door een externe partij laat maken, is het ‘gezond-verstand-ondernemerschap’ dat je vooraf wilt weten hoe lang dat gaat duren, en wat het precies gaat kosten. Maar even belangrijk is dat je waar voor je geld krijgt – werkende software die bijdraagt aan de bedrijfsdoelstellingen bijvoorbeeld. Agile softwareontwikkeling begint bij vertrouwen. Je timmert niet vooraf alles dicht met strakomlijnde specificaties. Daar tegenover staat doorlopende betrokkenheid bij het proces en – het belangrijkste – de tussentijdse resultaten. Agile werkt goed als je in staat bent tot samenwerken. Uit gesprekken met Levi9 en NetRom, twee nearshore IT-dienstverleners die vrijwel altijd aan de hand van agileprincipes werken, valt op te maken dat er een paar succesfactoren zijn: 

  • de aanwezigheid van functiescheiding en een product owner;
  • het vermogen te kunnen denken in gewenste business outcomes;
  • de beheersing bij het bepalen van de omvang van sprints;
  • de bereidheid te leren (feedback gebruiken, vallen en opstaan);
  • het kunnen omgaan met weerstanden, loslaten van oude gewoonten.

Lees meer hierover in de interviews met Anamarija Petrovic (Levi9) en Han in ’t Veld (NetRom)

Teamsamenstelling  

Naast een stapsgewijze transformatie naar agile zijn er ook meerdere smaken als het gaat om de rolverdeling binnen een scrum team tussen de uitbesteder en de serviceprovider. Dit hangt af van de strategie van de uitbesteder: wil je zelf de ontwikkelcompetenties aan boord houden, dan is je rol in het scrum team het meest uitgebreid. Je besteedt dan bijvoorbeeld alleen testen en quality assurance (QA) uitMaar wanneer je optimaal wilt profiteren van schaalvoordeel, kies je voor het meest extreme geval waarbij alleen de product owner van de uitbesteder afkomstig is en zo zeggenschap behoudt over de agenda. Scrum master, businessanalisten, developers en QA-functionarissen zijn dan lid van de serviceprovider. De product owner is de link naar de business. Welke variant je ook kiest, het scrum team moet wel een team zijn waarin iedere speler hetzelfde teamdoel nastreeft.

Overgang naar nieuwe werkwijze  

Je kunt niet zomaar van de ene op de andere dag agile werken introduceren binnen je eigen organisatie. Ook het invoeren van agile werken in de samenwerking met de serviceprovider zal een stapsgewijs proces moeten zijn. Het begint bij het aangaan van het gesprek: duidelijk maken aan je partners dat je als uitbestedende organisatie kiest voor de transformatie naar agile. Het alternatief – aan het einde van het contract op zoek naar een partner die helemaal thuis is in agile – brengt hoge kosten met zich mee. Dit scenario is alleen aantrekkelijk als je toch al van plan bent om een contract niet te verlengen. Een tijdige aankondiging van je plannen maakt het ook voor de serviceprovider beter haalbaar om te gaan investeren in een ‘nieuwe’ werkwijze.

Een beproefde methode om stapsgewijs aan de slag te gaan met agile samenwerken is het in toenemende mate gaan belonen van je serviceprovider(s) op basis van teamprestaties, terwijl gelijktijdig het ‘time-andmaterial’-model dan wel ‘het-voldoen-aan-vaste-SLA-voorwaarden’-model wordt afgebouwd.

Een paar tips:
1. Begin bescheiden met kleinschalige hackathons – denk aan een productteam dat multidisciplinair is samengesteld uit medewerkers van uitbesteder en serviceprovider – die buiten de bestaande ‘time-andmaterial’-outsourcingovereenkomst vallen. Beperk je hierbij tot enkele sprints, waarin het doel is om zicht te krijgen op de belangrijkste doelen en KPI’s van het team. 

2. In de daaropvolgende tien sprints werk je op basis van de nieuwe KPI’s en introduceer je de nieuwe afrekenmethodiek die voor circa 30% is gebaseerd op performance-based contracting. Denk hierbij aan doelen zoals klanttevredenheid, teamsnelheid en het wegwerken van IT-debt.

3. In de laatste fase – na zo’n 12 tot 15 sprints – werk je toe naar agile outsourcing. Daarbij is het scrum team in control over de productie en wordt er volledig ‘afgerekend’ op KPI’s die met de teamperformance en de outcomes te maken hebben. Denk aan de ‘lead time for a change’, het aantal incidenten per release en de interne klanttevredenheid (zijn de scrum teams tevreden met de service en tooling die de serviceprovider biedt).

Succesfactoren  

Bedrijven die succesvol zijn in agile samenwerken, kiezen voor een gezamenlijke roadmap en maken hierover (contractuele) afspraken. Deze bedrijven laten de fixed scope los en zetten in op doorlopende aanpassing met de roadmap op de achtergrond. Een voorbeeld van een concrete aanpak is het gezamenlijk in kaart brengen van de belangrijkste pijnpunten, het gezamenlijk bepalen welke monolithische missiekritieke applicaties als eerste worden opgesplitst, het gezamenlijk definiëren van activiteiten die hiervoor nodig zijn en het gezamenlijk maken van afspraken over wie welke activiteit oppakt. Wordt een milestone op de roadmap eerder bereikt dan initieel ingeschat? Dan krijgt de IT-serviceprovider in ruil voor de toegenomen innovatiesnelheid een extra beloning voor zijn prestaties. Hierbij wordt ook voldaan aan een van de agile-principes, namelijk het delen van risico’s in plaats van het verplaatsen van risico’s – en het sturen op gezamenlijke resultaat in plaats van het sturen op operationele tussenuitkomsten. 

Noten
1. www.accenture.com/hu-en/insight-competitiveagility-index
2. www.hbr.org/sponsored/2018/03/survey-data-showsthat-many-companies-are-still-not-truly-agile