Fra fossefall til varighets- og priskontrakter (med Tucker Sauer-Pivonka fra Crema)

Les transkripsjonen:

Vi prøver ut å transkribere podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, siden roboten ikke er korrekt 100 % av tiden.

Ben Aston:

Velkommen til DPM-podkasten, der vi går bortenfor teorien for å gi råd som fungerer når du skal lede bedre digitale prosjekter. Takk for at du lytter. Jeg er Ben Aston, grunnleggeren av The Digital Project Manager. Prosjekter går sjelden etter planen, og når planene endres, skaper det ofte mye stress. Det må tas beslutninger, møter må planlegges, planer må oppdateres, estimater må beregnes på nytt, og vanligvis må det sendes ut endringsforespørsler. Men hva om det fantes en annen måte å håndtere endringer i prosjektene dine på? I denne podkasten skal vi se nærmere på en annen måte å håndtere endringer på, gjennom smidige kontrakter. Fortsett å lytte for å forstå hvordan du kan få smidige kontrakter til å fungere for deg, og hvilke fordeler og utfordringer denne tilnærmingen innebærer.

I dag har jeg med meg Tucker Sauer-Pivonka. Han er direktør for produktledelse og hjelper produktledere med å vokse og utvikle seg. Han har også ansvar for å videreutvikle beste praksis. Hei, Tucker.

Tucker Sauer-Pivonka:

Hei, Ben. Hyggelig å snakke med deg i dag.

Ben Aston:

I like måte. En av tingene jeg gjerne vil spørre deg om innledningsvis, er at en del av rollen din handler om utvikling av teamet. Kan du dele noen erfaringer om hva som virkelig har fungert når det gjelder å hjelpe teamet med å utvikle seg? Kanskje også knyttet til kontraktene dere arbeider med eller eksperimenterer med. Hvordan gir du teamet næring og hjelper dem med å vokse? Hva har fungert for deg?

Tucker Sauer-Pivonka:

Jeg tror det viktigste er å forstå tidlig at alle lærer litt forskjellig, og at alle trenger litt ulike former for veiledning. Noe av det første jeg gjør med teammedlemmene mine, er å sette meg ned med dem og finne ut av dette. Hvordan lærer de? Hvordan liker de å få tilbakemeldinger? Hvordan liker de å få ros? Jeg holder oversikt over dette, slik at jeg kan tilpasse tilnærmingen min til noe de responderer bedre på. Jeg bruker mye tid i individuelle samtaler på å gå gjennom ulike temaer og utviklingsområder med dem, og på å veilede dem i det de måtte streve med. I tillegg har vi en bokklubb i Crema rundt en bok som heter Multipliers.

Det er en viktig del av utviklingen i teamet vårt. Og selvfølgelig har vi konferanser. Vi skal på en konferanse mot slutten av september som handler om produktledelse. Vi drar dit som et team, både for teambygging og for å lære om nye temaer.

Ben Aston:

Hva heter konferansen?

Tucker Sauer-Pivonka:

Den heter Industry: The Product Conference og arrangeres i Cincinnati, hvis jeg husker riktig.

Ben Aston:

Fest i Cincinnati hvis du vil bli med Tucker og teamet. Du nevnte at dere dekker mange ulike temaer med teamet. Kan du dele noen av temaene eller områdene du hjelper teamet med? Hvilke utfordringer møter teamet, og hva hjelper du dem med å overvinne?

Tucker Sauer-Pivonka:

Det varierer litt fra person til person, fordi vi har ulike ferdighetsnivåer i teamet. Mye av det vi gjør i gruppesammenheng, handler om kundehåndtering. Det kan være spørsmål som: «Kunden min sa dette», eller «Kunden ber oss gjøre dette, men vi har egentlig ikke snakket om det. Hvordan bør jeg håndtere det?» Kundehåndtering er vanligvis det vanskeligste å lære bort, så samtalene handler ofte om hva som føltes rart, om noe ble håndtert riktig, og om hvordan det kan gjøres annerledes neste gang.

Ben Aston:

Det stemmer. Det finnes myke ferdigheter innen kunde- og teamledelse, men det finnes aldri ett riktig svar. Det kommer alltid an på situasjonen. Du nevnte også at dere drar på konferanse som et team. Hvor finner du inspirasjon, og hvordan holder du deg oppdatert?

Tucker Sauer-Pivonka:

Jeg bruker mange ulike kilder. Jeg leser bøker og mange artikler. Medium er et sted jeg ofte finner inspirasjon om produktledelse og teamledelse. Samtidig må man ta ting med en klype salt, fordi hvem som helst kan publisere en artikkel der. Det at noe står på internett, gjør ikke forfatteren til en ekspert, men det kan likevel gi nyttig kontekst for hvordan man kan håndtere ulike situasjoner. Jeg leser også Wired for å følge med på teknologitrender utenfor prosjektlederverdenen.

Ben Aston:

Hva er det nyeste teknologiproduktet du har kjøpt?

Tucker Sauer-Pivonka:

Jeg har en iPad Pro, men vurderer den nye versjonen. Jeg har også fulgt med på den nyeste versjonen av iOS og iPadOS og alt som ble presentert under WWDC. Jeg er dessuten litt Zelda-nerd, så jeg gleder meg til oppfølgeren til Breath of the Wild.

Ben Aston:

Jeg ser på en liten kamerarobot fra DJI. Den ser fantastisk ut.

Tucker Sauer-Pivonka:

Det høres morsomt ut.

Ben Aston:

La oss snakke om artikkelen, som handler om å gå fra fossefallskontrakter til varighets- og priskontrakter. Vi har snakket om smidige kontrakter tidligere. For dem som ikke kjenner dem, kan du kort forklare hva en varighets- og priskontrakt er, og hvordan den fungerer?

Tucker Sauer-Pivonka:

I Crema bygger vi prosjektet rundt et fast team. Det kan for eksempel være to heltidsutviklere, en testingeniør på halv tid, en designer på en kvart eller halv tid, en produktleder og kanskje en strateg på en kvart tid. Fokuset ligger på teamet og målene man forsøker å nå, i stedet for å liste opp alle leveranser og funksjoner med nøyaktige timeestimater.

Programvare er for komplisert til at man kan estimere alt på forhånd og anta at alt vil gå etter planen. Disse kontraktene gjør det mulig å flytte fokuset dit arbeidet har høyest prioritet. På slutten av perioden, og gjennom de iterative syklusene underveis, leverer vi det som har størst verdi for virksomheten. Hvis prioriteringene endres over tid, kan vi tilpasse oss kundens behov.

Ben Aston:

Hvilke typer prosjekter fungerer ikke like godt med smidige varighets- og priskontrakter?

Tucker Sauer-Pivonka:

Man må vurdere hvilken type arbeid man gjør. Dette fungerer godt for oss fordi vi utvikler produkter der det er vanskelig å beskrive alt i detalj på forhånd. Hvis arbeidet derimot er svært repeterbart, som standardiserte nettsteder med et bestemt antall sider og en fast layout, kan en fastprismodell være mer hensiktsmessig. Det handler i stor grad om forutsigbarhet kontra uforutsigbarhet.

Ben Aston:

Hvordan fungerer dette sammen med verdibasert prising?

Tucker Sauer-Pivonka:

Det er to forskjellige ting. Når vi bygger programvare etter en varighets- og prismodell, vet vi ikke nødvendigvis hvordan det endelige resultatet blir. Derfor er det vanskelig å sette én pris på forhånd. Verdibasert prising fungerer godt når man kan si at man skal levere noe som skaper en bestemt verdi for virksomheten. Når man bygger et stort produkt, er det vanskeligere å definere verdien på forhånd.

Lønnsomheten ligger i at kunden kjøper en bestemt kapasitet i et team. De betaler ikke time for time for hver funksjon. Vi ser på hvilken del av teamet kunden får, og leverer verdi sprint etter sprint. Derfor handler rapporteringen mer om resultatene enn om antall timer.

Ben Aston:

Hva gjør dere hvis kunden etter flere sprinter mener at de ikke har fått nok verdi?

Tucker Sauer-Pivonka:

Vi jobber svært systematisk for å ha god samkjøring med kundene, både ved starten av hver sprint og gjennom hele sprinten. God kommunikasjon og kundehåndtering er avgjørende. Vi sier tydelig fra når noe som skulle ta to sprinter, ser ut til å ta tre eller fire, forklarer hvorfor, og viser hvilke alternativer kunden har. Når alle fakta ligger på bordet, blir beslutningene mindre følelsesladde.

Ben Aston:

Hvordan kom dere frem til en tidsramme på sju måneder?

Tucker Sauer-Pivonka:

Vanligvis skjer det etter en form for prototyping eller testing. I dette tilfellet hadde vi også gjennomført en teknisk gjennomgang av det eksisterende systemet. Deretter vurderte produksjonsteamet målene, kompleksiteten og de ulike delene av produktet. Vi brukte grov størrelsesvurdering, såkalte T-skjortestørrelser, for å vurdere kompleksiteten og bestemme teamets størrelse. Tidsrammen handlet om forretningsmålene og kundens budsjett, ikke om en fast liste med leveranser.

Ben Aston:

Hvordan skiller tilnærmingen deres seg fra tradisjonell Scrum?

Tucker Sauer-Pivonka:

Vi setter mennesker foran prosesser. Vi praktiserer Scrum med liten s. Det betyr at prosessen må være fleksibel nok til at teamet kan tilpasse den til kunden. Produktansvaret ligger vanligvis hos kundens daglige kontaktperson, eventuelt sammen med en strateg. Produktleder- og Scrum-masterrollen kombineres hos oss. Vi gjennomfører sprintplanlegging, estimering, retrospektiver og produktdemoer, men tilpasser seremoniene etter hva som fungerer best for teamet.

Ben Aston:

Hvordan håndterer dere endrede prioriteringer og konkurrerende behov?

Tucker Sauer-Pivonka:

Først må man forstå hvorfor prioriteringene endres. Kunden ønsker som regel ikke å miste fokus, men det kan ha oppstått et reelt behov. Deretter må man være helt tydelig på at en endring påvirker planen. Hvis teamet går over til en ny oppgave, blir den opprinnelige oppgaven forsinket. Det er greit, så lenge alle forstår konsekvensene.

Vi bruker også visuelle verktøy som Jira for å vise hva som skjer. Kundene har tilgang til verktøyene våre og kan bidra til å kontrollere prioriteringer og krav. Full åpenhet gjør det enklere å holde alle samkjørt.

Ben Aston:

Hvordan unngår dere å overvelde kunden med for mye informasjon?

Tucker Sauer-Pivonka:

Vi krever ikke at kundene bruker verktøyene, men sørger for at de har tilgang hvis de ønsker det. Vi kan lage personlige skjermopptak som viser hvordan verktøyene brukes, hva kunden bør se etter, og hva de ikke trenger å bekymre seg for. Vi leverer også informasjon trinnvis, slik at kunden ikke får alt i fanget samtidig.

Ben Aston:

Rapporterer dere tidsbruk og timelister?

Tucker Sauer-Pivonka:

Vi rapporterer først og fremst på resultater. Etter hver sprint ser vi på hva som ble fullført, hva som eventuelt gjenstår, og hvilken gjennomføringstakt teamet har. Vi rapporterer ikke detaljert timebruk på hver funksjon. Vi bruker likevel interne data for å kontrollere at teamets kapasitetsfordeling er riktig.

Ben Aston:

Når fungerer ikke varighets- og priskontrakter?

Tucker Sauer-Pivonka:

Hvis kunden virker misfornøyd med fremdriften, bør man ta opp dette tidlig. Hvis det oppstår en følelse av at noe ikke blir sagt, bør man spørre direkte om man er på samme side. Det er bedre å håndtere dette tidlig enn å vente til slutten av kontrakten.

Jeg har ikke opplevd at et prosjekt har falt fullstendig sammen, men vi har hatt situasjoner der kunden var skuffet over fremdriften. Da undersøkte vi hva som hadde skjedd, og fant at prioriteringene hadde blitt endret underveis. Når dette ble forklart, forsto kunden hvorfor resultatet var annerledes enn forventet. Det viktigste er å skape samkjøring og tillit tidlig.

Ben Aston:

Det krever altså en moden kunde som forstår at endrede prioriteringer påvirker tidsplan og kostnad. En viktig del av prosessen er å lære opp kunden gjennom salgsprosessen, prototypingen og valideringen, og å sette realistiske forventninger. Til gjengjeld får kunden verdi levert kontinuerlig, basert på det som til enhver tid er viktigst.

Tucker, tusen takk for at du ble med oss i dag.

Tucker Sauer-Pivonka:

Takk for invitasjonen. Dette har vært en flott samtale.

Ben Aston:

Hva synes du? Har du prøvd en smidig kontrakt? Fortell oss hvordan det gikk. Kommenter på dette innlegget, og besøk TheDigitalProjectManager.com for å bli med i Slack-teamet vårt. Der finner du mange interessante samtaler om prosjektleveranse. Vi har også en smidig kanal der vi gjerne diskuterer dette videre.

Hvis du likte det du hørte i dag, kan du abonnere og bruke et par minutter på å legge igjen en ærlig vurdering av DPM-podkasten på Apple Podcasts. Vurderinger og anmeldelser er svært nyttige og settes stor pris på. Takk for at du lyttet, og på gjensyn.