Skift fra vandfaldsmodellen til kontrakter baseret på varighed og pris (med Tucker Sauer-Pivonka fra Crema)

Læs transskriptionen:

Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Velkommen til DPM Podcast, hvor vi går videre end teorien for at give råd, der fungerer, når man skal lede bedre digitale projekter. Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager. Projekter går sjældent efter planen, og når planerne ændrer sig, skaber det ofte en masse stress. Der skal træffes beslutninger, planlægges møder, opdateres planer, genberegnes estimater og som regel udarbejdes ændringsanmodninger. Men hvad nu, hvis der var en anden måde at håndtere ændringer på i dine projekter? I denne podcast løfter vi sløret for en anderledes tilgang til håndtering af ændringer med agile kontrakter. Så lyt med for at forstå, hvordan du får agile kontrakter til at fungere for dig, og for at forstå fordelene og udfordringerne ved denne tilgang.

I dag har jeg besøg af Tucker Sauer-Pivonka. Han er direktør for produktledelse hos et bureau, der hjælper produktchefer med at vokse og udvikle sig. Han har også ansvaret for at videreudvikle deres bedste praksis. Hej, Tucker.

Tucker Sauer-Pivonka:

Hej Ben, dejligt at tale med dig i dag.

Ben Aston:

I lige måde. Noget, jeg gerne vil spørge dig om, når vi begynder, er, at en del af din rolle handler om udvikling af teamet. Kan du dele nogle af dine erfaringer med, hvad der virkelig har fungeret, når du skulle hjælpe dit team med at udvikle sig? Måske også i forbindelse med de kontrakter, I arbejder med eller eksperimenterer med. Hvordan plejer du teamet og hjælper dem med at vokse? Hvad har du fundet ud af, fungerer for dig?

Tucker Sauer-Pivonka:

Jeg tror, det første, man skal erkende tidligt, er, at alle lærer lidt forskelligt, og at alle har brug for forskellige former for coaching. Noget af det første, jeg gør med mine teammedlemmer, er derfor at sætte mig ned med dem og begynde at vurdere det. Hvordan lærer de? Hvordan vil de gerne modtage feedback? Hvordan vil de gerne have ros? Jeg holder styr på alt det, så jeg kan tilpasse min tilgang til noget, de reagerer bedre på. Jeg bruger meget tid på vores individuelle en-til-en-samtaler, hvor vi gennemgår forskellige emner og områder, hvor de kan udvikle sig. Jeg coacher dem i forhold til de udfordringer, de har på det pågældende tidspunkt. De opstår, når de opstår, og så tager vi fat på dem. Derudover har vi lige nu et bogstudie hos Crema omkring en bog, der hedder Multipliers.

Det er en stor del af vores teams udvikling. Og så er der selvfølgelig konferencer. Vi skal til en konference i slutningen af september, tror jeg. Den handler også om produktledelse. Vi tager af sted som team, både for at styrke teamet og for at lære om nye emner.

Ben Aston:

Spændende. Hvad hedder konferencen?

Tucker Sauer-Pivonka:

Den hedder Industry: The Product Conference og afholdes i Cincinnati, hvis jeg husker rigtigt.

Ben Aston:

Fest i Cincinnati, hvis du vil slutte dig til Tucker og teamet. Jeg vil gerne dykke ned i det, du nævnte om, at I måske gennemgår alle mulige forskellige emner med teamet. Kan du dele nogle af de emner eller områder, du hjælper teamet med? Hvilke udfordringer står teamet over for, som du hjælper dem med at overvinde?

Tucker Sauer-Pivonka:

Det ser igen lidt forskelligt ud for den enkelte, fordi folk på vores team har forskellige færdighedsniveauer. Noget af det, vi arbejder med i gruppesammenhæng, handler meget om kundehåndtering. For eksempel: “Min kunde sagde dette, eller min kunde beder os om at gøre det her, men vi har ikke rigtig talt om det. Hvordan skal jeg håndtere det?”

Kundehåndtering er typisk det vanskeligste at lære nogen, så det bliver mere en diskussion om: “Jeg havde det underligt med det her. Jeg ved ikke, om det var den rigtige måde at håndtere det på. Var det rigtigt, eller bør jeg håndtere det anderledes næste gang?” Det er som regel den retning, vores samtaler tager.

Ben Aston:

Det er så rigtigt. Der er bløde færdigheder inden for kundehåndtering og også teamledelse, ikke? Der er aldrig ét rigtigt svar. Det afhænger altid af situationen. Men vi kan altid udvikle os og blive bedre på de områder.

Du nævnte, at I tager til en konference som team, hvilket jeg synes er fantastisk. Jeg er nysgerrig efter at høre mere om, hvor du henter inspiration, og hvordan du holder dig opdateret med alt det, der sker. Hvordan holder du dig ajour, og hvordan bliver du inspireret?

Tucker Sauer-Pivonka:

Jeg holder mig inspireret ved at bruge mange forskellige kilder. En af dem er bøger, jeg læser. Jeg læser mange artikler, og Medium er et sted, jeg ofte går hen for at finde inspiration om produktledelse, teamledelse og hvordan det bør eller kan se ud. Jeg skal dog minde mig selv om, at Medium er en god ressource, men at man nogle gange skal tage tingene med et gran salt, fordi alle kan lægge en artikel op. Bare fordi man kan skrive noget på internettet, gør det ikke en person til ekspert. Men hvis man har den tilgang, kan det i det mindste give en vis kontekst til, hvordan man håndterer bestemte situationer.

Det bruger jeg en del. De to vigtigste kilder er nok bøger og artikler. Derudover læser jeg ting, der handler om branchen generelt. Jeg kan rigtig godt lide magasinet Wired, så jeg læser som regel de fleste artikler i hvert nummer. Det hjælper mig med at holde mig opdateret om forskellige tendenser uden for projektlederverdenen og om, hvad der generelt sker inden for teknologi.

Ben Aston:

Når det gælder teknologi, er du så en, der følger den nyeste udvikling? Hvad er det seneste stykke teknologi, du har købt?

Tucker Sauer-Pivonka:

Det er et godt spørgsmål. Jeg ville ønske, jeg havde noget virkelig spændende at fortælle dig. Jeg vil dog ikke sige, at jeg er helt på forkant med teknologien. Jeg betragter mig selv som en tidlig bruger, men ikke tidligere end det. Jeg prøver som regel at købe nye produkter, når de udkommer, hvis jeg kan. Lige nu drømmer jeg lidt om en ny iPad. Jeg har en iPad Pro, som fungerer fint, men jeg vil gerne have den nye version, og jeg kan ikke retfærdiggøre det. Det er det gode ved Apple-produkter: De fungerer fint, så der er ikke rigtig behov for at udskifte dem.

Den seneste version af iOS og iPadOS samt alt det, der kom ud af WWDC, var meget interessant for mig. Jeg har tænkt meget over, hvilken indvirkning det vil få på branchen som helhed og måske på nogle af de produkter, jeg udvikler. Det er det største, jeg har fulgt med i for nylig. Og så er jeg lidt af en Zelda-nørd, og efterfølgeren til Breath of the Wild blev netop annonceret, så det glæder jeg mig også meget til.

Ben Aston:

Jeg kigger i øjeblikket på DJI Rover. Jeg ved ikke, om det hedder en Rover, eller hvad det er, men de har annonceret den lille kamerating på en lille tank, som man selv bygger. Den ser fantastisk ud. Den står på min ønskeliste som det næste, jeg vil købe.

Tucker Sauer-Pivonka:

Det lyder sjovt.

Ben Aston:

Det er igen sådan en ting, hvor man spørger sig selv: Har jeg virkelig brug for det? Det har jeg ikke, men børnene vil sikkert synes, det er sjovt. Når du nu nævner, at du elsker din iPad Pro: Er der andet hardware eller software, du for nylig har fundet, som gør dit liv bedre, og som alle bør kende til?

Tucker Sauer-Pivonka:

Jeg har i årevis haft svært ved at finde balancen mellem håndskrevne noter, maskinskrevne noter og opgavestyring. Jeg har forsøgt at finde en balance, fordi der findes meget information om, at man forstår noget anderledes, når man skriver det ned, end når man skriver det på et tastatur. Det interesserer mig. I en periode skrev jeg noter på min iPad med Apple Pencil, og det fungerede ret godt. Men for nylig har jeg fundet en mellemvej.

Jeg har min iPad eller computer som det endelige arkiv for alt arbejdsrelateret, men jeg går også rundt med en lille notesbog, hvor jeg tager daglige noter og skriver opgaver ned, efterhånden som de opstår. I slutningen af dagen overfører jeg det til en app, der hedder Todoist, så jeg kan holde styr på mine opgaver. Jeg lægger også mine noter ind der og behandler dem i slutningen af dagen.

Jeg er først lige begyndt at komme ind i den arbejdsgang, men det har virkelig været den største ændring i min måde at arbejde på. Det har været meget hjælpsomt. Jeg bemærker, at jeg forstår det, jeg laver, lidt bedre. Samtidig hjælper det mig med at holde bedre styr på mine opgaver, så jeg ikke straks kaster mig over dem. Selv fra et tidsstyringsperspektiv har det været meget nyttigt.

Ben Aston:

Interessant. Så du bruger en fysisk notesbog til noter, påmindelser og den slags? Det er dér, du er gået tilbage til det analoge?

Tucker Sauer-Pivonka:

Ja, men det ender til sidst i et digitalt system. For mig kan intet erstatte at åbne en notesbog, klikke med kuglepennen og begynde at skrive. Min største udfordring med at bruge iPad og Apple Pencil er, at der går tid med at åbne den rigtige app, finde den rigtige notesbog og sikre sig, at Apple Pencil er opladet. Det er små ting, men de bliver barrierer for bare at kunne skrive en note.

Jeg opdagede, at jeg gik rundt med min iPad og en million post-it-sedler, fordi jeg skrev på dem, når jeg havde et problem eller bare skulle i gang med noget. Det var ikke holdbart, og det var lidt fjollet at gå rundt med alle de post-it-sedler. Derfor skiftede jeg til en notesbog.

Ben Aston:

Det er en kamp, jeg også kender. Min seneste tilgang er Evernote. Jeg har én notesbog, som er min opgaveliste, og en anden, som jeg kalder en skitseblok. Den fungerer som en losseplads. Hvis jeg bliver meget perfektionistisk omkring mine noter, vil jeg gerne have, at min opgaveliste ser pæn og struktureret ud, men jeg ødelagde den altid.

Nu har jeg introduceret denne skitseblok, hvor alt det rå materiale kommer ind, og derefter overføres det til min opgaveliste. Det lyder som et lignende system. Jeg har også en lille notesblok, som bevidst er så lille, at jeg ikke kan skrive noter i den. Jeg kan skrive påmindelser, men ikke noter. På den måde tvinger den mig til at bruge mit system. Ellers begynder jeg at lave forskellige lister forskellige steder, og det ender i et stort rod.

Lad os tale om artiklen. Det var en case, du skrev for os, og den handler om at skifte fra kontrakter baseret på vandfaldsmodellen til kontrakter baseret på varighed og pris. Vi har talt om agile kontrakter før. I DPM-skolen var der i denne uge en, der spurgte: “Giv mig et eksempel på en agil kontrakt.” Alexa har tidligere skrevet et godt indlæg om agile kontrakter. For dem, der ikke kender agile kontrakter, kan du så kort forklare, hvad en kontrakt baseret på varighed og pris er, og hvordan den fungerer?

Tucker Sauer-Pivonka:

Jeg vil forklare, hvordan den fungerer ud fra den måde, vi gør det på her hos Crema. Det betyder ikke, at alle skal bruge præcis den samme formel, men det er den model, jeg kender bedst. En kontrakt baseret på varighed og pris centrerer i praksis projektet omkring et dedikeret team. Det kan for eksempel være to fuldtidsudviklere, en testingeniør på halv tid, en designer på en kvart eller halv tid, en produktchef og måske en strateg på en kvart tid.

Fokus er altså mere på teamet og de mål, man forsøger at nå, end på en detaljeret liste over leverancer og funktioner med præcise timeestimater ved siden af. Det, vi har erfaret, og grunden til, at vi har stor succes med denne model, er, at software er for komplekst til at estimere alt på forhånd og antage, at alt vil gå præcis efter planen. Det ville være fantastisk, hvis vi kunne planlægge alt, og alt derefter skete præcis, som vi havde tænkt os. Men sådan fungerer det aldrig.

Disse kontrakter gør det muligt for os og vores kunder at flytte fokus til det arbejde, der har den højeste prioritet. På den måde leverer vi ved periodens afslutning og undervejs i de iterative cyklusser den højeste værdi for virksomheden. I en fastpriskontrakt kan prioriteterne ændre sig over tid. Hvis det for eksempel er en kontrakt på seks måneder, kan man ende med at levere funktioner, der ikke længere er relevante for virksomheden. Denne model gør det muligt at skifte retning, så vi matcher kundens behov.

Ben Aston:

Hvilke typer projekter fungerer godt med agile kontrakter?

Tucker Sauer-Pivonka:

Det fungerer godt til produkt- og softwareudvikling, hvor det er vanskeligt at beskrive alle detaljer på forhånd, og hvor man har brug for fleksibilitet. Hvis noget derimod er gentageligt, som standardwebsites med et bestemt antal sider og et bestemt layout, kan en fastprismodel give mere mening. Det handler i høj grad om forudsigelighed kontra uforudsigelighed.

En kontrakt baseret på varighed og pris fungerer, fordi kunden køber en bestemt kapacitet fra et team i en bestemt periode. Man betaler ikke time for time for en bestemt funktion. I stedet leverer teamet løbende værdi og prioriterer arbejdet sammen med kunden.

Ben Aston:

Hvordan håndterer I situationer, hvor kunden mener, at han eller hun ikke har fået tilstrækkelig værdi for tiden?

Tucker Sauer-Pivonka:

Det sker ikke særlig ofte, fordi vi arbejder meget målrettet på at skabe fælles forståelse med kunderne. Ikke kun ved begyndelsen af hvert sprint, men gennem hele sprintet. God kommunikation og god kundehåndtering er afgørende.

Vi er ærlige om ændringer og usikkerheder. Hvis noget, vi troede ville tage to sprints, viser sig at tage tre eller fire, forklarer vi, hvad vi har fundet ud af, og hvorfor det påvirker tidsplanen. Vi viser også kunden, at vi kan gå tilbage og vælge noget andet, hvis det er vigtigere. Når alle fakta ligger på bordet, bliver beslutningerne mindre følelsesladede.

Ben Aston:

Hvordan kom I frem til den oprindelige vurdering på syv måneder?

Tucker Sauer-Pivonka:

I det konkrete tilfælde havde vi først gennemført en prototypings- og testfase samt en teknisk gennemgang af det eksisterende system. Derefter vurderede produktionsteamet kompleksiteten og opdelte de forskellige dele i omtrentlige T-shirt-størrelser. På baggrund af det anbefalede vi teamets størrelse og sammensætning.

Varigheden handler ikke om en fast liste over leverancer, men om forretningsmålene og kundens budget. Software bliver aldrig helt færdig. Vi vurderede, at der var nok arbejde til mindst syv måneder for at nå de mål, kunden havde på det tidspunkt, samtidig med at vi fortsat kunne prioritere arbejdet på ny i hvert sprint.

Ben Aston:

Så man kan i praksis leje et team i tre måneder, seks måneder eller et år?

Tucker Sauer-Pivonka:

Præcis. Kunden får det, teamet kan producere i den valgte periode. Hvis kunden kun ønsker en kontrakt på tre måneder, er det helt fint. Så fokuserer vi på det vigtigste arbejde inden for de tre måneder. Det handler om at arbejde på det, der har højeste prioritet.

Ben Aston:

Hvordan fungerer prototypings- og valideringsfasen? Er den fastprisbaseret?

Tucker Sauer-Pivonka:

Den følger teknisk set stadig vores model baseret på varighed og pris, men den er mere fast defineret end vores almindelige kontrakter. Vi kan for eksempel aftale, at vi leverer en prototype med høj detaljeringsgrad, designfiler, brugerinterviews, noter og den tilhørende research.

Hvis vi efter tre uger opdager, at brugerne ikke ønsker det, vi arbejder på, kan vi gå tilbage til tegnebrættet. Vi er ikke bundet til et bestemt antal skærmbilleder eller en fast specifikation. Det er fortsat en model baseret på varighed og pris.

Ben Aston:

Lad os tale om metode. I casen beskriver du en tilgang, der er agil og Scrum-inspireret. Hvad tager I med fra Scrum, og hvad lader I ligge?

Tucker Sauer-Pivonka:

Vi siger ofte, at vi sætter mennesker over processer. Vi praktiserer Scrum med lille s. Det betyder, at processen skal være fleksibel nok til, at den ikke begrænser folk. Hvis et team har brug for at tilpasse processen til kunden, har de fuld frihed til at gøre det.

I en bureaustruktur er det sværere at have dedikerede roller til alt. Kundens daglige kontakt fungerer typisk som produktejer. Hvis der er en strateg på projektet, fungerer strategen nogle gange som en slags medproduktejer og hjælper kunden med at træffe beslutninger om produktets overordnede retning.

På vores side kombinerer vi produktchefens og Scrum-masterens roller. Det strider mod den traditionelle Scrum-metode, men det fungerer for os. Vi planlægger sprints, estimerer, holder retrospektiver og laver produktdemoer. De fleste af vores daglige statusmøder er automatiserede, men vi følger op på dem og fjerner blokeringer. Overordnet set ligner det stadig Scrum, men rollerne er tilpasset vores bureaukontekst.

Ben Aston:

Hvordan håndterer I ændringer i prioriteter, når kunden både vil have udviklet noget nyt og samtidig have repareret det gamle system?

Tucker Sauer-Pivonka:

Det første er at være empatisk over for årsagen til ændringen. Kunden ønsker som regel ikke at ændre prioriteten, men er nødt til det på grund af en forretningsmæssig situation. Man skal forstå, om der er tale om en reel høj prioritet, en interessent, der presser på, eller noget andet. Alle svar kan være rimelige, men det er vigtigt at forstå baggrunden.

Derefter skal man kommunikere meget tydeligt, at en ændring af prioriteten ændrer planen. Hvis teamet stopper arbejdet på en funktion for at fokusere på noget andet, bliver den oprindelige funktion forsinket. Det er helt i orden, hvis alle forstår konsekvensen.

Visuelle værktøjer kan være nyttige. Vi giver kunder adgang til Jira og andre værktøjer, så de kan se prioriteter, krav og den aktuelle retning. Vi har også kunderne som gæster i vores Slack-team. Det skaber gennemsigtighed og hjælper dem med at forstå, hvad der sker.

Ben Aston:

Hvordan undgår I at overvælde kunderne med alle disse oplysninger?

Tucker Sauer-Pivonka:

Vi kræver ikke, at kunderne bruger værktøjerne. Vi sørger bare for, at de har adgang, hvis de ønsker det. Vi laver også personlige skærmoptagelser, hvor vi viser, hvordan værktøjerne fungerer, hvor man finder det relevante, og hvilke områder kunden ikke behøver at bekymre sig om.

Derudover leverer vi tingene iterativt, så kunden ikke pludselig får 500 skærmbilleder i skødet. Det er ikke altid muligt, men når vi er åbne om ophobning af arbejde, hjælper det meget.

Ben Aston:

Rapporterer I om tidsforbrug og timesedler?

Tucker Sauer-Pivonka:

Vi rapporterer primært på resultater. Ved afslutningen af hvert sprint gennemgår vi, hvad der blev færdigt, hvad der ikke blev færdigt, og hvordan vores hastighed udviklede sig. Vi rapporterer ikke på timer, fordi kunden ikke køber bestemte timer til bestemte funktioner. Vi bruger dog oplysningerne internt til at sikre, at teamets kapacitet er korrekt fordelt.

Hvis en person, der skulle arbejde halvtid på et projekt, konsekvent bruger mere tid, taler vi med kunden om enten at fjerne noget fra personens opgaver eller øge kapaciteten. Men vi rapporterer ikke disse udsving som et timebaseret regnskab.

Ben Aston:

Hvornår fungerer kontrakter baseret på varighed og pris ikke?

Tucker Sauer-Pivonka:

Hvis kunden begynder at føle sig skuffet over fremdriften, skal man reagere tidligt. Hvis man kommunikerer ofte, vil man som regel kunne mærke, at noget er forkert. Så bør man sige: “Jeg har en fornemmelse af, at vi ikke er helt på samme side. Kan vi tale om det?” Man skal undersøge, hvad der skaber frustrationen, mens der stadig er tid til at rette op på det.

Jeg har ikke oplevet, at noget er faldet fuldstændigt fra hinanden. I en situation var kunden skuffet over fremdriften, men det viste sig, at vi havde skiftet til andet arbejde på grund af en ændring i prioriteringen. Da vi forklarede det, forstod kunden situationen. Den slags samtaler bygger tillid, fordi kunden kan se, hvilke konsekvenser ændringerne har.

Det kræver dog den rigtige kunde. Kunden skal være moden nok til at forstå, at arbejdet tager tid, og at ændrede prioriteter påvirker både tidsplan og omfang. Derfor er salgsprocessen og kundens oplæring vigtig. Når kunden forstår modellen, kan teamet løbende levere den værdi, der er vigtigst for virksomheden.

Ben Aston:

Det lyder som en interessant model. Tak fordi du deltog i dag, Tucker.

Tucker Sauer-Pivonka:

Selv tak. Det har været en fantastisk samtale. Tak fordi du havde mig med.

Ben Aston:

Hvad tænker du? Har du prøvet en agil kontrakt? Jeg vil gerne høre, hvordan det gik. Skriv en kommentar til dette indlæg, og gå til TheDigitalProjectManager.com for at deltage i vores Slack-team. Her finder du alle mulige interessante samtaler om projektleverancer. Vi har også en agil kanal, hvor det ville være fantastisk at diskutere dette.

Hvis du kunne lide det, du hørte i dag, så abonnér, og brug et par minutter på at skrive en ærlig anmeldelse af DPM-podcasten på Apple Podcasts. Bedømmelser og anmeldelser hjælper os meget, og det sætter vi stor pris på. Indtil næste gang: Tak fordi du lyttede.