Å jobbe baklengs for å gå fremover (med Jeff Gothelf fra Gothelf.co)

Les transkripsjonen:

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

Ben Aston:

For å være ærlig: Leverer prosjektene dine noen gang virkelig det du håpet at de skulle levere? Kunne eller burde de gjøre det? Hvorfor er det slik? Er det kanskje fordi du ikke planla? Fordi du ikke ledet teamet ditt godt? Eller kanskje fordi du slet med å håndtere interessentene dine? Kanskje det er alt dette. Kanskje det er fordi dere ikke var fullt ut samkjørte om det endelige resultatet og visjonen for prosjektene. Så fortsett å lytte til dagens podkast hvis du vil lære hvordan du kan jobbe baklengs for å gå mer selvsikkert fremover med gode prosjekter, redusere risikoen for å mislykkes og øke sjansene for at prosjektet lykkes.

Takk for at du lytter. Jeg heter Ben Aston og er grunnleggeren av The Digital Project Manager. Velkommen til DPM-podkasten. Vi har som mål å hjelpe prosjektledere med å lykkes, og å hjelpe mennesker som leder prosjekter med å levere bedre. Vi er her for å hjelpe deg med å ta prosjektarbeidet ditt til neste nivå.

Besøk thedigitalprojectmanager.com for å lære mer om opplæringen og ressursene våre, som vi tilbyr gjennom medlemskap. Denne podkasten er levert av Clarizen, lederen innen programvare for virksomhetsomfattende prosjekt- og porteføljestyring. Besøk Clarizen.com for å lære mer.

I dag har jeg med meg Jeff Gothelf. Jeff underviser ledere og team gjennom fjernrådgivning, coaching, workshops, hovedinnlegg og bøker, med fokus på kundene, på å lære av feil og på å skape en agil kultur som kontinuerlig forbedrer produktene og tjenestene sine og måten de arbeider på.

Han er medforfatter av en rekke bøker du har lest, eller i det minste sannsynligvis hørt om, blant annet Sense and Respond. Lean UX er den store boken her. Lean versus Agile versus Design Thinking. Nylig var han med på å grunnlegge Sense and Respond Press, et forlag for moderne, transformasjonsorienterte næringslivsbøker. Så hei, Jeff, tusen takk for at du blir med oss i dag.

Jeff Gothelf:

Hei, Ben. Takk for at jeg fikk være med.

Ben Aston:

Jeg vil faktisk begynne med å snakke om prosjekter. Jeg vet at du i stor grad er en produktorientert person, men for oss prosjektledere som leder prosjekter, kan de være del av et større arbeidsprogram eller et produktveikart.

Jeg er nysgjerrig på hvordan du mener at vi som prosjektledere kan hjelpe oss selv og teamene våre med å orientere oss mot en mer iterativ tilnærming. Jeg vet også at du nettopp har skrevet et innlegg om de ti viktigste motsvarene til «Agilt er flott, men det vil ikke fungere her». Jeg vil gjerne snakke om noen av utfordringene som jeg mener vi møter som digitale prosjektledere, og hvorfor.

I bunn og grunn tror jeg at kundene vi arbeider med, og alle interessentene, liker ideen om å arbeide agilt. Vi kan selvfølgelig diskutere hva agilitet betyr, men enten vi snakker om et leveranserammeverk eller mer generelt om en tankemåte, synes jeg vi bør snakke om denne tankemessige tilnærmingen til agilitet.

Jeg tror likevel at det er tre utfordringer vi må snakke om. For det første klientmistillit. Deretter altfor stramt definerte krav. For det tredje manglende budsjett og tid. Kundene ønsker å være agile, men har ikke alltid budsjett til å arbeide slik.

Kundene har for stramt definerte krav, og i tillegg kommer klientmistillit. Kundene stoler ikke helt på byrået eller teamet nok til å slippe taket og stole på prosessen. Det er altså tre utfordringer. Hvilken vil du snakke om først?

Jeff Gothelf:

La oss snakke om endringen i tankesett først, for jeg tror det er det avgjørende, særlig for digitale prosjektledere å forstå. Hvis vi skal lykkes med å bygge gode team, gode produkter, gode tjenester, vellykkede selskaper og fornøyde kunder og brukere, er det viktig å innse den grunnleggende forskjellen i dagens digitale produktutvikling.

Den grunnleggende forskjellen i dag sammenlignet med for ti eller femten år siden er at programvare nå er kontinuerlig. Vi går ikke lenger til butikken og kjøper en eske med programvare. Vi abonnerer på den, eller installerer den, laster den ned, installerer den og lar den oppdateres kontinuerlig.

Den blir stadig bedre. Du går ikke til en butikk og kjøper neste versjon av Facebook. Du går ikke til butikken og kjøper neste versjon av Pinterest eller Amazon eller noe annet. Det blir kontinuerlig bedre, eller forbedres og endres over tid. Det er den grunnleggende forskjellen mellom prosjekt- og produkttenkning. Prosjekter og produkter tar ikke slutt.

I dag bygger vi disse systemene, disse kontinuerlige systemene, der vi har et valg i hver syklus. Du kan kalle det en sprint eller en iterasjon, hva du vil. Men vi kan velge hvordan vi skal gjøre systemet bedre. Skal vi legge til noe? Skal vi optimalisere det som allerede finnes? Skal vi fjerne noe?

Det finnes mange ting vi kan gjøre, men det er omtrent de tre kategoriene. Det er det viktigste å ta med seg, for disse tingene tar ikke slutt. Tanken om «Jeg leder prosjektet frem til en vellykket lansering» er grei nok, men en lansering er bare begynnelsen på samtalen med målgruppen din. Den er ikke slutten på produktet.

Ben Aston:

Absolutt. En av tingene jeg mener vi som digitale prosjektledere møter når vi prøver å snakke med kunder om en mer agil arbeidsform, er at vi sier: «Betal oss bare for et dedikert team i en bestemt periode, så samarbeider vi.» La oss si at vi har lansert nettstedet ditt. Nå kan vi iterere på det.

Det er kanskje slik du beskriver programvare og kontinuerlige oppdateringer. Kanskje nettstedet deres gjør det samme. Men det avhenger av tillit – at den som betaler, får god verdi ut av prosessen. Hvordan kan vi som prosjektledere, som mennesker som prøver å veilede kundene gjennom denne prosessen, hjelpe dem gjennom mistilliten når leveransene er ukjente?

Jeff Gothelf:

Det er mye å pakke ut her, så la oss begynne med det grunnleggende: Hvilken virksomhet driver du? Du må virkelig stille det spørsmålet når du ser på dette fra kundens, leverandørens eller tjenesteleverandørens ståsted.

Driver du en virksomhet der du samarbeider med kundene for å hjelpe dem med å oppnå resultater, eller leverer du et strengt definert sett med krav? Som du sier, er det en grunnleggende motsetning mellom «Her er kravene, men vær så snill å være agil med dem».

Det gir ikke mening. Det finnes et spekter jeg lærte av vennen og kollegaen min, Jeff Patton, som gjør det lettere å tenke rundt dette spørsmålet. I den ene enden av spekteret har du ordet lege. I den andre enden har du ordet servitør.

Jeg vil utfordre deg som tjenesteleverandør til å tenke over hvor på dette spekteret du befinner deg. Hvis du er på servitørsiden, er jobben din å gi meg nøyaktig det jeg ba om.

Ben Aston:

Riktig.

Jeff Gothelf:

Om du spiser det eller ikke, eller liker det eller ikke, er ikke mitt problem. Du ba om biff med salat og en cola. Det var det jeg tok med. Det finnes mange organisasjoner som gjør nettopp dette: «Gi meg 100 000, så bygger jeg arken til deg.» På legesiden er det annerledes.

Du forteller ikke legen: «Jeg vil ha denne medisinen, denne vaksinen og denne behandlingen», og så sier legen: «Greit, det skal du få.» Legen arbeider som rådgiver for å hjelpe deg med å forbedre deg, og til syvende og sist forbedre nøkkeltallene og måleverdiene dine.

Spørsmålet er derfor hvor på spekteret du befinner deg. Det er betydelig enklere å være agil på legesiden enn på servitørsiden, fordi målene på suksess er grunnleggende forskjellige. På servitørsiden er suksessmålet resultatet: Leverer du det jeg ba om, i tide og innenfor budsjett?

På den andre siden handler det om resultater og endret atferd – om endringer i kundenes atferd og målene for denne atferden. Fikk vi kundene til å kjøpe mer, bruke mer, bruke mer tid, fortelle vennene sine om oss eller kjøpe mer enn ett produkt fra oss? Det er her agilitet virkelig skinner, når det finnes stor usikkerhet og ingen tydelig forståelse av nøyaktig hva som vil gi det forretningsresultatet vi ønsker.

Agilitet kan ikke komme inn i samtalen før du begynner å flytte det du leverer, og måten du leverer det på, bort fra servitørsiden av spekteret og mot legesiden.

Ben Aston:

Det handler altså om at kunden eller interessenten må gå fra å se seg selv som den som har kontroll, til å bygge tillit. Når du coacher organisasjoner, hvordan oppmuntrer du folk til å se forbi det ukjente og få appetitt på det? Det finnes som regel en forretningsdriver for et prosjekt eller en produktiterasjon, men vi hopper ofte på den lavthengende frukten, og den blir prosjektet eller neste iterasjon.

Hvordan hjelper du folk med å forstå verdien av et mer agilt tankesett, slik at de får appetitt på en mer rådgivende, legeaktig tilnærming i stedet for en servitørtilnærming?

Jeff Gothelf:

Måten å gjøre det på er å finne en respektfull måte å stille spørsmålet «hvorfor?» på uten å begrense engasjementet. Når noen sier «Jeg trenger disse ti funksjonene innen fredag, hvor mye koster det?», må du respektfullt kunne spørre: «Hvorfor ønsker du disse funksjonene?»

Du gjør det ved å samarbeide med kundene om å omforme faste krav til en problemformulering – problemet organisasjonen eller teamet prøver å løse. Når teamet sier «Jeg trenger mobilappen innen fredag, hvor mye koster det?», spør du «Hvorfor trenger dere mobilappen?» Svaret kan være at mobilhandelstallene har falt, og at de må øke mobilhandelen.

Da er problemet vi prøver å løse, å få flere til å kjøpe gjennom mobilkanalen. Hvor mye mer? En økning på 15 prosent ville vært betydelig. Flott. Se hva vi gjorde: Vi omformet «Bygg en mobilapp» til «Øk mobilhandelen med 15 prosent».

Du har fjernet det spesifikke kravet fra samtalen. Det tvinger teamet til å være agilt når det gjelder å teste, eksperimentere, lære, iterere og forbedre løsningen – til et punkt der mobilhandelen øker med 15 prosent. Det er suksessmålet, ikke å lansere appen.

Det er stor risiko i å anta at funksjonssettet ditt vil gi resultatene du tror det vil gi. Som oftest tar du feil, uansett hvor god du er. En god produktleder har rett omtrent 30 prosent av tiden.

Hvis du kommer til å ta feil 70 prosent av tiden, ville du ikke heller bruke en prosess som lar deg oppdage den mest presise måten å nå målene dine på så raskt som mulig, i stedet for blindt å si «Send meg en app innen torsdag, gjør den blå og la den gjøre disse fem tingene»? Det er den grunnleggende forskjellen.

Ben Aston:

Jeg synes det er svært klokt. Å omformulere forespørselen fra kunden til problemformuleringer og gå inn i hvorfor-spørsmålet er verdifullt. Det endrer samtalen fra en kravliste til noe som gir oss rom til å utforske problemet og finne løsninger vi kan bygge, teste, lære av og iterere på.

Det hjelper oss med stramt definerte krav, som var den andre utfordringen. Jeg vil også berøre den tredje utfordringen. I innlegget ditt «Agilt er flott, men det vil ikke fungere her» – tror du mangel på budsjett og tid kan være en grunn til at agilitet ikke fungerer?

Jeff Gothelf:

For meg handler dette om en grunnleggende misforståelse av hva agile prosesser tilfører. Det er ikke et spørsmål om budsjett eller tid. Det handler om risikoreduksjon. I stedet for å arbeide i tre måneder med noens idé om hva suksess ser ut som, kan vi begynne å lære så raskt som mulig om vi er på riktig vei. Hvis vi ikke er det, justerer vi kursen.

Hvis teamet justerer kursen basert på bevis fra markedet, arbeider det agilt. Det har ingenting med budsjett eller tid å gjøre. Alternativet kan være at det koster 75 000 dollar å bygge appen den neste måneden. Flott. Er det et godt eller dårlig estimat? Ingen vet. Du bygger det beste du kan innenfor tidsrammen, og så er budsjettet brukt opp. Hva skjer hvis det ikke fungerer?

Det er risikoen du tar ved å utvikle et digitalt produkt med en fossefallsmetode, med en forutsigbar, ovenfra-og-ned, forskrivende tilnærming. Du sier: «Jeg vet hva det må være, hvordan det må se ut, hva det må gjøre, og jeg trenger det innen denne datoen.» Det er et svært risikabelt perspektiv.

Ben Aston:

Men det avhenger av hvem som stiller kravet. Tilbake til eksempelet med biff, salat og cola: Hvis jeg har tretti dollar og vil ha biff, cola og salat, er det det jeg vil ha, selv om det ikke er det som er best for meg.

Jeff Gothelf:

Ja, og da går du til en servitør. Hvis du går til legen, måler legen kroppsmasseindeks, vekt, blodtrykk og kolesterol. Hvis du sier «Jeg vil ha biff og cola», sier legen nei, fordi jobben ikke er å gi deg biff, salat og cola. Jobben er å gjøre deg sunnere.

En servitør bryr seg ikke om helsen din. Servitøren gir deg det du ber om, fordi det er jobben og virksomheten de driver. Det mange tjenesteleverandører ikke forstår med agilitet, er at dette ikke er én prosess kontra en annen. Det er én forretningsmodell kontra en annen.

Ben Aston:

Det krever modenhet hos den som bestiller arbeidet, slik at de kan legge til rette for dette.

Jeff Gothelf:

Nettopp.

Ben Aston:

Det handler virkelig om den nødvendige modenheten. For oss som arbeider i byråer med kunder som bare vil ha biff, salat og cola innen neste torsdag, er dette en stor utfordring. Jeg tror utfordringen er å omformulere forespørselen, ta på seg legehatten og kvitte seg med servitøruniformen.

Du har skrevet et flott innlegg om kundesentrering og planlegging av kundesentrerte prosjekter, med en oppdatert versjon av teknikken med en pressemelding fra fremtiden. Den bygger på Amazons «arbeid baklengs»-prosess og fokuserer sterkt på resultater, risikostyring og samarbeid. Uten å avsløre hele innlegget: Hvordan hjelper denne tilnærmingen i praksis?

Jeff Gothelf:

Først og fremst begynner den å forestille seg en fremtid der du har lykkes, og den tvinger deg til å tenke gjennom hva som gjorde deg vellykket. Variasjonen i artikkelen setter kunden i sentrum – ikke bare «Vi leverte dette fantastiske nye systemet, alle elsket det, og vi tjente masse penger».

Den handler om hva vi leverte, hvilken atferdsendring vi så, og hvilke resultater vi oppnådde. For å komme dit måtte vi ikke bare vurdere suksess ut fra kundeatferd, men også tenke grundig gjennom hvordan vi skulle skape denne verdien for kunden på tvers av organisasjonen.

Hvilke samarbeidsutfordringer måtte vi håndtere? Hvordan hjalp dette virksomheten? Dette tvinger teamet til å gjennomføre en forhåndsanalyse av hva som kan gå galt: Når vi lanserer dette og det lykkes i markedet, hvordan vet vi at det lyktes? Hva tror vi at vi må ha overvunnet for å komme dit?

Dette er en samtale som sjelden skjer i starten av et initiativ. Vanligvis sier man «Bygg dette», og suksess betyr at det leveres i tide og innenfor budsjett. Her sier vi at suksess er å bygge en prosess som påvirker kundene positivt og gjør dem mer vellykkede – og dermed også gjør virksomheten mer vellykket.

Hvis dere har denne samtalen i begynnelsen, tvinger den dere til å tenke gjennom arbeidet underveis. Dere kan bruke pressemeldingen fra fremtiden som et filter: Vil dette hjelpe oss med å nå målet? Hvis ikke, lar vi være å gjøre det og gjør noe annet. Det er svært kraftfullt.

Ben Aston:

For dem som ikke har lest innlegget, handler dette om å forestille seg fremtidstilstanden og se inn i krystallkulen. På mange måter ser vi på produkt–marked-tilpasning, ønskelighet, gjennomførbarhet og levedyktighet. Finnes det et stort marked med mennesker som virkelig trenger dette problemet løst? Vil forretningsmodellen fungere? Kan vi faktisk gjøre det?

Det er en god risikolinse. Vi bruker empati til å se fremover og spørre om dette vil oppfylle kravene våre. Men siden vi bruker forestillingsevnen, hvordan validerer vi dette? Hvor ofte har du skrevet fremtidige pressemeldinger, og hvordan validerer du dem? Som produktleder har du jo bare rett 30 prosent av tiden.

Jeff Gothelf:

Dette gir oss et mål. Det er ambisiøst og noe teamet sikter mot. Du prøver å forutsi fremtiden, så du vil ta feil om deler av den. Men totalt sett prøver du å forutsi hvordan suksess ser ut, hvilke hindringer du møtte og hvordan du overvant dem. Du prøver å fortelle en overbevisende historie.

Du må leve opp til historien mens du arbeider deg gjennom initiativet. Noe vil uunngåelig ikke bli virkelighet, og det er greit, så lenge du tydelig og objektivt kan forklare hvorfor. Historien kan endres, men målet og ambisjonen består.

Vi filtrerer beslutningene våre gjennom dette helt til vi får bevis fra markedet som viser at beslutningene gir et dårligere resultat. Da endrer vi kurs.

Ben Aston:

Vi flytter fokuset. Vi lærer at denne delen av den ambisiøse målsettingen ikke lenger er gyldig eller verdifull, og justerer den før vi går videre. Du flytter ikke målstengene; du justerer målet basert på virkeligheten du ikke hadde i begynnelsen av prosjektet.

Finnes det noe som ikke fungerer godt med denne tilnærmingen? Kan den hemme teamet eller kreativiteten? Du har sagt at dette er en videreutvikling av Amazons metode. Kan du forklare hvorfor du videreutviklet den, og hvilke utfordringer det kan føre til?

Jeff Gothelf:

Den største utfordringen er at teamene ikke er kreative eller ambisiøse nok. De gjør dokumentet veldig trygt. På amerikansk engelsk kalles dette å «sandbagge»: Du setter et mål du vet at du vil nå.

Den største risikoen er derfor at du ikke forutser de store problemene og ikke setter suksesskriteriene høyt nok. Amazon har brukt dette med stor suksess. Min videreutvikling består av to deler. Den opprinnelige malen manglet fokus på resultater – målbare endringer i kundeatferd som viser at vi har levert noe av verdi.

Den opprinnelige malen snakket om forretningsfordeler, som at vi tjente penger eller ikke mistet kunder. Men hvilken kundeatferd ønsker vi faktisk å se? Hvis dette lykkes, er det denne atferden som fører til inntekter og kundelojalitet.

Den andre mangelen var en diskusjon om samarbeidsutfordringer. Ingenting leveres til markedet av produktteamet alene. Det må gjennom juridisk avdeling, økonomi, markedsføring, drift og samsvar. Hvordan skal vi samarbeide på tvers av organisasjonen for å levere den opplevelsen vi sikter mot?

Dette er avgjørende for en vellykket lansering, særlig i organisasjoner med mer enn rundt førti eller femti personer. Dere er ikke en øy. Dere kommer ikke til å levere dette alene. Derfor må dere involvere disse menneskene tidligere enn dere vanligvis ville gjort hvis dere skal nå den ambisiøse målsettingen.

Ben Aston:

Dette er svært kraftfullt. Vi tenker ikke bare på resultatene, men også gjennom prosessen. Vi kan ofte identifisere gode mål og suksessmål, men det er kommunikasjonen og samarbeidet i prosessen som ofte svikter.

Les Jeffs innlegg om å jobbe baklengs for å gå fremover. Jeg er sikker på at du vil finne mange nyttige poenger der.

Jeg vil skifte spor og gå litt inn i prosessen, som jeg vet at du brenner for. Du har arbeidet med rådgivning, oppstartsbedrifter og byråer, og nå arbeider du for deg selv. Hvordan ser du at prosessene og metodene vi bruker for å levere ting, utvikler seg?

Vi har utviklingen av agile prosesser. I bunn og grunn er den den samme, men vi har også lean, agilitet, designtenkning og tjenestedesign. Hvordan ser du at prosessene modnes, og hva tror du er fremtiden for disse teknikkene og rammeverkene?

Jeff Gothelf:

Uunngåelig vil agilitet etter hvert bli standarden i organisasjoner over hele verden. Pandemien vi opplever, vil fremskynde dette. Organisasjonene som allerede er agile, og som forbedrer evnen til å sanse og reagere, vil overleve.

Organisasjoner som ikke klarer det, eller som ikke har dette i sitt DNA, vil lide og potensielt bli utslettet. Agilitet må bli normen fordi endringstakten og volatiliteten i markedene og verden bare øker. Hvis du fungerer som en monolitt, vil du synke som en monolitt.

Hvis du derimot fungerer som et sett med delvis autonome team som sanser, reagerer, lærer, deler kunnskap og justerer kurs basert på bevis, kan du overleve store kriser.

Om vi om tjue år fortsatt snakker om sprinter, hastighet, burndown-diagrammer og produktkøer, vet jeg ikke. Språket og merkenavnene kan endres, men jeg kan ikke forestille meg en vellykket økonomisk virkelighet der kundesentrering, kontinuerlig læring og kontinuerlig forbedring ikke er de facto-måtene å lede en organisasjon på.

Dette er kjernefilosofiene bak agilitet. Det er dit jeg tror fremtiden går, og krisen vi lever gjennom, vil trolig fremskynde utviklingen ytterligere.

Ben Aston:

Du er tydeligvis opptatt av Lean og har skrevet mye om det. Det finnes også spesifikke teknikker innen designtenkning og tjenestedesign, og noen av dem kan være ganske forskrivende. Trenger vi alle disse? Hvordan fungerer de sammen? Hva er ditt filosofiske syn på agil utvikling kontra designtenkning?

Jeff Gothelf:

Jeg skrev en kort bok som heter Lean versus Agile versus Design Thinking. Hovedideen er at dette er ulike merkenavn oppå svært like filosofier. Navnene og aktivitetene er forskjellige, og rytmen kan variere litt, men filosofisk sett er dette de samme tingene.

Organisasjonen må velge én, kombinere dem eller lage noe som fungerer for dere. Målet er ikke å implementere en oppskrift blindt, men å øke organisasjonens agilitet. Derfor er oppskriften du velger, til syvende og sist ikke det viktigste.

Tenk på det som matlaging. En nybegynner finner en kokebok eller oppskrift på internett og følger instruksjonene ord for ord. Etter hvert blir du flink til å følge oppskriften og begynner å tilpasse den. Til slutt blir du en profesjonell kokk. Profesjonelle kokker trenger ikke oppskrifter; de vet hvordan de skal arbeide i ulike kjøkkenmiljøer.

Det er det høyeste modenhetsnivået for et team eller en organisasjon: å vite hvordan man er agil i ethvert miljø ved hjelp av ulike verktøy og metoder. Organisasjoner som binder seg til én oppskrift, setter seg selv opp for å mislykkes. Reisen handler om agilitet, ikke om å implementere oppskriften.

Ben Aston:

Det er derfor «slik skal det ikke gjøres» bør skape bekymring. Prosessen kan itereres, og det handler ikke om å følge den slavisk. Spørsmålet bør være om tilnærmingen hjelper oss med å nå resultatet, ikke om læreboken sier at noe må gjøres på en onsdag og ikke en torsdag.

Du har skrevet boken Sense and Respond om organisasjoner som lytter til kundene og skaper nye produkter. Finnes det andre teknikker du mener vellykkede organisasjoner tar i bruk, særlig i en verden preget av covid-19?

Jeff Gothelf:

Det organisasjoner endrer sist, og som er en av de mest kritiske delene av hele puslespillet, er insentivstrukturen og kriteriene for resultatstyring. Vi kan bruke alle oppskriftene, metodene og filosofiene vi vil, men hvis jeg får betalt for å levere en funksjon i stedet for å oppnå et resultat, kommer jeg til å levere funksjonen.

Hvordan måler vi de ansattes suksess? Hvordan endrer vi det vi måler, slik at vi oppmuntrer til nysgjerrighet, læring og forbedring? Hvordan skaper vi insentiver for dette? Hvis vi ikke gjør det, vil ikke agiliteten oppstå.

Det betyr å knytte insentivene til OKR-ene. OKR-ene blir målet på teamets suksess og en del av medarbeidersamtalen og insentivene. Hvis du når OKR-ene dine, er det dette du belønnes for.

Ben Aston:

Jeg har nylig sett at stillingskort i stedet for stillingsbeskrivelser kan være en nyttig måte å måle helt ned på individnivå. Det kan hjelpe folk med å forstå nøkkelmålene som faktisk skal skape endring.

Det kan være svært utfordrende å bestemme disse målene. Jeg har selv opplevd å lage en OKR eller måling og først etterpå innse at det var feil mål. Likevel er fokuset på resultater og leveranse av utfall gjennom et sterkt resultatfokus svært nyttig.

Jeg vil avslutte med å snakke om Scrum-kurset ditt. Scrum er et agilt rammeverk, og kurset ditt handler om UX og Scrum. Hvordan gjør man UX-design og forskning innenfor Scrum-rammeverket? Dette er noe mange i byråer synes er utfordrende, fordi Scrum virker forskrivende for utvikling.

Når vi legger til UX-forskning og design, blir ting mer kompliserte. Arbeider man alltid i den samme toukers-sprinten, eller ligger man én eller to sprinter foran? Hva sier du til dem som mener Scrum er et godt leveranserammeverk, men som ikke vet hvordan de skal legge inn den strategiske UX-design- og forskningsdelen?

Jeff Gothelf:

Det er utfordringen kurset Professional Scrum with UX, eller PSU, er laget for å løse. Vi ser pragmatisk og realistisk på hva Scrum er i dag, og hvordan det må justeres for å støtte praksiser som ikke ble vurdert da Scrum ble oppfunnet.

Vi ser på hva som skal inn i produktkøen, hvordan vi skriver brukerhistorier, hvem som gjør arbeidet, hva som skjer mens arbeidet utføres, hva annet som bør foregå, og hvor mye av sprinten som bør være læringsarbeid versus leveransearbeid.

Kort sagt handler det om tverrfunksjonelt samarbeid. Designeren må være et fullverdig medlem av teamet, og oppdagelsesarbeidet er like viktig som leveransearbeidet. Det finnes en vekselvirkning mellom oppdagelse og levering, og noen ganger utføres design- og forskningsarbeidet av personer som ikke er designere. Det må være akseptabelt for alle i teamet.

Ben Aston:

Det jeg vanligvis reagerer på ved Scrum, er hvor forskrivende det er. Vi har snakket om at dette bare er et rammeverk og et utgangspunkt som bør utvikles. Hvordan forholder du deg til et forskrivende rammeverk når du samtidig vet at det må tilpasses organisasjonen?

Jeff Gothelf:

Det fine med å gjøre dette sammen med scrum.org var at de var villige til å justere standpunktet sitt. Tidligere var problemet at organisasjoner sa: «Dette er Scrum, det kan ikke endres. Tilpass arbeidet ditt slik at det fungerer.»

Dette er en oppskrift. Hvis du ikke vet hvordan du skal løse dette akkurat nå, begynner du med oppskriften. Etter hvert justerer du den etter behovene, omstendighetene, organisasjonen og teamet ditt. Start med dette, bli bedre og utvid oppskriften etter behov. Det er et godt utgangspunkt som har fungert for oss.

Ben Aston:

Det er nyttig for alle som vurderer en mer agil tilnærming. Rammeverk som beskriver en prosess, er oppskrifter. Du trenger ikke følge dem til punkt og prikke. Du har frihet til å være fleksibel for å nå resultatene du ønsker. Du blir ikke vurdert etter hvor godt du følger rammeverket, men etter hvor godt du oppnår de ønskede resultatene.

Tusen takk for at du ble med oss i dag, Jeff.

Jeff Gothelf:

Bare hyggelig, Ben. Det har vært kjempegøy. Takk for at jeg fikk være med.

Ben Aston:

Hva mener du? Hvilke metoder, tips og triks har du for å levere godt? Hvordan skaper du suksess? Har du prøvd teknikken med pressemeldingen? Fortell oss om det i kommentarfeltet. Del historiene om det som mislyktes, og det som fungerte.

Hvis du vil lære mer og komme videre i arbeidet ditt, kan du bli med i stammen vår gjennom DPM-medlemskap. Gå til thedigitalprojectmanager.com/membership for tilgang til Slack-teamet vårt, maler, workshops, AMA-økter, kontortid, e-bøker og mer. Hvis du likte det du hørte i dag, kan du abonnere og holde kontakten på thedigitalprojectmanager.com. Takk for at du lyttet, og på gjensyn.