Case: Hur vi bände in ett agilt arbetssätt i ett befintligt fastprisavtal

Det är inte alltid man kan sätta ramarna för arbetet från start. Därför är det intressant att lära sig hur man gör i det fall det finns avtalsförutsättningar satta på förhand.

Ett större svenskt försäkringsbolag tog hem outsourcad utveckling från Indien och stöpte om sina avtal med Agila arbetssätt i fokus. Efter bara fyra månader hade ledtiden minskat med 50%, storleken på en förändring sjunkit med 50% detta skall jämföras mot en kostnadsökning på 15%. “Easy trade” enligt Tobias Ladhe.

Kristofer Forsmar t.v och Tobias Ladhe t.h

Berätta lite om dig/er?

Mitt namn är Tobias Ladhe, jag arbetar idag som Agil Coach hos Spring.se. Det skall dock nämnas att resultatet ni läser om är frukten av många personers goda jobb, teamwork helt enkelt. Framförallt kan nämnas oss på Spring, Kristofer på ToAgree.se samt försäkringsbolaget.

Vem är jag? Jag är framför allt är jag en passionerad produktutvecklare och entreprenör med lång erfarenhet från försäkringsbranschen.

År 2000 startade jag och några kollegor ett mjukvarubolag som utvecklade produkter anpassade till en ny standard för hur man skickar data för pensioner. Detta var något som existerande försäkringssystem inte klarade vid den tiden. Försäkringsbolaget blev en av våra kunder.

Vägen till förändring i avtal som vi strax skall utveckla, inleddes med att vi i början av 2010-talet byggde om ett kärnsystem för tjänstepension.

Vi byggde det med stöd av Agila metoder, med 5 lokala utvecklingsteam. Resultatet blev fantastiskt, vi gick under budget och levererade innan tidsplan. En detalj var att vi satsade på testautomatisering och när vi närmade oss ”färdigt”, hade vi en testtäckning för klienten på närmare 80%. Utan det hade vi aldrig lyckats! Sammanfattningsvis kan man säga att försäkringssystemet var i ett bra läge 2012

Sedan började outsourcingvågen.

Spolar vi fram till 2017 insåg försäkringsbolaget att detta inte levererade och kontaktade oss för att se vad vi kunde göra i den situation de hade hamnat i. Det är där denna historia börjar.

Hur vi insourcade (och återskapa teamet)

När vi analyserade läget 2017 var det bekymmersamt. Försäkringsbolaget hade tappat många utvecklare som satt på kärnkunskap. I och med outsourcingvågen hade flera gått till underleverantörer och hade börjat säga upp sig. Testsviten som fanns 2012 var borta.

En annan udda observation från verksamhetens perspektiv, var att ansvaret för deras IT var så fragmenterad och uppdelad att ingen kunde ta ett bra ägandeskap för helheten längre.

Situationen var prekär.

Vad var de första stegen?

Vi var tidigt på det klara med att flera saker snabbt behövde komma på plats:

  • Samlokalisering mellan verksamhet och utvecklingsteam
  • Team som tog ansvar för både utveckling och förvaltning. Det skulle finnas ett gotoställe för att få saker levererade
  • Yrkesstolthet, att känna att jag gjort något bra behövde få tillbaka.
  • Att vi fick nyckelkompetens, från försäkringsbolaget, från leverantören samt de på stan som var med under resan 2010-2012 att vilja stanna bidra till vårt nya satsning
  • Att försäkringsbolaget återtog styrning och ledning för effektmålen

Vi började med en kompetenskartläggning och testade tidigt tankarna på ett antal utvecklare vi behövde få med oss. Vi fick positiva signaler, tex. fick vi utvecklare som tidigare skickat in sina avskedsansökningar, att dra tillbaka dem.

Nu återstod “bara” att navigera vår strategi genom en myriad av detaljer i existerande avtal som fanns mellan försäkringsbolaget och leverantörerna.

Inte helt enkelt kan jag gissa?

Nej, processen tog defacto ett helt år. Vi hade starkt stöd från verksamheten att hitta en väg framåt, vi mötte aningen oväntat motstånd i tre vågor på vägen:

  • Första vågen – IT. Olika delar av IT’s verksamhet trodde fortfarande starkt på sin strategi.
  • Andra vågen – de outsourcade leverantörerna. De blev oroade när de förstod vad som var på väg att hända
  • Tredje vågen – interna processen och förvaltningsmodell. Ett ansvarigt team passade inte med defaultmallen som fanns från ITIL, PM3.

En kärnutmaning var att vi behövde skifta samverkansform med de leverantörer vi hade, trots att deras kontrakt styrde mot något annat.

Inte helt lätt – hur gjorde ni det?

Steg för steg är svaret.. Vi försökte hitta pragmatiska lösningar och anpassa avtalet därefter. Det var ett jättejobb, men blev bra till slut.

Låt mig ge ett axplock av saker vi ändrade:

Eliminierade SLA’er

Vi ersatte hårda SLA’er för olika delmoment i utvecklingsprocessen (vilka var kopplade till straffavgifter) med ett tydligt ägandeskap hos teamet.

Ett annat viktigt skifte värt att nämna var en betoning på helhetsansvar. Det fanns ingen separation mellan utveckling och förvaltning i vår modell. Detta var ett paradigmskifte som underlättade kommunikationen och ansvarskänslan mot verksamheten.

Slutligen, för att kunna säkerställa samverkansformen behövde vi göra oss av med kortsiktiga incitament. Vi bestämde oss, helt sonika, för att stryka en majoritet av SLA’erna från de befintliga avtalen. Detta löstes ‘pragmatiskt’ genom att vi ändrade inte huvudavtalen utan istället lade till en bilaga där SLA’er ströks för just vårt team.

Skifta leverantörerna till kompetensförsörjare

I de gamla avtalen hade leverantörerna ansvar för leverans och därmet också för styrning och ledning. Vi skiftade detta i ett slag genom att vi tog över ansvaret för styrning och ledning av teamet.

För att detta skulle fungera behövde leverantörernas roll skifta, till att börja verka som kompetensförsörjare istället. Det betydde också att avtalen behövde medge att vi kunde plocka kompetenser från där vi behövde. Vi var tidigt öppna i vår kommunikation med leverantören att teamen behövde vara tvärfunktionella, dvs i varje team skulle det kunna komma finnas medlemmar från fler leverantörer, och från verksamheten.

Vi hade nu banat väg för att team skulle kunna ta ett helhetsansvar.

Vad gjorde ni för att övervinna internt motstånd inom försäkringsbolaget?

Jag nämnde tidigare att vi hade tre vågor av motstånd. En av dessa var försäkringsbolagets befintliga processer och rutiner, som inte var kompatibla med sättet vi ville jobba. Exempel på dessa var:

PM3

PM3 delar upp ansvar mellan utveckling och förvaltning. Det gick stick i stäv med vår approach och vår vilja att ta helhetsansvar. Vår lösning blev att för allt under taktisk nivå i PM3 (det PM3 kallar objekt dvs grupper av system) så fick det agila teamet mandat att hantera.

“IT – Rör inte vår leverantör”

När det blev klart att vår ändrade strategi skulle påverka relationen med de existerande leverantör och dess avtal mötte vi till vår förvåning motstånd från IT. Deras utgångspunkt var: “rör inte vår leverantör”. Oron uttrycktes i osäkerhet i vad som skulle hända i andra system när vi uppdaterade vårt. Vägen runt blev att inte riva upp huvudavtalet utan att bilagor för just vårat projekt. När det kom på plats så minskade oron och vi gick grönt ljus att fortsätta.

En positiv sidoeffekt som detta har fört med sig, är att idag finns det en differentiering i sourcingstrategin, där olika behov bemöts på olika sätt. Det medges idag upplägg från ren outsourcing till Agila team. Vi banade helt enkelt väg för denna differentiering.

När ni nu hade löst de viktigaste knutarna, satte ni då några effektmål för ert arbete?

Ja! De effekter vi var ute efter och valde att prioritera var:

  • Säkra leveransen
  • Korta time to market
  • Skapa Effektiva samarbetsformer (tex mellan IT och Verksamhet).

Så, nu var förutsättningarna satta. Hur kickstartade ni sedan teamen?

Vi beslöt för att trycka reboot på varje nytt team.

Vi satt ju i en situation med hög grad av diversifiering bland deltagarna i de Agila teamen, både i form av deltagare från olika leverantörer men också olika kulturer.

Så det trick vi tog till för att initiera skiftet gjordes genom vårt koncept “Samverkansveckan”.

Hur gick det till?

Ja i ett team flög vi helt sonika in alla medlemmar under en vecka med syfte att lära känna varandra och definiera “hur vill vi jobba ihop”.

Alla vi bär på vissa kulturella mönster som kan lägga krokben för ett bra samarbete. Den del är synliga andra kan vara osynliga för oss. Ett sådant exempel är kulturella skillnader. Tex: Indier har en kultur att inte säga när något går dåligt. Detta rimmar illa med det bärande fundamentet i Agila arbetssätt – öppenhet och transparens.

Så: hur tar du upp kulturella mönster utan att det upplevs känsligt? Lösningen var vår samverkansvecka.

Hur gick samverkansveckan till?

Jo, så här:

De två första dagarna spenderade vi i stort sett enbart på att lära känna varandra som personer. Vi frågade “vem är du”, tittade på kartor var varje individ kom ifrån och deras historia (både professionellt och privat). Vi tog gjorde även lite sociala aktiviteter som bowling och middag ihop.

Det la en grund för att dag 3 så började deltagarna våga öppna upp sig mer.

Då tog vi tag i de lite svårare frågorna, bla kulturella mönster. Viktigt att påpeka var att vi gjorde det för alla involverade kulturer. Ett svenskt exempel var ”socialt avstånd”, en svensk fysisk komfortzon skiljer sig från t.ex. en indisk. Vad vi gjorde var att identifiera och jobba igenom varje viktig (o)vana, förklara den och på ett okonstlat sätt hitta hur man inom teamet ville förhålla sig till den.

Detta fungerade bra. Dag 4 vara det en helt annan stämning i rummet. I det läget skiftade vi spår och började definiera gemensamma arbetsprocesser.

Samverkansveckan var en nyckelfaktor för att tillåta oss att snabbt komma ut ur startblocken och sätta en ny kultur.

Låt oss spola fram till nutid. Vad är resultatet så långt?

Ganska snabbt fick vi bra resultat. Efter fyra månader hade vi i ett team minskat ledtiden med 50%, parallellt med detta sjönk även medelstorleken på en förändring i systemet med 50%. Det blev alltså lättare att lägga in nya funktioner. Detta skall jämföras med en kostnadsökning på ca 15% som kom från skiftet från outsourcat till lokala Agila team.

Jämför man dessa parametrar, minskad ledtid, minskad storlek på förändring mot en marginell kostnadsökning så blev det en total kostnadssänkning. En enkel trade att göra, om man bara tar det ekonomiska perspektivet.

En annan upplevd effekt som var minst lika stark, var att en verksamhets person i och med vår förändring kunde tala direkt med de involverade teamen. Detta ökade ansvarskänslan, kvaliteten i kommunikationern samt snabbade på feedbacklooparna. Förtroendet ökade och en mängd köer minskade.

Vi är fortsatt inte klara, det finns så klart fler saker att adressera. Vi söker hela tiden förbättra oss i små steg. Ett praktiskt sådant exempel är skalad samverkan mellan teamen.

Tack för att du tog dig tid Tobias, och varmt lycka till på den fortsatta resan!

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *