Veel organisaties hebben Agile geadopteerd in hun werkprocessen. Meestal op afdelingsniveau, maar steeds vaker ook over de gehele breedte van een organisatie. Uitgangspunt is dat het werk naar stabiele teams stroomt, die iedere iteratie werkend resultaat opleveren. Welke gevolgen heeft dit eigenlijk voor sourcing?
Moeten we sourcing überhaupt aanpassen op Agile? Waait deze trend niet gewoon weer over? Laten we daar beginnen. Overal wordt Agile te pas en te onpas genoemd. Iedereen werkt Agile of Scrumt op zijn eigen manier. Het wordt zoveel genoemd dat ‘scrummen’ bijna de lijst van jeukwoorden op kantoor heeft gehaald in 2016.
Die irritatie is begrijpelijk, aangezien de populariteit van Scrum ook voor veel losse flodders heeft gezorgd. Het is tegelijkertijd ook spijtig. Scrum is immers niet voor niets bedacht.
Dynamische maatschappij
Met een druk op de knop kunnen bestanden zo groot als een Ultra HD-film binnen enkele seconden met de andere kant van de aarde worden gedeeld. Nieuwe, populaire apps hebben miljoenen gebruikers binnen een paar uur. Zo snel hebben we het nog niet eerder meegemaakt, en ieder jaar zien we dat dit steeds sneller gaat en worden records na records verbroken. We nemen informatie steeds sneller tot ons en willen steeds vaker over nieuwe informatie kunnen beschikken.
Dit vraagt van organisaties om sneller en wendbaarder te opereren. Of een bedrijf daarin wil meegaan of niet, is eigenlijk helemaal geen keuze. Juist snelheid en wendbaarheid zijn de speerpunten van Agile: kortcyclisch door stabiele teams constant werkende resultaten opleveren. Agile lijkt daarmee de sleutel om succesvol in een dynamische wereld te opereren. Maar wat betekent dit dan voor sourcing?
Agile werken betekent een verschuiving van het individu naar het team. Een team dat stabiel is, bereikt meer, groeit met elkaar, wisselt kennis met elkaar uit en verbetert iteratie na iteratie. De focus ligt op het versterken van het geheel. We brengen niet langer mensen naar het werk, maar werk stroomt naar teams die het succesvol tot resultaat brengen.
Dit is fundamenteel anders dan uurtje-factuurtje werken met individuen en kijken wie wat kan oppakken. Daardoor wordt het wisselen van teamleden een gevaar voor de stabiliteit van het team. Het schuiven in de teamcompositie kan eigenlijk niet meer.
Productimpact
Naast de focus op teams vindt er nog een verschuiving plaats. Zo richten we ons niet langer op de procesvoortgang maar op de impact van het product. Het is het resultaat dat leidend wordt. Ook dit is anders in de sourcingspraktijk. Het lijkt misschien mee te vallen, die invloed van Agile op sourcing. Er wordt immers gewerkt met teams waar gewoon mensen voor worden ingehuurd. En uiteindelijk is het alsnog een kwestie van het uurtarief doorberekenen, toch? Maar zo makkelijk is het niet. Een aantal voorbeelden uit de praktijk.
1. Tariefsverhoging bij teamstabiliteit
Veel opdrachtgevers vragen hun leveranciers om lagere tarieven bij een contractvelenging. Dit klinkt misschien logisch, maar wanneer je bedenkt dat Agile uitgaat van stabiele teams, dan ontstaat er frictie. Scherpere tarieven geven aanleiding om goedkopere krachten toe te voegen aan een team en ‘dure’ medewerkers naar een ander team over te zetten. Dit gaat ten koste van kennisoverdracht en borging van stabiele Agile-teams. Dus bij stabiele teams is tariefsverhoging veel logischer. Leg dat maar eens uit aan de inkoopafdeling.
2. Outcome-verantwoordelijkheid is lastig
In de praktijk vindt er een verschuiving plaats van een inspanningsverplichting naar een resultaatverplichting gericht op de outcome: de impact van het product. Deze verplichting is echter niet contractueel vast te leggen, omdat de leverancier daar niet de directe verantwoordelijkheid voor kan nemen. Daardoor zie je echter een morele verplichting ontstaan op de outcome, wanneer een samenwerkingsrelatie gebouwd wordt rond deze impact.
3. Single-supplierteams/ketens maakt afhankelijk
Steeds vaker worden teams gevormd met verschillende, externe experts. Maar daar schuilt een gevaar: het is immers niet wenselijk om een team te bouwen van verschillende partijen die elkaar de schuld geven over het niet bereiken van resultaten. Bouw daarom teams met specialisten van één leverancier. Door dit te doen ontstaat er verantwoordelijkheid bij de leverancier voor het resultaat. Steeds vaker zien we single-supplierketens, waarbij de hele keten ondergebracht wordt bij één leverancier. En ja, dit levert een grotere afhankelijkheid op van deze leverancier, maar wel meer impact op het resultaat.
4. Exit-gedreven contracten zijn geen geëffend pad
Agile gaat uit van een werkend product dat ook af is. Daarbij is het niet gek om op ieder gewenst moment te kunnen stoppen. Een nieuwe vorm van contracten is daarmee geïntroduceerd. Er wordt van deze exitmogelijkheid echter vaak geen gebruik gemaakt; er wordt juist nieuw/ander werk naar de teams gebracht, de scope verandert daarmee. Dit in contracten vastleggen is nog geen geëffend pad.
5. Extra kosten voor reizen en contact zijn ongewenst
Vooral wanneer teams werken over verschillende landen heen ontstaat een nieuwe uitdaging. Een van de randvoorwaarden van agility is samenwerking en kennisoverdracht, face-to-face bij voorkeur. Wanneer vanuit kostenoverwegingen werk naar het buitenland wordt uitbesteed, kan het tot frictie leiden dat er ook geld aan reizen uitgegeven moet worden.
6. Agile vervaagt de traditionele klant-leverancierrelatie
Agile verandert de denkwijze, en daarbij komt alles ter discussie te staan. Van individu naar team, van proces naar outcome. We kunnen stellen dat sourcing sterk aan het veranderen is. Het gaat namelijk niet meer om het bemensen van een project (inspanningslevering) maar om de outcome (meetbare businessresultaten). En mensen zijn geen resources, maar komen ieder met eigen nukken, kwaliteiten en gebruiksaanwijzing.
Om succesvol te zijn moeten teamleden elkaar vooral leren kennen en voor verandering openstaan. Misschien kunnen we sourcing daarom beter ‘teaming’ noemen?
Door Rini van Solingen, CTO bij Prowareness en deeltijdhoogleraar aan de Technische Universiteit Delft.
