Leestijd is 7 minuten
Agile werken en Outsourcing
het kan wel maar is vaak een rampzalige combinatie
Voor veel organisaties is Agile werken en Outsourcing geen issue, omdat Agile werken er beperkt blijft tot software ontwikkeling. Maar in toenemende mate passen vooruitstrevende bedrijven dezelfde Agile benadering ook toe in andere takken van sport.
Ze implementeren deze technieken in andere product- en dienstenontwikkelingen en zo worden ook uitbestede diensten geraakt.
Wanneer bedrijven echt in hun hele organisatie Agile werken toepassen, beloven Agile protagonisten dramatische verbetering in de werkwijze van die organisatie.
Aantoonbaar is dat toepassing van de echte Agile benadering bevorderend werkt voor de samenwerking over afdelingsgrenzen heen, voor de creativiteit en efficiëntie.
Echt Agile werkt ook beter dan de karikatuur die men van de zogenaamde ‘Waterval’-methode of van de PRINCE2 methodiek heeft gemaakt.
Schijn bedriegt
Agile werken zoals wij dat in de praktijk zien, past nauwelijks in grote en complexe organisaties. Ook al lijkt het succesvol, schijn bedriegt.
Wat er gebeurt, is dat organisaties achter adviesbureaus (consultants) en de door hen ontwikkelde methoden aan hollen en zogenaamde Agile modellen gaan toepassen.
We noemen die methoden AINO. Agile In Name Only. Die benadering werkt helaas alleen op de korte termijn en niet op de lange duur.
Wat is echte Agile? Wat is de zogenaamde Agile die we meestal zien? Wat maakt de combinatie Agile werken en Outsourcing zo moeizaam? Hoe kan het wel werken?
Een praktijkvoorbeeld, de ING-bank App
Uitzondering hierop is het als betrokkene al volop in de publiciteit staan of hebben gestaan of hebben meegewerkt aan publicatie. Deze gids biedt een blik achter de schermen van Outsourcing. We hebben alles wat mogelijk is in het werk gesteld om een onafhankelijke en objectieve blik op de werkelijkheid van dit voorbeeld te bieden. |
Het is ons beleid om altijd namen van organisaties en mensen in onze publicaties anoniem te maken.
De ING-bank App (of RABO App en heel veel andere apps) op mijn mobieltje wordt soms bijna wekelijks geüpdatet. Wij vinden dat al normaal.
Maar dat is het niet! Het moet omdat het product vol fouten, datalekken en security lekken zit.
Wekelijks vindt men weer zo’n fout en moeten al die honderdduizenden gebruikers weer een geüpdatete App laden in hun telefoon. Soms zit er ook een nieuwe functionaliteit bij zo’n update, maar meestal is de update er alleen om fouten op te lossen.
Buiten ICT kan dat niet
Stel je voor dat je een nieuwe auto koopt en dat die jaar in, jaar uit wekelijks voor een probleem terug naar de garage moet! Hoelang accepteer je dat? Waarschijnlijk gaat die autofabrikant snel failliet.
AINO adepten zullen nu tegenwerpen dat in de traditionele software ontwikkeltrajecten ook veel fout ging. Zij hebben gelijk. De ICT branche heeft geen trackrecord van betrouwbare resultaten, al zijn die er wel. Maar die trekken minder publiciteit.
En het kan natuurlijk best. Net zo goed als de auto-industrie het kan, kan het ook in de ICT.
Het probleem met de huidige praktijk van zogenaamd Agile, AINO werken is dat alleen tijd en geld worden gefixeerd.
Het effect is dat er wel sneller en meer frequent wordt geleverd, maar dat het veel langer duurt voor er eindelijk iets echt kwalitatief goeds en bruikbaars wordt geleverd.
Het is een ‘quick and dirty’ aanpak.
Agile In Name Only, meer een religie dan een nuttige praktijk
Probeer eens iemand te vertellen dat je twijfels hebt over Agile werken. Je wordt dan al snel aangekeken met een blik van: ‘Kun jij nog wel met je tijd meekomen?’
Wat kan er nu mis zijn met ‘snel’ en ‘flexibel’ resultaat waar ook nog de echte business stakeholders bij betrokken zijn? Met snel en flexibel is niets mis, maar wat misgaat, is het gemis aan kwaliteit en voorspelbaarheid en echte business betrokkenheid.
Wat ook misgaat, is dat het Agile Manifesto gehanteerd wordt zoals veel mensen de bijbel hanteren.
Ze praten erover, maar ze hebben het niet echt gelezen.
Slechts een kleine minderheid leest het echt van begin tot einde, en nog een kleinere minderheid past het Agile Manifesto ook echt toe. Wat dat betreft is er weinig veranderd sinds twintig jaar terug (1997) PRINCE2 werd geïntroduceerd en iedereen dat ineens ging toepassen.
Deze intrinsiek goede methodiek werd ook door de ICT branche verhaspeld. PINO was het gevolg (Prince In Name Only).
Het belang van de ICT branche
Voor die verhaspeling bestaan goede redenen. Een projectmanager die de PRINCE2 methode toepast, richt zich op de effecten die het resultaat moeten zijn van projecten.
De klassieke ICT benadering richtte zich meer op opleverresultaat. PINO doet dat ook en zie, Agile en Scrum, zoals ze nu worden toegepast, doen dat ook. Het gevolg: operatie geslaagd, patiënt blijkt na enige tijd toch overleden.
In plaats van sturen op de langetermijnresultaten en -effecten (de Business Case) stuurt men op de kortetermijnoplevering van het project. PRINCE2 eist dat een project door de klant bestuurd moet worden.
Dit was en is niet in het belang van de ICT branche en daarom ‘vergat’ men dit snel.
De misvatting die bij Agile optreedt
Je denkt waarschijnlijk: Agile is snel en flexibel. Je hebt veel sneller dan bij de traditionele ontwikkelmethoden een product beschikbaar.
Dat moet de ICT branche pijn doen. Snellere oplevering is minder declarabele uren, is minder inkomsten. En dus voor ons als uitbesteder veel goedkoper!
Niets is minder waar!
Denk eens aan al die herstelacties, updates en fouten die na een AINO ontwikkeling volgen en die keer op keer weer moeten worden opgelost.
AINO, zogenaamd Agile werken, verkoopt lekker, het klinkt bestuurders als muziek in de oren, maar het is in werkelijkheid een nieuwe goudmijn voor de ICT branche.
De schijn van klant/gebruikers aan het stuur
Wat we vandaag zien, is weinig Agile en veel AINO. Het lijkt hierbij of de klant, de product- of diensteigenaar aan het stuur zit, maar dat is schijn. Deze organisaties kennen geen echte producteigenaar, geen eindverantwoordelijke manager meer.
Bij organisaties zoals ING en Achmea, organisaties die grootschalig met AINO werken, kent men vaak wel een chapter lead (functioneel manager) of een tribe lead (sectiecoördinator) en er is een coach die op een of andere manier veel sprint teams begeleidt.
En ieder sprint team wijst een producteigenaar aan. Die naamgeving is het toppunt van window dressing. Zo’n teamlid kan wel proberen de rol van producteigenaar te vervullen, maar hij is geen producteigenaar en hij heeft nauwelijks macht om echt te sturen.
Hij heeft ook geen enkele invloed op wat zogenaamde producteigenaren in andere sprint teams voor koers varen. En zo ontstaat er een lappendeken van deeloplossingen zonder overall visie of structuur.
Wat je ziet
Wat je ziet, is het sociale model van een disfunctionele organisatie zonder een goed gedefinieerde hiërarchie. Als je wilt ervaren waar dat toe leidt, ga dan binnen zo’n organisatie eens op zoek naar een eindverantwoordelijke.
Iemand die aanspreekbaar is op het hypotheekproduct, een verzekeringsproduct of bijvoorbeeld je salarisrekeningen. Iemand met voldoende gezag en macht om het verschil te kunnen maken!
Ik wens je veel succes.
Wij kennen Service Managers en Demand Managers die gek worden van deze ongestuurde chaos waarin niemand echt verantwoordelijk en aanspreekbaar is.
Als je echt door alle verkoopverhalen heen wilt prikken en testen of het werkt, bel zo’n organisatie dan op en vertel ze een klacht of een probleem met hun dienst of product.
Als het heel moeilijk is om iemand aan de telefoon te krijgen die iets met jouw klacht kan, of als je wel mensen spreekt, maar ze kunnen je klachten niet oplossen, dan weet je hoe het zit. Het werkt niet.
Een probleem overigens dat je ook wel bij organisaties tegenkomt die niet claimen Agile te werken, maar dit terzijde.
Hoe ziet AINO, Agile In Name Only, eruit?
De bijgaande figuur geeft weer zoals het meestal werkt.
Een dienst- of producteigenaar maakt een geprioriteerde wensenlijst. Dit noemt men de product- of de diensten-backlog (werkvoorraad).
Men formeert een multidisciplinair team en organiseert een sprint planning. Tijdens de sprint planning trekt het team een klein onderdeel van de werkvoorraad naar zich toe.
Dat is vanaf dat moment de sprint backlog (sprint werkvoorraad). Vervolgens besluit het team hoe die werkvoorraad binnen het team wordt verdeeld en opgepakt.
Het team heeft een bepaalde tijd – een sprint (meestal één tot vier weken) – om zijn werk te voltooien. Elke dag wordt de voortgang ervan besproken (dagelijkse Scrum).
Binnen het team is één persoon de scrum master. Die persoon zorgt ervoor dat het team op het afgesproken resultaat gericht blijft.
Aan het einde van de sprint behoort het werk opgeleverd/overgedragen te kunnen worden: klaar om naar een klant te gaan, op voorraad te leggen of de werking aan een belanghebbende te demonstreren.
De sprint eindigt met een sprint review (evaluatie van werkwijze en resultaat).
Zolang de product- of diensten-backlog gevuld is en de eigenaar budget heeft, kan er nu een nieuwe sprint worden gestart. Het team kiest opnieuw een binnen de toegemeten tijd behapbare brok werk en begint een nieuwe sprint.
Leuk en motiverend
Deze werkwijze kan afhankelijk van het karakter van de deelnemers leuk en motiverend werken. De werkwijze is ook zeer geschikt om toe te passen bij crisissituaties die om een snelwerkende oplossing vragen.
Situaties waarbij het betere de vijand is van het goede. Oplossen van het probleem is dan prioriteit nummer één.
Een nette oplossing die op de langere termijn ook goed werkt en geen vervelende bijverschijnselen heeft, is dan van later belang.
Maar businesswise kleven er toch wat beperkingen aan als je deze werkwijze structureel gaat toepassen.
Er dreigt een lappendeken van subdiensten of producten te ontstaan die samen niet een fraai totaalproduct omvatten.
Deze werkwijze heeft weinig te maken met Agile werken en is Agile In Name Only (AINO).
In het geval van Outsourcing, uitbesteed werk, is Agile werken praktisch onmogelijk. AINO werken lijkt mogelijk, maar daarmee loop je tegen heftige beperkingen op.
1. Het probleem van de lappendeken
Het gevolg van de huidige zogenaamde Agile aanpak is een lappendeken van deeldiensten en -producten die samen geen goed functionerend totaalplaatje opleveren.
Veel kleine projecten zonder samenhang die in de ICT worden gemaskeerd met een gelikte presentatie. Het ziet er mooi uit. Maar in complexe projecten werkt het niet.
Maar zoals al eerder gezegd: een mooie auto die iedere week naar de garage moet wegens gebreken, die verkoopt niet lang!
Een hypotheekafhandeling die weken op zich laat wachten omdat het mee verkochte verzekeringsproduct niet samenwerkt met het hypotheekproces, gaat geen succes worden (en vervolgens verliest men marktaandeel).
Een echte projectaanpak met samenhang verdient daarom de voorkeur.
2. Agile In Name Only. Wat is Agile dan wel?
Agile is geen methodiek. Het is een set van waarden en principes over werken en samenwerken in een organisatie.
Agile ontstond in de website-ontwikkelbranche. De benadering heeft waarde bij het omgaan met klanten die niet weten wat ze willen. Websitebouwers kunnen dan kiezen uit twee opties.
De eerste optie is het om de klant te gaan managen: maak een schets van de vage verwachtingen van de klant en bouw op basis van die schets een website.
Accepteer dat die schets nooit in één keer voldoet, vraag een redelijke vergoeding voor correctiewerk (noem het een update) en bouw in plaats van een relatie als opdrachtnemer een relatie van partner in business op.
- De tweede optie is het accepteren van wangedrag van klanten en je werkstroom afstemmen op de mogelijkheden en de onmogelijkheden van de klant. Zo ontstond Agile.
Deze video van Mark Shead legt in twaalf minuten perfect uit wat Agile werken echt is.
3 Agile werken en Outsourcing
Waarom vormen Agile werken en Outsourcing een rampzalige combinatie?
Zoals de video liet zien, kun je bij Agile werken de methode van werken niet van de ene groep aan de andere groep overdragen. Iedere groep vindt zijn eigen methodieken op basis van de groepswaarden en behoeften.
Als je nu binnen jouw organisatie bepaalde taken, functies en werkzaamheden hebt uitbesteed en je hebt die functies nodig binnen een sprint team?
Je kunt natuurlijk van je leverancier eisen dat hij de benodigde specialisten aan jullie afstaat, naar jullie detacheert, zodat ze in het sprint team kunnen participeren.
Daar kleven gelijk drie problemen aan:
Die specialisten zijn schaars. Ook je leverancier heeft er maar enkele van beschikbaar en dit zijn drukbezette mensen die bijna altijd in meerdere projecten en meerdere klantteams worden ingezet.
Zo’n specialist kan daarom niet zomaar naar één klant worden gedetacheerd.
Die specialisten zijn duur. Die detachering gaat jullie veel geld kosten. Meestal is het budget daarvoor niet toereikend.
De leverancier lost deze twee problemen op door een andere en goedkopere medewerker te detacheren.
De oplossing die een sprint groep bedenkt en bouwt, zal een deeloplossing bij de leverancier tot gevolg hebben. Daar moet dus die oplossing ook worden geïmplementeerd.
Maar past de gevonden oplossing in de infrastructuur van de leverancier? Daar heeft het sprint team niet naar gekeken (en niet de deskundigheid voor in huis want die was te duur!)
De oplossing die leveranciers bieden
Leveranciers worstelen natuurlijk ook met deze uitdaging en sommigen van hen hebben daar een oplossing voor gevonden.
Zij organiseren de sprint en betrekken daar medewerkers van de klant bij.
Op die wijze kunnen ze hun infrastructuur beschermen en toch tegemoetkomen aan de klantwens om Agile, snel en flexibel en goedkoop te werken.
Zoals we al eerder zagen, snijden zij daarmee niet in eigen vlees. Er zal nog veel update- en herstelwerk voor hen volgen.
Conclusie over Agile werken en Outsourcing
Agile werken en Outsourcing een rampzalige combinatie? Een mode die net zoals de PRINCE2 mode en daarvoor de SDM mode wel weer overwaait?
Agile werken dat zich eenzijdig richt op tijd- en geldfixatie werkt niet, zagen we.
In product- en dienstenontwikkeling, een activiteit waarbij Outsourcing leveranciers een bijdrage in de ontwikkeling moeten leveren, werkt het helemaal niet.
De PRINCE2 aanpak, de echte en niet de PINO aanpak waarmee de ICT sector er een farce van maakte, biedt het meeste kans op succesvolle samenwerking tussen uitbesteder en leverancier.
Met deze aanpak zit de uitbesteder, de Regisseur / Demand Manager, echt aan het stuur en wordt er gewerkt aan resultaten en effecten die ook op langere termijn standhouden.
Geen openeindregeling, maar een business case die gerealiseerd wordt.
Net zoals in het verleden bepaalde SDM methoden met succes binnen de PRINCE2 aanpak zijn geïntegreerd, kunnen nu ook bepaalde Agile elementen hierin worden verweven.
Een probleem dat met geen enkele methode wordt opgelost, is het probleem van opdrachtgeverschap. Uitbesteders die Regie en Demand Management verwaarlozen, raken echter met de huidige Agile praktijk nog verder in de problemen.
De eindvraag is: wil je meewaaien met de laatste managementmode en -gril of wil je werken aan serieuze business resultaten, niet alleen gericht op volgende week, maar ook op langere termijn?
Jouw antwoord op succesvolle Agile Silicon Valley stories
Steve Jobs startte het project voor de ontwikkeling van de iPhone (Project Purple 2) in februari 2005. De eerste prototypes werden al in de zomer van 2006 getest. Jobs vond dat ze nog onvoldoende kwaliteit hadden.
Jobs wees de team-ontwikkelgedachte (kern van de sprint/scrum benadering) af.
Hij verafschuwde de suboptimale eigenschappen die een dergelijk proces kan veroorzaken als gevolg van het compromissen sluiten tussen de eisen en standpunten van de verschillende deelnemers.
Hij stelde zich op als de enige echte producteigenaar en besloot in zijn eentje wanneer de iPhone marktrijp was.
De launch was in juni 2007 en niet eerder dan wanneer het product, in de ogen van Jobs, perfect was.
-
Koos Overbeeke
September 2018. Nawoord bij Agile werken en Outsourcing
Agile en reorganisaties brengen ING naar rand van de afgrond
ING betaald boete van ruim € 700.000.000,- voor falende bedrijfsvoering
De kruitdampen ING zijn weer opgetrokken. De CFO en de CIO verlaten het bedrijf na het bekend worden van het witwasschandaal en een ongekend hoge boete.
De banklicentie heeft even ter discussie gestaan maar l'histoire se répète en weer blijkt dat een bank zoals ING ‘too big to fail’ is.
Bewezen is dat de ING Agile aanpak commercieel en bedrijfseconomisch succesvol was maar tevens ernstige schade heeft veroorzaakt aan een solide bedrijfsvoering.
Alle tijd vergende impact analyses die in de afgelopen jaren zijn overgeslagen zullen nu alsnog nodig zijn om die bedrijfsvoering weer op het gewenste niveau te krijgen.
Dat er in de afgelopen jaren ook veel reorganisaties waren en afdelingen zijn opgeheven heeft ook veel impact gehad en het Agile werken nog risicovoller gemaakt dan het al was.
Mensen zijn zijn de weg in hun eigen organisatie kwijtgeraakt. Structuur en processen veranderden continue waardoor er elke keer weer een periode was waarin iedereen met elkaar de samenwerking weer moest gaan vinden.
En oude wijsheid doet opgeld en is met het ING debacle weer eens bewezen. Als iets te mooi lijkt om waar te zijn is het ook bijna altijd te mooi om waar te zijn.
De Agile belofte zoals ING en anderen hem toepasten brengt op de langere duur bedrijven naar de afgrond.
Overigens heeft ING van haar fouten geleerd.
Er is nu een praktijk ingericht met DevOps en daarmee zijn de meeste AINO problemen opgelost.
Gerelateerde informatie bronnen bij Agile werken en Outsourcing
Tweedaagse training Sourcing, Regie en Demand Management
Terug van Agile werken en Outsourcing naar Contrair denken