Vi tog tillfället i akt att intervjua Stefan Roock från it-agile i Tyskland. Stefan har 12 års erfarenhet från mjukvarubranchen i bagaget. Stefan har följt utvecklingen av upphandling på den Tyska marknaden och sett två trendskiften, hur stora fastprisprojekt initialt övergavs till förmån för upphandling av agila team projekt på löpande räkning, samt de senaste åren hur detta skiftat till upphandling via Agila kontrakt. Vi ringde upp honom för att lära oss av hans erfarenheter om hur de som leverantör lyckats omvandla traditionella fastprisprojekt till Agila kontrakt. En kul överraskning var att Stefan även kunde berätta hur de Agila kontrakt som är i bruk idag fungerar. De är byggda kring en modell som kallas ”garanterad produktivitet.”
(this article is also available in english here)
Låt oss börja med att lära oss lite om dig?
Hej, mitt namn är Stefan Roock, anställd på it-agile.
Kan du ge oss lite bakgrund till projektet där ni lyckades skifta from traditionella fastprisprojekt till Agila kontrakt?
Japp, det var faktiskt en resa genom flera projekt som vi (som leverantör) gjorde tillsammans med ett större vattendistributions- och reningsföretag – låt oss kalla det WATCO. WATCO försörjer mer än en miljon människor med vatten.
Jag kommer att berätta om på två projekt vi gjorde med dem. Det första var ett planeringssystem för fältarbetare, det andra ett prognossystem för avloppsvattensrensning. Längden på projekten låg på 1,5 till 2 år, vilket var ganska stora projekt för oss på den tiden.
Målet med det första projektet (”fältplanering”) var att skapa ett användarvänligt gränssnitt för planering och utförande av fältarbete. Detta skulle även integreras med SAP, vilket användes som affärssystem.
Det andra projektet syftade till att hitta ett smarta sätt att disponera underhållsresurser på. Bakgrunden var att ett skifte till moderna tvättmaskiner inneburit att vattenflödet var inte starkt nog för att hålla igång självreningen av avfallsvattnet. Istället måste reningen genomföras med hjälp av speciella lastbilar. Problemet var att WATCO inte hade tillräckligt med personer eller lastbilar för att hålla avloppsvattnet flödande. Så de behövde komma sätt att disponera reningsresurserna och prognosticera var avloppsystemet behövde renas, för att undvika stopp i systemet.
Bägge projekten startades som traditionella fastprisprojekt, men avslutades som Agila projekt.
Ett bevis på det -och ett minne som etsats fast – kommer från kick-off’en på projektet som skedde efter dessa två. Inför detta projekt hade vi gett en offert på 300 000 EUR baserat på en initial specifikation. Kick-offen inleddes med att kunden klev in i rummet, knölade ihop specifikationen och demonstrativt kastade den i papperskorgen och sade ”Låt oss nu tala om vad som verkligen behöver byggas!”.
Specen hade skrivits för att få loss budgeten till projektet, men kunden insåg att den passerat bast före datum, den var gammal. Situationen visade på att vi hade byggt upp ett ömsesidigt förtroende för att tillsammans beskriva på vad som verkligen behövdes, för att uppnå deras effektmål.
Vad gjorde ni som leverantör i de tidigare faserna- upphandling och kontraktsskrivning – för att möjliggöra ett skifte mot Agila kontrakt?
Vi föreslog två klausuler i kontrakten.
- ”Change for free” – Kunden får rätt att under projektets gång, byta ut krav som ursprungligen skrivits mot nya funktioner, så länge de är av motsvarande storlek.
- ”Budgetbuffer” – En buffer på 15% av totalkostnaden vilken kontrolleras av kunden. Buffern kommer med en ömsesidig överenskommelse om att den kan användas för extra funktionalitet som upptäcks, under projektets gång.
Hade ni några problem med att lägga till dessa klausuler i kontraktet?
Den första – ”change for free” köpte kunden direkt. Den gav helt enkelt kunden extra flexibilitet.
”Budgetbuffer” klausulen, skapade dock en del diskussion. Kunden förstod nyttan av klausulen eftersom de hade erfarenheter från tidigare misslyckade projekt bakom sig. Diskussionerna rörde snarare hur stor den skulle vara. Vårt initiala förslag var 20%. Kunden förelog 10%. I slutändan enades vi om en budgetbuffer på 15%.
Kom ni att använda någon av klausulerna?
Under de första sex månaderna så användes ”change for free” knappast alls. Vi levererade helt enkelt mot ursprunglig spec. Men steg för steg, över tid, skiftades vad vi utvecklade från ”vad som var beställt” till ”vad som behövdes för att uppnå målet”. Under den andra halvan av projektet användes ”change for free” ganska frekvent. Det bör nämnas att för det efterföljande projektet – när kunden kastade hela specifikationen i papperskorgen – så användes ”change for free” direkt på alla funktioner kunden hade beställt.
Hur lång tid tog det att bygga upp tillräckligt förtroende för att kunna ha balanserad konversationer med kunden?
Ca 6 månader, vill jag minnas. Men den erfarenhet vi byggt upp idag jag säga att de skulle ta 3-4 månader. Vi har helt enkelt mognat som leverantör.
En insikt som vi drog om oss själva från den tiden var, att vi omedvetet som leverantör, kunde börja imitera beteenden hos kunden. Ett exempel från det första projektet, mycket av kravdiskussionerna skedde inledningsvis mellan kundens projektledare och våran. Idag skulle vi direkt ha involverat en utvecklare i de diskussioner som rör innehåll eller teknologival. Detta bidrar till att skapa ett bättre informationsflöde och snabbare uppbyggnad av förtroende.
En annan erfarenhet vi drog var att byta av nyckelpersoner bidrog att vi föll tillbaka till ruta ett. Vi såg detta tydligt vid ett tillfälle när kundens projektledare byttes ut. Efter det hände behövde vi gå igenom hela förtroendecykel igen.
Låt oss utveckla projektstrukturen lite.Var var ni placerade?
Vi var samlokaliserade med kunden i dennes faciliteter. Detta var en central framgångsfaktor. Den dagliga interaktionen vi hade förbättrade både våran problemlösningsförmåga och en snabb uppbyggnad av förtroendet mellan parterna.
Om vi som leverantör någon gång körde i diket (japp.. sånt hände..), så kunde vi samma dag gå till kunden, erkänna att det hade hänt, föreslå en motågärd och tillsammans klura ut bästa sättet att lösa situationen. Samlokalisering möjliggjorde att vi kunde fixa problemet direkt när de hände och utan behov av extra eskalering.
Hur såg projektorganisationen ut?
Hos kunden:
Varje projekt hade en dedikerade projektledare/produktägare (PO). I realiteten arbetade denna person som en renodlad produktägare. Orsaken till den duplicerade titeln var vi den tiden som projektet initierades var Agila roller som ”Produktägare” och ”Scrummaster” ganska okända.
Kunden hade också en ”Cheif product owner” som var ansvarig för hela programmet (vilket inkluderade våra projekt). Varje kundproduktägare hade dock eget mandat att prioritera inom sitt projekt. Rollen ”Cheif product owner” existerade helt enkelt för eskalering, och det var denna person som hade mandat att använda budgetbuffern
Hos leverantören:
Vi hade en projektledare/scrum master samt ett utvecklingsteam. Scrum master’s roll var att skapa ett högeffektivt team. Det var även denna persons roll att lösa eventuella konflikter, samt avgöra om en förändring var en bugg eller feature.
Ett klassiskt problem i fastprisprojekt är ”feature push”, att kunden rätt sent börjar trycka in extra funktioner. Upplevde ni detta problem?
Faktiskt mycket mindre än vad vi normalt sett gör. Det faktumet att vi bedrev projektet med Agila metoder samt var samlokaliserade, påverkade och skiftade parternas beteenden. Ett sånt tydligt skifte var ett skifte från krav till behov, i kommunikation mellan oss som parter. Från ”vad som var skrivet i specifikationen” till ”vad behövs för att nå effektmålet?”. Detta till att hålla fokus på innovation och problemlösning, snarare än att trycka in nya funktioner.
Ok, med din erfarenhet, vad skulle du rekommendera andra som står i en liknande situation?
Jag skulle rekommendera tre saker:
- Arbeta samlokaliserat i kundens lokaler med daglig personlig kontakt. Detta är det snabbaste sättet att lösa problem samt att bygga förtroende.
- Kör projektet med Agil metodik, oavsett vad kontraktet säger. Att använda Agil metodik minskar drastiskt risken i projektet.
- Om du kan, använd Agila kontrakt från början. Vår erfarenhet är att fastprisprojekt dödar innovation.
En erfarenhet vi drog som leverantör var att att förändring av personal (även på vår sida) skapade oväntade sidoeffekter. Ett verkligt exempel: I ett av projektet hade jobbat upp en väl fungerande, regelbunden demonstration av vad vi utvecklat. Men så ansluter en ny utvecklare vårt team. Och när en ny person kommer in är han/hon normalt fylld av idéer (bra!) som de vill dela med sig av. I detta fall skedde det genom att den nya utvecklaren direkt till kunden, under demonstrationen, lägger fram ett antal förslag. ”om vi grupperar sidorna på det här sättet, blir systemet lättare att använda”. Inte oväntat gillar kunden detta, och inget ont om iden, men sidoeffekten var att detta efteråt skapar obekväma diskussioner huruvida om detta var en feature eller bugg (eftersom förslaget kom från oss). Det jag lärde mig var; håll rotation av personal till ett minimum, och gå igenom med nya utvecklare hur konstruktivt engagera sig i dialog med kunden, när de kommer in i teamet.
Avslutningsvis vill jag betona att även om i dessa projekt lärde oss hur kunde skifta traditionella fastprisprojekt till Agila (och därmed fick ett bra resultat), så är vår samlade erfarenhet att fastprisprojekt dödar innovation. Så om du kan, upphandla projekt genom Agila kontrakt från början.
När du nämner Agila kontrakt, hur skulle du beskriva status för Agila kontrakt i Tyskland?
Agilt börjar bli det vanliga sättet att bedriva utveckling på i Tyskland. Det gör att vi ser ett växande intresse kring Agila kontrakt.
Vi har observerat att många av våra kunder har slutat med fastprisprojekt idag. Under en tid experimenterade de med löpande räkning men de drog slutsatserna att detta reducerade leverantörens incitament att ständigt förbättras. Så idag har många taget steget till Agila kontrakt fullt ut.
Det är intressant. Så vilken incitamentsmodel är vanligast i Agila kontrakt hos era kunder?
Det finns flera alternativ. Men en som är speciellt intressant är en modell vi kallar ”Garanterade produktivitet”. En av våra kunder kom på modellen för att undvika problemen som vid fastprisprojekt, samt de som uppstod med löpande räkning.
Upplägget går ut på att du hyr ett Agilt utvecklingsteam för ett antal sprintar (iterationer). Tex. 8 st tvåveckorssprintar. Efter den första sprinten mäts teamets leveransförmåga (”velocity” i Scrumterminologi) och kund och leverantör för en diskussion huruvida den velocityn som uppmättes är representativ för det kvarvarande delarna i projektet. Om bägge parter håller med, används denna som prognos för vad man kommer hinna med i projektet.
Varje vecka hålls ett kalibreringsmöte där kunden och leverantören diskuterar framåtskridandet, prognosen för vad som kommer hinnas med och eventuell nödvändig omkalibrering (detta möte är inskrivet i kontraktet). Om leverantören visar sig vara långsammare, än ursprunglig prognos så delas kostnaderna för detta 50/50, mellan leverantören och kunden. Orsaken till 50/50 delningen är för att betona kundens ansvar för leveranskapacitet, tex genom att prioritera och svara på frågor i tid.
En insiktsfull observatör noterar säkert att estimeringen (som ligger till grund för velocityn) faktiskt kan ”gejmas”. Vad som balanserar ett sådant beteende (och förövrigt eget kortsiktigt gynnande, oavsett part..) – är den höga transparensen samt det veckoliga kalibreringsmötet.
En naturlig evolution av denna modell vore att att även inkludera en uppsida. Om vår leveransförmåga utvecklas bättre över tid (ett rimligt antagande i ett väl fungerande Agilt projekt) – så kan vinsten av denna produktivitetsökning delas 50/50. Du får i med uppsidan inkluderad, en form av målprismodell.
Vi har kunder idag som vill använda ovanstående vinstdelningsmodell i sina Agila kontrakt, men inte kan. Orsaken är att deras upphandlingsavdelningars systemstöd, ännu inte klarar hantera dessa modeller.
Tack Stefan för att du tog dig tid. Det var spännande att höra om skiftet som sker mot Agila kontrakt. Vi ser fram emot att höra från era framtida experiment.