Arbejd baglæns for at komme fremad (med Jeff Gothelf fra Gothelf.co)

Læs transskriptionen:

Vi er i gang med at afprøve transskription af vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle slåfejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

For at være ærlig: Leverer dine projekter nogensinde virkelig det, du havde håbet, de ville? Det, de kunne eller burde? Hvorfor er det sådan? Er det måske, fordi du ikke planlagde? Måske fordi du ikke ledede dit team ordentligt. Eller måske fordi du havde svært ved at lede og samarbejde med dine interessenter. Måske er det lidt af det hele. Måske skyldes det, at I ikke alle var fuldt afstemt om projekternes endelige resultat og vision. Så lyt med til dagens podcast, hvis du vil lære, hvordan du kan arbejde baglæns for at komme mere selvsikkert fremad med gode projekter, reducere risikoen for fiasko og øge dine chancer for projektsucces.

Tak, fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager. Velkommen til DPM-podcasten. Vi har som mission at hjælpe projektledere med at få succes og hjælpe mennesker, der leder projekter, med at levere bedre. Vi er her for at hjælpe dig med at tage dine projektevner til næste niveau.

Besøg thedigitalprojectmanager.com for at lære mere om den træning og de ressourcer, vi tilbyder gennem medlemskab. Denne podcast er bragt til dig af Clarizen, den førende software til virksomheds- og porteføljestyring. Besøg Clarizen.com for at få mere at vide.

I dag har jeg selskab af Jeff Gothelf. Jeff underviser ledere og teams gennem fjernrådgivning og coaching, workshops, hovedtaler og bøger i at fokusere på kunderne, lære af fejl og skabe en agil kultur, der løbende forbedrer deres produkter, tjenester og arbejdsmetoder.

Han er medforfatter til en række bøger, som du har læst eller i det mindste sandsynligvis har hørt om, herunder Sense and Respond. Lean UX er den store af dem. Lean versus agil versus designtænkning. For nylig var han med til at grundlægge Sense and Respond Press, et forlag for moderne, forandrende erhvervsbøger. Så hej Jeff, mange tak fordi du er med i dag.

Jeff Gothelf:

Hej Ben, tak fordi du inviterede mig med i programmet.

Ben Aston:

Jeg vil faktisk gerne begynde med at tale om projekter. Jeg ved, at du i høj grad er produktorienteret, men for os projektledere, der leder projekter, kan de være en del af et større arbejdsprogram eller en produktkøreplan.

Jeg er nysgerrig efter at høre, hvordan du ser på det. Hvordan kan vi som projektledere hjælpe os selv og vores teams med at orientere os mod en mere iterativ tilgang? Jeg ved, at du netop har skrevet et indlæg om de 10 bedste svar på påstanden om, at agil er fantastisk, men ikke vil fungere her. Jeg vil derfor gerne tale om nogle af de udfordringer, som jeg mener, vi møder som digitale projektledere, og hvorfor.

Grundlæggende tror jeg, at de kunder, vi arbejder med, og alle interessenter godt kan lide idéen om at arbejde agilt. Vi kan diskutere, hvad agilitet betyder, men uanset om vi taler om en leverancemodel eller mere bredt om en tankegang, synes jeg, vi skal tale om denne tankegang omkring agilitet.

Jeg tror, at der er tre udfordringer, vi bør tale om. For det første kundernes mistillid. Dernæst for snævert definerede krav. Og for det tredje manglende budget og tid. Kunder vil gerne være agile, men har ikke altid budgettet til at gøre det.

Kunder med for snævert definerede krav og også kundernes mistillid. Kunderne stoler ikke rigtigt på bureauet eller teamet nok til helt at give slip og stole på processen. Det er altså tre udfordringer. Hvilken vil du gerne tale om først?

Jeff Gothelf:

Lad os tale om ændringen i tankegang først, for jeg tror, det er det afgørende, især for digitale projektledere at forstå. Hvis vi skal lykkes med at skabe gode teams, gode produkter, gode tjenester, succesfulde virksomheder samt succesfulde kunder og brugere, er det vigtigt at forstå den grundlæggende forskel i udviklingen af digitale produkter i dag.

Den grundlæggende forskel i dag sammenlignet med for 10 eller 15 år siden er, at software i dag er kontinuerlig. Vi går ikke længere i butikken og køber en kasse med software. Vi abonnerer på det eller installerer det, downloader det og installerer det, hvorefter det løbende opdateres.

Det bliver hele tiden bedre. Du går ikke i en butik og køber den næste version af Facebook. Du går ikke i butikken for at købe den næste version af Pinterest eller Amazon eller noget lignende. Det bliver løbende bedre, forbedres og ændres over tid. Det er den grundlæggende forskel mellem projekt- og produkttænkning. Projekter og produkter slutter ikke på samme måde.

I dag bygger vi virkelig disse systemer, disse kontinuerlige systemer, hvor vi ved hver cyklus har et valg. Du kan kalde det et sprint, en iteration eller hvad du vil. Men vi kan vælge, hvordan vi gør systemet bedre. Tilføjer vi noget? Optimerer vi det, der allerede findes? Fjerner vi noget?

Der er alle mulige ting, man kan gøre, men det er omtrent de tre kategorier. Det er det vigtigste at tage med, for disse ting slutter ikke. Tanken om, at jeg leder projektet frem mod en succesfuld lancering, er fin, men en lancering er blot begyndelsen på samtalen med din målgruppe. Den er ikke slutningen på produktet.

Ben Aston:

Helt sikkert. En af de ting, jeg synes, vi som digitale projektledere møder, når vi forsøger at tale med kunder om at arbejde mere agilt, er, at vi siger: Betal os for et dedikeret team i en periode, så samarbejder vi. Lad os sige, at vi har lanceret jeres website. Nu itererer vi på det.

Ligesom med software, der løbende opdateres, kan deres website måske gøre det samme. Men det kræver tillid, ikke? Den person, der betaler, skal have tillid til, at vedkommende får god værdi ud af processen. Hvordan mener du, at vi som projektledere, som mennesker der forsøger at guide kunder gennem denne proces, kan hjælpe dem med den mistillid, hvor de måske hellere vil sige: Jeg vil give jer 100.000 dollars, men jeg vil have en absolut bekræftelse på, at jeg får alt det, jeg ønsker, når processen er slut. Samtidig vil de have, at vi er agile.

De har denne kravliste, og vi siger, at vi ikke kan fortælle præcis, hvad de får, fordi vi arbejder på en måde, hvor vi identificerer det, der skaber mest værdi. Vi prioriterer disse ting. Vi arbejder os gennem dem sekventielt. Vi får ting sendt ud. Vi får ting gjort. Vi bygger. Vi tester. Vi lærer. Vi itererer. Men det kræver en vis grad af tillid. Hvad er dine bedste råd til at bygge bro over dette tillidsgab, når leverancerne er ukendte?

Jeff Gothelf:

Der er meget at pakke ud her, så lad os begynde med det grundlæggende. Det grundlæggende er: Hvilken forretning er du i? Det spørgsmål skal du virkelig stille dig selv, når du ser på det fra en kundes, leverandørs eller serviceudbyders perspektiv.

Er du i gang med at indgå partnerskab med dine kunder for at hjælpe dem med at opnå resultater, eller er du i gang med at levere et fast sæt krav? Som du siger, er der et grundlæggende misforhold mellem: Her er kravene, men vær venlig at være agil med dem.

Det giver ikke mening. Der er et spektrum, som jeg har lært af min ven og kollega Jeff Patton, og som hjælper med at tydeliggøre tankerne omkring spørgsmålet. I den ene ende af spektret har du ordet læge. I den anden ende har du ordet tjener.

Jeg vil udfordre jer som serviceorganisation til at overveje, hvor på dette spektrum I befinder jer. Hvis I befinder jer på tjenersiden, er jeres opgave at bringe mig præcis det, jeg bad om.

Ben Aston:

Ja.

Jeff Gothelf:

Uanset om du spiser det eller ej, eller om du kan lide det eller ej, er det ikke mit problem. Du bad om bøf med salat og en cola. Det var det, jeg kom med. Der er masser af organisationer, der gør det. Giv mig 100.000, så bygger jeg arken til dig i den anden ende som en læge.

Du fortæller ikke lægen: Hør, jeg vil gerne have denne medicin, denne vaccine og denne behandling. Lægen siger ikke bare: Okay, det får du. Lægen arbejder som konsulent for at hjælpe dig med at forbedre dig, i sidste ende forbedre dine KPI’er og dine målinger.

Spørgsmålet er derfor, hvor på spektret du befinder dig. Det er betydeligt lettere at være agil i lægeenden af spektret end i tjenerenden, fordi målene for succes grundlæggende er forskellige i de to ender. På tjenersiden er målet for succes output. Leverede du det, jeg bad om, til tiden og inden for budgettet? Ja, jeg kom med bøffen, salaten og colaen på 15 minutter, og prisen er den, du forventede. Det er et mål for succes. Der er ingen agilitet i det.

I den anden ende handler det om resultater og ændret adfærd hos dine kunder. Fik vi kunderne til at købe mere, bruge flere penge, bruge mere tid, fortælle deres venner om os eller købe mere end ét produkt fra os? Det er dér, agilitet virkelig skinner, når der er stor usikkerhed, og der ikke er et klart billede af, hvad der præcist vil skabe det forretningsresultat, vi søger.

Det er dér, det er langt mere værdifuldt og agilt at fungere som en læge. Og endnu vigtigere: Agilitet kan ikke komme i spil i samtalen, før du begynder at flytte det, du leverer, og måden du leverer det på, væk fra tjenersiden og over mod lægesiden.

Ben Aston:

Det handler altså om, at kunden eller interessenten skal gå fra at se sig selv som den, der har kontrollen, til at have tillid. Når du coacher organisationer, hvordan opfordrer du dem så til at se ud over det ukendte og få appetit på det? Der er typisk en forretningsmæssig drivkraft bag et projekt eller en produktiteration, og vi kan hurtigt vælge den lavthængende frugt, som bliver projektet eller næste iteration.

Hvordan hjælper du folk med at forstå værdien af en mere agil tankegang og få appetit på en mere konsulent- eller lægeorienteret tilgang frem for en tjener?

Jeff Gothelf:

Måden at gøre det på er at finde en respektfuld måde, der ikke begrænser engagementet, til at stille spørgsmålet hvorfor. Når du kommer til mig og siger: Jeg har brug for disse ti funktioner inden fredag, hvad koster det? skal du respektfuldt kunne spørge: Hvorfor ønsker du disse funktioner?

Det gør du ved at arbejde sammen med kunderne om at omdanne de faste krav til en problemformulering. Den problemformulering, som organisationen eller teamet forsøger at løse. Når teamet siger: Jeg har brug for mobilappen inden fredag, hvad koster det? siger du: Vent lidt, hvorfor har du brug for mobilappen?

Svaret kan være: Vi har brug for mobilappen, fordi vores mobile handelstal falder, og vi skal øge den mobile handel. Okay, så det problem, vi forsøger at løse, er at få flere til at købe gennem den mobile kanal. Hvor meget mere? En stigning på 15 procent ville være betydelig. Okay, fantastisk.

Se, hvad vi gjorde. Vi omformede Byg en mobilapp til Øg den mobile handel med 15 procent. Det, du grundlæggende har gjort, er at fjerne det specifikke krav fra samtalen. Det tvinger nu teamet til at være agilt i forhold til at teste, eksperimentere, lære, iterere og forbedre løsningen, indtil den øger den mobile handel med 15 procent.

Det er målet for succes, ikke at implementere appen. Der er en enorm risiko ved at antage, at dit funktionssæt vil skabe de resultater, du tror. Det meste af tiden tager du fejl, uanset hvor god du er.

Hvis du taler med nogle af de produktfolk, der har været i branchen længe, vil de fortælle dig, at en god produktchef har ret 30 procent af tiden. Det er en god produktchef.

Det gælder også interessenter, kunder og alle andre. Hvis du tager fejl 70 procent af tiden, vil du så ikke hellere bruge en proces, der giver dig mulighed for at finde den mest præcise måde at nå dine mål på så hurtigt som muligt, i stedet for blindt at sige: Send mig en app på torsdag, gør den blå, og lad den kunne disse fem ting?

Det er den grundlæggende forskel.

Ben Aston:

Ja. Jeg synes, det er meget klogt. At omformulere kundens ønske til problemformuleringer og gå ind i hvorfor-spørgsmålet er virkelig værdifuldt. Det ændrer samtalen fra en kravliste til noget, der giver os et område til at udforske problemet og identificere løsninger, vi kan bygge.

Derefter kan vi teste dem, lære og iterere. Det kan hjælpe os med de for snævert definerede krav, som var den anden udfordring. Jeg vil også gerne berøre den tredje udfordring. I dit indlæg om, at agilitet er fantastisk, men ikke vil fungere her, spørger du, om mangel på budget og tid kan være en årsag til, at agilitet ikke fungerer. Hvad mener du?

Jeff Gothelf:

Efter min mening er der en grundlæggende misforståelse af, hvad agile processer bidrager med. Det handler ikke om budget eller tid. Det handler om risikoreduktion. I stedet for at arbejde i tre måneder ud fra en persons idé om, hvordan succes ser ud, begynder vi at lære så hurtigt som muligt, om vi bevæger os i den rigtige retning.

Hvis vi ikke gør det, justerer vi kursen. Det er hele pointen. Hvis teamet justerer kursen ud fra evidens fra markedet, arbejder teamet agilt. Det har intet med budget eller tid at gøre.

Alternativet kan være, at det koster 75.000 dollars at bygge appen den næste måned. Fint. Er det et godt estimat eller et dårligt estimat? Det ved ingen. Du bygger det bedste, du kan, inden for tidsrammen, og så er budgettet væk. Hvad nu, hvis det ikke virker? Det er den risiko, du tager ved at bygge et digitalt produkt med en vandfaldstilgang, en forudsigende, topstyret og foreskrivende tilgang.

Du siger blot: Jeg ved, hvad det skal være. Jeg ved, hvordan det skal se ud. Jeg ved, hvad det skal gøre, og jeg skal bruge det på denne dato. Det er et ekstremt risikabelt synspunkt. Som jeg sagde, vil en god interessent, kunde eller produktchef forstå den del én ud af tre gange.

Ben Aston:

Men det afhænger også af, hvem der stiller kravet. Tilbage til eksemplet med bøffen, salaten og colaen på 15 minutter for 30 dollars. Jeg har 30 dollars, og jeg vil have bøf, cola og salat. Selv hvis det ikke er det bedste for mig, er det det, jeg ønsker. Jeg leder bare efter nogen, der kan give mig en bøf, salat og cola.

Jeff Gothelf:

Ja, og i den situation går du til en tjener. Hvis du går til lægen, måler lægen dine KPI’er: dit BMI, din vægt, dit blodtryk og dit kolesteroltal. Hvis du siger: Jeg vil have to bøffer og cola, siger lægen nej. Lægens opgave er ikke at give dig bøf, salat og cola. Lægens opgave er at gøre dig sundere.

Det er det resultat, lægen søger. En tjener er ikke optaget af dit helbred. En tjener giver dig det, du beder om, fordi det er tjenerens opgave, og fordi det er den forretning, tjeneren er i. Det er det, jeg tror, de fleste serviceudbydere ikke forstår ved agilitet: Det er ikke én proces versus en anden. Det er én forretningsmodel versus en anden. Det er meget vanskeligt for traditionelle serviceudbydere at forstå og derefter ændre sig efter.

Ben Aston:

Det kræver modenhed hos den, der får arbejdet udført, for at kunne rumme det, ikke?

Jeff Gothelf:

Præcis.

Ben Aston:

Det handler virkelig om den modenhed, der er nødvendig. For os, der arbejder i bureauer med kunder, som siger, at de bare vil have en bøf, salat og cola inden næste torsdag, er det en stor udfordring.

Jeg tror, udfordringen ligger i at omformulere ønsket, tage lægekasketten på og smide tjeneruniformen. Du har også skrevet et godt indlæg om kundecentrering og planlægning af kundecentrerede projekter med en opdateret version af teknikken med den fremtidige pressemeddelelse, som bygger på Amazons baglæns arbejdsproces og fokuserer stærkt på resultater.

Det handler om risikostyring og samarbejde. Jeg vil ikke afsløre historien fra indlægget, men man kan læse den på thedigitalprojectmanager.com. Jeg er nysgerrig efter at høre, hvordan denne tilgang hjælper. Der findes mange teknikker, som kan føles som en sjov aktivitet, men hvad sker der i praksis, når man skriver denne fremtidige pressemeddelelse?

Jeff Gothelf:

Først og fremmest begynder den med at forestille sig en fremtid, hvor man har haft succes, og tvinger en til at tænke over, hvad der gjorde en succesfuld til at begynde med. Variationen i artiklen placerer kunden i centrum, ikke blot: Vi sendte dette fantastiske nye system ud, alle elskede det, og vi tjente en masse penge.

Det handler mere om: Dette sendte vi ud, og dette er den adfærdsændring, vi har set. Dette er de resultater, vi har opnået. For at nå dertil måtte vi ikke kun definere succes ud fra kundeadfærd, men også tænke grundigt over, hvordan vi skulle skabe denne værdi for kunden på tværs af organisationen.

Hvilke samarbejdsudfordringer skulle vi håndtere? Og hvordan hjalp det i sidste ende virksomheden? Det vigtigste er, at det tvinger teamet til at gennemføre en slags forudgående dødsårsagsanalyse: Når vi endelig lancerer dette, og det får succes på markedet, hvordan ved vi så, at det lykkedes? Og hvad tror vi, at vi skulle have overvundet for at nå dertil?

Det er en samtale, der sjældent finder sted i begyndelsen af et initiativ. Typisk siger man: Jeg har brug for, at du bygger dette. Gå i gang. Succes er, at du leverer til tiden og inden for mit budget. I dette tilfælde siger vi, at succes er at opbygge en proces, der gør det muligt for os at påvirke kunderne positivt, så de får større succes. Det gør også virksomheden mere succesfuld.

Hvis du kan have den samtale ved initiativets begyndelse, tvinger den dig til at tænke over det arbejde, du udfører under initiativet. Du kan bruge den fremtidige pressemeddelelse som et filter og spørge: Er dette noget, der hjælper os med at nå målet? Hvis ikke, gør vi det ikke. Vi kan gøre noget andet. Det er meget kraftfuldt.

Ben Aston:

For dem, der ikke har læst indlægget, handler det om at forestille sig den fremtidige tilstand og se ind i krystalkuglen. På nogle måder ser vi på produkt-markedstilpasning, ønskværdighed, levedygtighed og gennemførlighed. Er der et stort marked af mennesker, der virkelig har brug for problemet løst? Vil forretningsmodellen fungere? Kan vi faktisk gøre det?

Det er en god risikolinse at bruge til at overveje, om produktet vil gøre disse ting. Vi bruger empati til at se fremad. Men jeg er nysgerrig: Vi bruger vores fantasi til at gøre dette. Er der en måde virkelig at validere det på? Hvor ofte har du skrevet fremtidige pressemeddelelser, og hvordan validerer du dem? Som produktchef har man jo kun ret 30 procent af tiden. Hvad med de øvrige 70 procent?

Jeff Gothelf:

Det giver os et mål. Det er et ideal, som teamet stræber efter. Du forsøger at forudsige fremtiden, så du vil tage fejl i dele af den. Men samlet forsøger du at forudsige, hvordan succes ser ud, hvilke forhindringer du havde, og hvordan du overvandt dem. Du forsøger at fortælle en overbevisende historie.

Du skal leve op til historien, mens du arbejder dig gennem initiativet. Nogle elementer vil uundgåeligt ikke blive virkelighed. Det er okay, så længe du klart og objektivt kan sige, hvorfor disse dele af historien ikke bliver til virkelighed, og hvordan historien ændrer sig. Men dette er vores mål og vores ideal for, hvordan teamet skal arbejde, og hvilken succes det skal opnå.

Vi filtrerer vores beslutninger gennem det, indtil vi får evidens fra markedet, der siger, at hver gang vi har truffet en beslutning ud fra disse kriterier, har resultatet været suboptimalt. Så ændrer vi det.

Ben Aston:

Vi flytter fokus. Vi lærer, at denne del af vores ideal ikke længere er gyldig eller værdifuld. Derfor justerer vi den og går videre. Den begynder som målet og idealet. Derfor flytter vi ikke målstolperne. Vi justerer målet ud fra den virkelighed, som vi ikke havde i begyndelsen af projektet.

Er der noget, der ikke fungerer godt med denne tilgang? På hvilke måder kan den hæmme teamet, kreativiteten eller perspektivet? Jeg ved, at du taler om, at dette er en videreudvikling af Amazons tilgang. Vil du forklare, hvorfor du har videreudviklet den, og hvilke udfordringer det kan give?

Jeff Gothelf:

Den største udfordring, jeg ser hos teams, er, at de ikke er kreative eller ambitiøse nok. De gør dokumentet meget sikkert. På amerikansk engelsk kaldes det sandbagging. Man sætter et mål, som man ved, man kan nå.

For mig er den største risiko, at man ikke forudser de store problemer og ikke sætter sine succeskriterier højt nok. Det er den største udfordring, jeg har set. Amazon har brugt teknikken med stor succes.

Min videreudvikling har to dele. For det første manglede den oprindelige skabelon fokus på resultater, altså målbare ændringer i kundeadfærd, der viser, at vi har leveret noget af værdi. Det er det, vi ønsker, at kunderne skal gøre, når vi sender det, vi bygger, ud.

Den oprindelige skabelon til pressemeddelelsen talte om forretningsfordele. Vi tjente penge, eller vi mistede ikke kunder. Men hvilken kundeadfærd ønsker vi faktisk at se? Hvis det lykkes, er det den adfærd, der fører til indtjening, fastholdelse og den slags.

Den anden mangel er især vigtig i større organisationer: Skabelonen manglede en diskussion af samarbejdsudfordringer. Intet bliver sendt på markedet af produktteamet alene. Det skal gennem jura, økonomi, marketing, drift og compliance. Hvordan samarbejder vi på tværs af organisationen, så vi fortsat kan levere den oplevelse, vi sigter efter, og involvere alle disse mennesker og afdelinger i processen?

Det er afgørende for en succesfuld lancering, især i organisationer med mere end måske 40 eller 50 medarbejdere. Derfor vil jeg have, at teams tænker over det. I er ikke en ø, og I kommer ikke til at sende dette ud alene. I skal begynde at involvere disse mennesker betydeligt tidligere end normalt, hvis I vil nå det ambitiøse mål.

Ben Aston:

Det er meget stærkt. Man tænker ikke kun på resultaterne, men også processen. Vi kan ofte identificere gode mål og succeskriterier og forestille os det resultat, vi ønsker. Men den proces, der skal gøre det til virkelighed, er ofte dér, hvor tingene går galt med hensyn til kommunikation og samarbejde.

Læs Jeffs indlæg om at arbejde baglæns for at komme fremad. Jeg er sikker på, at man kan tage mange nyttige pointer med sig. Jeg vil gerne skifte gear og gå lidt ind i den proces, som jeg ved, du brænder for. Du har arbejdet med rådgivning, startups og bureauer, og nu arbejder du for dig selv. Det har sikkert givet dig stor erfaring med både det, der fungerer, og det, der ikke fungerer.

Hvordan ser du processen og de metoder, vi bruger til at levere ting, udvikle sig? Vi har den agile procesudvikling, og selv om grundlaget er det samme, har vi ting som lean, agilitet, designtænkning og servicedesign. Vi ser forskellige teknikker få forskellige betegnelser.

Hvordan ser du, at processen udvikler sig, at agiliteten modnes, og at disse forskellige teknikker og rammer for idéudvikling og levering ændrer sig? Hvad ser du som fremtiden?

Jeff Gothelf:

Jeg tror, at agilitet på et tidspunkt bliver standarden i organisationer over hele verden. Den pandemi, vi gennemlever, vil fremskynde det. Organisationer, der allerede er agile, og som øger deres evne til at sanse og reagere, vil overleve dette.

Organisationer, der ikke kan gøre det, eller hvor det ikke ligger i deres DNA, vil uundgåeligt lide under det og måske blive slået ihjel af det. Agilitet skal være normen fremover, fordi forandringstempoet og markedernes og verdens omskiftelighed kun øges. Hvis du fungerer som en monolit, synker du som en monolit.

Hvis du derimod fungerer som en række delvist selvstændige teams, der sanser, reagerer, lærer, deler viden og justerer kursen ud fra evidens, vil din evne til at reagere, når større kriser rammer, gøre det muligt for dig at overleve.

Om vi om 20 år stadig taler om sprint, hastighed, nedbrændingsdiagrammer og produktbacklogs, ved jeg ikke. Sproget kan ændre sig, og procesnavnene kan ændre sig, men jeg kan ikke forestille mig en succesfuld økonomisk virkelighed, hvor kundecentrering, kontinuerlig læring og kontinuerlig forbedring ikke er de faktiske måder at lede en organisation på.

Det er de grundlæggende filosofier bag agilitet. Det er den retning, jeg ser fremtiden gå i, og jeg tror, den vil blive fremskyndet yderligere af den krise, vi gennemlever.

Ben Aston:

Når vi går tilbage til disse rammer og deres navne: Du brænder tydeligvis for Lean og har skrevet meget om det. Siden har der været meget specifikke teknikker inden for designtænkning og servicedesign, som kan være ret foreskrivende.

Forskellige mennesker repræsenterer forskellige leverancemodeller. Har vi brug for dem alle, og hvordan synes du, de fungerer sammen? Vi har forskellige projekttyper, så det er svært at lave en generel erklæring, men hvad er dit filosofiske syn på agil udvikling versus designtænkning?

Jeff Gothelf:

Jeg skrev en kort bog, der hedder Lean versus Agile versus Design Thinking. Hovedtesen er, at det er forskellige mærkenavne oven på meget ens filosofier. Navnene er forskellige, aktiviteterne kaldes noget andet, og rytmerne kan være lidt forskellige, men filosofisk er det det samme.

Hvis I kan forene det internt i organisationen, skal I på et tidspunkt vælge én tilgang, blande dem sammen eller skabe noget, der fungerer for jer som virksomhed. Men målet er ikke blindt at implementere en opskrift. Målet er at øge organisationens agilitet. Derfor er den opskrift, I vælger, i sidste ende ikke afgørende.

Målet er at lære at blive kok. Hvis du er nybegynder og aldrig har lavet mad før, henter du en kogebog, downloader en opskrift fra internettet og følger instruktionerne ord for ord. Det forventer jeg, at de fleste organisationer og teams begynder med. Giv mig Lean, Scrum, designtænkning eller XP. Lad mig udføre det.

Efter et stykke tid bliver du god til at følge opskriften. Du begynder at tilføje ting, der ikke stod i den oprindelige opskrift, men som gør retten bedre eller teamet mere succesfuldt.

Til sidst bliver du professionel kok. Professionelle kokke bruger ikke opskrifter. De ved grundlæggende, hvordan de skal fungere i alle slags køkkenmiljøer.

For mig er det det højeste modenhedsniveau for et team eller en organisation: at de intuitivt ved, hvordan de skal være agile i ethvert miljø ved hjælp af forskellige værktøjer og metoder. Opskriften er ikke det afgørende. De forstår målet og ved, hvordan de bruger værktøjerne til at nå det.

Organisationer, der binder sig til én bestemt opskrift, gør sig selv sårbare over for fiasko. De siger igen: Følg blot trinene blindt. Men succes er ikke implementeringen af opskriften. Den kan være det første skridt på en rejse. Rejsen handler om agilitet.

Ben Aston:

Det er derfor, folk bliver bekymrede, når nogen siger: Sådan gør man ikke. Hele idéen er, at selve processen kan itereres, og at det ikke handler om at følge processen slavisk. Når vi spørger, om vi skal gøre det præcis sådan, eller om vi må bøje reglerne lidt, bør vi fokusere på, hvad der bedst hjælper os med at nå det ønskede resultat.

Vi bør ikke slå op i lærebogen og sige: Her står, at det skal være onsdag og ikke torsdag. Blind procesfølgning kan være en stor udfordring.

Du har skrevet bogen Sense and Respond, som handler om organisationer, der lytter til kunderne og skaber nye produkter. Er der andre teknikker, vi ikke har talt om, som succesfulde organisationer tager til sig i denne tid, især under COVID-19? Hvad tror du bliver mest effektivt for organisationer fremover?

Jeff Gothelf:

Det, organisationer ofte ændrer sidst, selv om det er en af de mest kritiske dele af hele puslespillet, er incitamentsstrukturen og kriterierne for performanceledelse. Det er her, det bliver konkret.

Vi kan bruge alle opskrifter, metoder og filosofier, men hvis jeg bliver betalt for at sende en funktion ud i stedet for at opnå et resultat, sender jeg funktionen ud. Om det er agilt, lean, designtænkning eller vandfald, er ligegyldigt, fordi du betaler mig for at levere funktionen.

Hvordan måler vi vores medarbejderes succes? Hvordan ændrer vi det, vi måler, så vi fremmer den adfærd, vi gerne vil se: nysgerrighed, læring og forbedring, som i sidste ende skaber succesfulde produkter og tjenester? Hvordan belønner vi det? Hvis vi ikke belønner det i dag, sker det ikke.

Hvis det ikke sker, forsvinder al agilitet. Organisationer, der forstår det, ændrer deres systemer. Det er hårdt arbejde og risikabelt, men det er risikoen værd, fordi man får bedre produkter og tjenester, gladere kunder og mere succesfulde medarbejdere.

Ben Aston:

Taler du specifikt om OKR’er, eller taler du mere bredt?

Jeff Gothelf:

Jeg taler om at knytte incitamenterne til OKR’erne. OKR’erne bliver målet for teamets succes og en del af deres performancevurdering og incitamenter. Rammer I jeres OKR’er? Hvis I gør, er det sådan, vi belønner jer.

Ben Aston:

Jeg så for nylig noget, jeg synes var meget nyttigt: at bruge job-scorekort i stedet for jobbeskrivelser. Det kan være en god måde at måle helt ned på individniveau og give incitament til at forstå de vigtigste målepunkter, der faktisk skaber forandringen.

Hvis målepunkterne er korrekte, hjælper de naturligvis folk med at forstå den forandring, man forsøger at engagere dem i. Det kan være meget udfordrende at beslutte, hvilke målepunkter der er rigtige. Nogle gange opretter jeg et OKR eller et målepunkt og opdager først bagefter, at det var det forkerte målepunkt.

Det kan skabe arbejde og energi omkring noget, som man bagefter opdager ikke var det rigtige. Men fokus på resultater og levering af resultater gennem denne stærke fokusering er meget nyttigt.

Jeg vil afslutte med at tale om dit Scrum-kursus. Scrum er naturligvis en agil ramme. Kurset handler om UX og Scrum og om, hvordan man laver UX fra research inden for Scrum-rammen.

Det er noget, bureaufolk ofte udfordres af, fordi Scrum kan virke meget foreskrivende for udvikling, hvor det fungerer godt. Når vi tilføjer UX-research og design, bliver tingene mere komplicerede. Arbejder vi altid i det samme tougers sprint, eller er vi et sprint eller to foran? Hvad siger du til mennesker, der oplever denne udfordring?

Hvordan ser du disse ting fungere sammen på højt niveau? Jeg tror, det er en af de største udfordringer for bureauer, der forsøger at implementere Scrum.

Jeff Gothelf:

Det er netop den udfordring, kurset Professional Scrum with UX, eller PSU, er designet til at løse. Vi ser pragmatisk og realistisk på, hvad Scrum er i dag, og hvordan Scrum skal justeres for at understøtte praksisser, som ikke blev tænkt ind, da Scrum blev opfundet, men som nu er nødvendige for at bygge gode produkter.

Vi fokuserer på, hvad der kommer i backloggen, hvordan vi skriver historier, hvem der udfører arbejdet, hvad der sker, når arbejdet udføres, og hvad der ellers bør foregå. Hvor meget af vores sprint skal være læringsarbejde versus leverancearbejde? Alle disse spørgsmål behandles i kurset.

Kort fortalt handler det om tværfunktionelt samarbejde. Designeren skal være fuldtidsmedlem af teamet, og discovery-arbejdet er lige så vigtigt som leverancearbejdet. Der er et flow mellem discovery og levering, og nogle gange udføres discovery-, design- eller researcharbejdet af personer, der ikke er designere. Det skal også være acceptabelt for alle i teamet.

Ben Aston:

En af mine typiske indvendinger mod Scrum er, at det er så foreskrivende. Vi har talt om, at det blot er en ramme og et udgangspunkt, som bør udvikle sig. Men Scrum-tilgangen er meget foreskrivende. Hvordan har du det med at arbejde inden for en foreskrivende ramme, når du samtidig ved, at den skal tilpasses organisationen?

Hvordan designede du en proces, der håndterede denne spænding?

Jeff Gothelf:

Det gode ved at gøre dette sammen med scrum.org var, at de var villige til at justere deres position. Tidligere var det en stopklods, når organisationer sagde: Det her er Scrum. Det kan ikke ændres. Uanset hvad du gør, må du ændre det, så det fungerer.

Det gode var, at de også var villige til at ændre deres egen tilgang. Det var allerede en sejr og et skridt i den rigtige retning.

For det andet er dette en opskrift. Hvis du ikke ved, hvordan du skal løse det lige nu, kan du begynde med denne opskrift. Til sidst justerer du den, så den passer til dine behov, omstændigheder, organisation og team. Men begynd her, bliv bedre, og tilpas opskriften efter behov. Det er et godt udgangspunkt, som har fungeret for os.

Ben Aston:

Det er meget nyttigt. For alle, der overvejer en mere agil tilgang, er det vigtigt at forstå, at disse rammer er opskrifter. Det betyder ikke, at man skal følge dem slavisk, og der er plads til fleksibilitet for at opnå de resultater, man ønsker.

Man bliver ikke vurderet på, hvor godt man følger rammen, men på, hvor godt man opnår de ønskede resultater. Det har været temaet for dagens samtale. Mange tak, Jeff, fordi du var med.

Jeff Gothelf:

Det var en fornøjelse, Ben. Det har været fantastisk. Tak fordi du inviterede mig.

Ben Aston:

Jeg er nysgerrig efter at høre, hvad du mener. Hvilke hacks, tips og tricks bruger du til at levere godt? Hvordan skaber du succes? Har du prøvet teknikken med pressemeddelelsen? Fortæl os det i kommentarerne. Del dine fiaskoer og dine sejre med os.

Hvis du vil lære mere og komme foran i dit arbejde, kan du slutte dig til vores fællesskab med DPM-medlemskab. Gå til thedigitalprojectmanager.com/membership for at få adgang til vores Slack-team, skabeloner, workshops, AMA-sessioner, kontortider, e-bøger og meget mere. Hvis du kunne lide det, du hørte i dag, så abonnér, og hold kontakten på thedigitalprojectmanager.com. Indtil næste gang: Tak fordi du lyttede.