Byta från vattenfallsmodellen till avtal med fast löptid och pris (med Tucker Sauer-Pivonka från Crema)

Läs transkriptet:

Vi testar att transkribera våra poddar med hjälp av ett datorprogram. Ha överseende med eventuella stavfel eftersom roboten inte är korrekt till 100 procent hela tiden.

Ben Aston:

Välkommen till DPM-podden, där vi går bortom teorin för att ge råd som fungerar när man ska leda bättre digitala projekt. Tack för att du lyssnar. Jag heter Ben Aston och är grundare av The Digital Project Manager.

Projekt går sällan enligt plan, och när planerna förändras skapar det ofta mycket stress. Beslut måste fattas, möten bokas, planer uppdateras, uppskattningar räknas om och vanligtvis utfärdas ändringsförfrågningar. Men tänk om det fanns ett annat sätt att hantera förändringar i dina projekt? I det här avsnittet lyfter vi på locket och tittar på ett annat sätt att hantera förändringar genom agila avtal. Fortsätt lyssna för att förstå hur du får agila avtal att fungera för dig samt vilka fördelar och utmaningar detta arbetssätt innebär.

I dag får jag sällskap av Tucker Sauer-Pivonka. Han är chef för produktledning och hjälper produktchefer att växa och utvecklas. Han ansvarar också för att vidareutveckla deras bästa arbetssätt. Hej, Tucker.

Tucker Sauer-Pivonka:

Hej Ben, trevligt att höra från dig i dag.

Ben Aston:

Detsamma. En sak jag faktiskt ville fråga dig om när vi börjar är att en del av din roll handlar om teamets utveckling. Kan du dela med dig av några insikter om vad du har upptäckt verkligen fungerar för att hjälpa teamet att utvecklas? Kanske när det gäller de avtal du arbetar med eller experimenterar med. Hur vårdar du teamet och hjälper det att växa? Vad har du upptäckt fungerar för dig?

Tucker Sauer-Pivonka:

Jag tror att det första man måste inse tidigt är att alla lär sig lite olika och behöver coachas på lite olika sätt. Därför sätter jag mig ned med varje teammedlem och börjar ta reda på hur de lär sig, hur de vill få återkoppling och hur de vill få beröm. Jag håller reda på allt detta så att jag kan anpassa mitt arbetssätt efter något som de svarar bättre på. Jag lägger mycket tid på våra individuella möten, där vi går igenom olika ämnen och utvecklingsområden och coachar kring sådant de har problem med just då.

Utöver det har vi just nu en bokstudie på Crema kring en bok som heter Multipliers. Det är en viktig del av teamets utveckling. Sedan har vi förstås konferenser. Vi ska på en konferens i slutet av september som också handlar om produktledning. Vi åker dit som ett team, inte bara för teambuilding utan också för att lära oss om nya ämnen.

Ben Aston:

Trevligt. Vet du vad konferensen heter?

Tucker Sauer-Pivonka:

Den heter Industry: The Product Conference och hålls i Cincinnati, om jag minns rätt.

Ben Aston:

Fest i Cincinnati om du vill följa med Tucker och teamet. Du nämnde att ni tar upp många olika ämnen med teamet. Kan du berätta om några ämnen eller områden som du hjälper teamet att hantera? Vilka utmaningar möter teamet som du hjälper dem att övervinna?

Tucker Sauer-Pivonka:

Det ser lite olika ut för varje person eftersom teammedlemmarna har olika kunskapsnivåer. En stor del av det vi gör i grupp handlar om kundhantering. Till exempel: ”Min kund sa det här” eller ”Min kund vill att vi gör det här, men vi har egentligen inte pratat om det. Hur ska jag hantera det?”

Kundhantering är vanligtvis det svåraste att lära någon, så det blir ofta en diskussion om vad som kändes fel, om det verkligen var rätt sätt att hantera situationen och om personen borde göra annorlunda nästa gång.

Ben Aston:

Det stämmer verkligen. Det finns mjuka färdigheter inom kundhantering och teamhantering, men det finns aldrig ett enda rätt svar. Det beror alltid på situationen. Vi kan ändå alltid utvecklas inom de områdena.

Du nämnde också att ni går på konferenser som team, vilket är fantastiskt. Jag är nyfiken på var du hämtar inspiration och hur du håller dig uppdaterad. Hur håller du dig aktuell och hur blir du inspirerad?

Tucker Sauer-Pivonka:

Jag använder många olika källor. Böcker är en av dem och jag läser också många artiklar. Medium är en plats jag ofta besöker för inspiration kring produktledning, teamledning och hur det kan se ut. Man måste komma ihåg att Medium är en bra resurs, men att man ibland måste ta innehållet med en nypa salt eftersom vem som helst kan publicera en artikel där. Att någon kan publicera något på internet gör dem inte till en expert, men innehållet kan ändå ge sammanhang för hur man kan hantera vissa situationer.

Jag läser också Wired. Jag brukar läsa de flesta artiklarna i varje nummer. Det hjälper mig att hålla mig uppdaterad om trender utanför projektledningsvärlden, särskilt inom teknik i stort.

Ben Aston:

När det gäller teknik, är du någon som ligger längst fram i utvecklingen? Vilken är den senaste prylen du har köpt?

Tucker Sauer-Pivonka:

Jag önskar att jag hade något väldigt spännande att berätta. Jag skulle inte säga att jag ligger längst fram, men jag betraktar mig som en tidig användare. Jag försöker vanligtvis köpa nya produkter när de lanseras. Just nu är jag sugen på en ny iPad. Jag har en iPad Pro som fungerar bra, men jag vill ha den nya versionen och kan inte riktigt motivera köpet.

Den senaste versionen av iOS och iPadOS, och allt som presenterades på WWDC, var mycket intressant för mig. Jag har funderat mycket på vilken påverkan det kan få på branschen och på vissa av de produkter jag utvecklar. Jag är också lite av en Zelda-nörd, och uppföljaren till Breath of the Wild har nyligen tillkännagetts, så jag är väldigt entusiastisk över det också.

Ben Aston:

Trevligt. Det jag tittar på just nu är DJI Rover. Jag vet inte om den kallas Rover eller vad det är, men det är en liten kamera på en liten bandvagn som man bygger själv. Den ser fantastisk ut och står på min inköpslista.

Tucker Sauer-Pivonka:

Det låter roligt.

Ben Aston:

Det är ännu en sådan sak där man frågar sig om man verkligen behöver den. Men barnen skulle säkert tycka om den. När du nämner att du tycker om din iPad Pro undrar jag om det finns någon annan maskinvara eller programvara som nyligen har gjort ditt liv bättre och som alla borde känna till.

Tucker Sauer-Pivonka:

Jag har under flera år försökt hitta en balans mellan handskrivna anteckningar, skrivna anteckningar och uppgiftshantering. Det finns mycket information som säger att man bearbetar något annorlunda när man skriver ned det för hand än när man skriver det på ett tangentbord. En tid antecknade jag på min iPad med Apple Pencil, men nyligen har jag gått över till ett mellanting.

Jag bär med mig en liten anteckningsbok där jag skriver ned dagens anteckningar och uppgifter. I slutet av dagen för jag över dem till Todoist för att hålla reda på mina uppgifter och bearbeta anteckningarna. Det är den största förändringen i mitt arbetsflöde på senare tid och den har varit mycket hjälpsam. Jag märker att jag förstår det jag gör bättre och kan följa upp mina uppgifter utan att kasta mig över dem direkt.

Ben Aston:

Intressant. Du använder alltså en fysisk anteckningsbok för anteckningar och påminnelser, men för sedan över informationen till en digital miljö?

Tucker Sauer-Pivonka:

Ja. För mig kan inget ersätta att öppna en anteckningsbok, klicka med pennan och börja skriva. När jag använde iPad och Apple Pencil fanns det många små hinder: öppna rätt app, hitta rätt anteckningsbok och kontrollera att pennan var laddad. De sakerna verkar små men blir ändå hinder för att snabbt skriva ned en anteckning. Därför bar jag runt på en iPad och en mängd klisterlappar. Det var inte hållbart, så jag gick över till en anteckningsbok.

Ben Aston:

Jag använder Evernote. Jag har en anteckningsbok för min att-göra-lista och en annan som jag kallar kladdblock, där allt råmaterial hamnar innan det förs över till att-göra-listan. Jag har också ett mycket litet block som bara rymmer påminnelser, inte längre anteckningar. På så sätt tvingas jag använda systemet i stället för att skapa nya listor överallt.

Men låt oss prata om artikeln du skrev för oss. Den handlar om att byta från avtal enligt vattenfallsmodellen till avtal med fast löptid och pris. Vi har pratat om agila avtal tidigare och i DPM-skolan frågade någon nyligen efter ett exempel på ett agilt avtal. Alexa skrev tidigare ett bra inlägg om agila avtal. För den som inte känner till dem: kan du kort förklara vad ett avtal med fast löptid och pris är och hur det fungerar?

Tucker Sauer-Pivonka:

Jag kan förklara hur vi använder det på Crema. Ett avtal med fast löptid och pris bygger i grunden ett projekt kring ett dedikerat team. Det kan till exempel bestå av två heltidsutvecklare, en testingenjör på halvtid, en designer på kvartstid eller halvtid, en produktchef och kanske en strateg på kvartstid.

Fokus ligger på teamet och de mål man försöker nå, snarare än på en detaljerad lista över leveranser och funktioner med exakta timuppskattningar. Programvara är för komplicerad för att allt ska kunna uppskattas i förväg med antagandet att allt följer planen. Det händer aldrig.

Avtalen gör det möjligt för oss och kunderna att flytta fokus till det arbete som har högst prioritet. På så sätt levererar vi det som skapar störst värde för verksamheten vid slutet av löptiden och under de iterativa cyklerna. Prioriteringar kan förändras under ett sexmånadersprojekt, och då kan avtalet hjälpa oss att anpassa oss efter kundens behov.

Ben Aston:

Vilka typer av projekt fungerar inte lika bra med sådana här agila avtal?

Tucker Sauer-Pivonka:

Man måste bedöma vilken typ av arbete man utför. Det här fungerar för oss eftersom vi utvecklar produkter där det är svårt att specificera varje detalj i förväg och samtidigt bedöma riskerna. Om arbetet däremot är mycket repetitivt, till exempel standardiserade webbplatser med ett visst antal sidor och en återkommande layout, kan ett fastprisavtal vara mer lämpligt. Det handlar i grunden om förutsägbarhet och oförutsägbarhet.

Ben Aston:

Hur skiljer sig detta från värdebaserad prissättning?

Tucker Sauer-Pivonka:

Det är två olika saker. När vi bygger programvara vet vi inte nödvändigtvis exakt hur slutresultatet kommer att se ut. Därför är det svårt att sätta ett pris i början. Värdebaserad prissättning fungerar bättre när man kan säga att man ska leverera något som skapar ett visst värde för verksamheten, till exempel en designsprint.

När det gäller lönsamhet är en fördel med löptids- och prismodellen att den är inbyggd i upplägget. Kunden köper en viss teamkapacitet under en viss tid. Man räknar inte på om man gått över eller under ett visst antal timmar, utan levererar värde sprint efter sprint.

Ben Aston:

Vad händer om kunden efter några sprintar tycker att de inte har fått tillräckligt mycket värde?

Tucker Sauer-Pivonka:

Det händer inte särskilt ofta eftersom vi arbetar noggrant med samsyn. Vi håller kunden informerad under hela sprinten och kommunicerar förändringar längs vägen. Den bästa lösningen är god kommunikation och kundhantering.

Vi kan säga: ”Vi trodde att detta skulle ta två sprintar, men det ser ut att ta tre eller fyra på grund av det vi har upptäckt.” Sedan förklarar vi vad vi har upptäckt och erbjuder kunden möjligheten att byta fokus. Genom att lägga fram alla fakta blir besluten mindre känslomässiga.

Inför varje sprint ser vi till att kunden förstår vad som ingår och att teamet känner sig tryggt med leveransen. I slutet visar vi det vi har gjort och pratar om eventuella överförda uppgifter eller nya upptäckter.

Ben Aston:

I fallstudien nämner du att ni visste att arbetet skulle ta minst sju månader. Hur kom ni fram till den uppskattningen om ni inte visste exakt vad ni skulle bygga?

Tucker Sauer-Pivonka:

I det fallet, liksom i de flesta av våra projekt, hade vi först genomfört någon form av prototyp- eller testuppdrag. Det var ett kortare uppdrag på sex veckor och omfattade även en teknisk granskning av det befintliga systemet. Det gav oss information om tidsramen för att nå kundens mål.

Vi tittade på målen och de olika delarna av produkten, bedömde komplexiteten och använde grova T-shirt-storlekar. Därefter rekommenderade vi teamets storlek och sammansättning. Löptiden handlar inte om en viss lista över leveranser utan om verksamhetsmålen och kundens budget. Programvara blir aldrig helt färdig, så vi uppskattade vad teamet kunde leverera under sju månader och arbetade sedan med kunden sprint för sprint utifrån den högsta prioriteten.

Ben Aston:

Kan kunden välja en kortare löptid?

Tucker Sauer-Pivonka:

Absolut. Om kunden vill ha ett avtal på tre månader kan vi göra det. Då fokuserar vi under de tre månaderna på det viktigaste arbetet. Man kan tänka på det som att hyra ett team under tre månader, sex månader, ett år eller två år.

Ben Aston:

Hur fungerar prototyp- och valideringsfasen? Är den ett fastprisuppdrag?

Tucker Sauer-Pivonka:

Tekniskt sett ingår den fortfarande i modellen med fast löptid och pris, men den är något mer fast när det gäller leveranser. Vi kan lova en prototyp med hög detaljnivå, skissfiler, användarintervjuer, anteckningar och tillhörande research. Men om vi efter tre veckor upptäcker att användarna vill något annat kan vi börja om från ritbordet. Det handlar inte om att leverera ett exakt antal skärmar, utan fortfarande om löptid och pris.

Ben Aston:

Vilken metod använder ni? Hur skiljer ni er från den mer föreskrivande Scrum-modellen?

Tucker Sauer-Pivonka:

Vi säger ofta att vi sätter människor framför processer. Vi arbetar med Scrum med litet s. Det innebär att processen är tillräckligt flexibel för att inte begränsa människor. Om ett team behöver anpassa processen för att samarbeta bättre med kunden har det självständighet att göra det.

I en byråmiljö är det svårare att ha en särskild roll för allt. Kundens dagliga kontakt fungerar vanligtvis som produktägare. Om en strateg ingår i projektet kan den personen fungera som medproduktägare och hjälpa kunden att fatta beslut om produktens strategi och riktning.

På vår sida kombinerar vi produktchefens och Scrum-mästarens roller. Det avviker från traditionell Scrum, men det fungerar för oss. Vi genomför planering, uppskattningar, retrospektiv och produktdemonstrationer. Vi samlar ofta aktiviteterna i ett möte som kallas onsdagens uppstartsmöte.

Ben Aston:

Hur hanterar ni motstridiga prioriteringar när kunden vill bygga något nytt men samtidigt måste underhålla det gamla systemet?

Tucker Sauer-Pivonka:

Det första är att vara empatisk inför orsaken till förändringen. Kunden vill oftast inte ändra prioriteringarna, men har ett verkligt behov. Man måste förstå varför prioriteten ändras och om det handlar om en genuint hög prioritet eller något annat.

Det andra är att vara mycket tydlig med att en ändrad prioritet ändrar hela planen. Om teamet lämnar en större funktion för att arbeta med något akut innebär det att den större funktionen inte blir färdig när man först trodde. Det kan vara helt okej, men kunden måste förstå konsekvenserna.

Visuella hjälpmedel i verktyg som Jira är mycket användbara. Ibland hör kunden orden men förstår inte konsekvensen förrän den visas visuellt.

Ben Aston:

Har kunden tillgång till Jira?

Tucker Sauer-Pivonka:

Ja. Vi arbetar med full transparens. Kunden får tillgång till våra verktyg och läggs till som gäst i vårt Slack-team. I Jira kan kunden hjälpa till att kontrollera prioriteringar, krav och riktning. Det minskar risken för att kunden i slutet av sprinten säger att något borde ha ingått.

Vi kräver inte att kunden använder verktygen, men om de vill kan vi skapa personliga skärminspelningsvideor som visar hur verktygen fungerar, var man hittar information och vilka delar man inte behöver bekymra sig om. Vi levererar också information stegvis så att allt inte hamnar i kundens knä samtidigt.

Ben Aston:

Rapporterar ni arbetad tid och tidrapporter när kunden betalar för ett team under en viss tid?

Tucker Sauer-Pivonka:

Vi rapporterar främst resultat. Varje sprint går vi igenom vad som blev färdigt, vad som inte blev färdigt och vilken hastighet teamet hade. Vi rapporterar inte exakt antal timmar eftersom kunden inte betalar timme för timme.

Vi använder rapporteringen internt för att kontrollera att teamets kapacitet är korrekt. Om någon som ska arbeta halvtid regelbundet behöver mer tid måste vi antingen ta bort arbete eller öka tilldelningen. Vanligtvis är tilldelningarna dock ganska träffsäkra.

Ben Aston:

När fungerar avtal med fast löptid och pris inte? Har något någonsin gått helt fel?

Tucker Sauer-Pivonka:

Saker kan gå fel, särskilt om kunden känner sig besviken på framstegen. När man märker tecken på det bör man ta upp det direkt: ”Jag tror inte att vi har samma bild av något. Kan vi prata om det?” Om man väntar till slutet är det ofta för sent att bygga upp förtroendet igen.

I ett fall var kunden besviken inför en förlängning. När vi pratade förstod jag att vi hade bytt fokus på grund av en prioriteringsförändring och arbetat med något annat i två månader. Det var rätt för verksamheten, men kunden hade inte fullt ut förstått hur det påverkade den ursprungliga planen. När vi förklarade det blev situationen tydligare.

Det mesta handlar om bristande samsyn. Om kunden inte vill skapa samsyn kanske man inte är rätt partner för varandra. Därför försöker vi upptäcka sådant tidigt i säljprocessen.

Ben Aston:

Det krävs alltså rätt typ av kund för att detta ska fungera. Kunden måste förstå att förändrade prioriteringar påverkar tidsplan och kostnad. En stor del handlar om att utbilda kunden under säljprocessen, prototyp- och valideringsfasen samt resten av uppdraget. Resultatet blir att kunden får ett bättre utfall eftersom teamet kan leverera värde utifrån kundens faktiska prioriteringar.

Avtal med fast löptid och pris är definitivt ett intressant koncept. Tack så mycket för att du var med i dag, Tucker.

Tucker Sauer-Pivonka:

Tack själv. Det här har varit ett fantastiskt samtal.

Ben Aston:

Jag undrar vad du tycker. Har du provat ett agilt avtal? Jag vill gärna veta hur det gick. Kommentera inlägget och besök TheDigitalProjectManager.com för att gå med i vårt Slack-team. Där pågår många intressanta samtal om projektleverans och vi har en agil kanal där vi gärna diskuterar detta.

Om du tyckte om dagens avsnitt får du gärna prenumerera och ta några minuter till att lämna en ärlig recension av DPM-podden på Apple Podcasts. Betyg och recensioner hjälper oss mycket och vi uppskattar det verkligen. Tack för att du lyssnade.