Hvordan kan du få Scrum til at fungere i et bureau, og hvordan gennemfører du effektivt enhver procesændring? I denne podcast taler Ben Aston med Alexa Huston om hendes introduktion af Scrum hos bureauet Crema, og om hvordan du kan få procesændringer til at fungere for alle sammen med dit team og dine værktøjer.
Læs transskriptionen:
Vi afprøver at transskribere vores podcasts ved hjælp af et softwareprogram. Tilgiv venligst eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.
Ben Aston:
Tak fordi du lytter med. Jeg hedder Ben Aston, og dette er podcasten The Digital Project Manager. I dag har jeg besøg af Alexa Huston. Alexa, mange tak fordi du ville være med i programmet i dag.
Alexa Huston:
Tak fordi jeg måtte komme.
Ben Aston:
I dag taler vi om at gennemføre procesændringer, og om hvordan vi kan forbedre processer og gøre det hele lidt mere enkelt. Men først, Alexa, vil vi gerne høre lidt om dig. Ud fra din biografi kan jeg se, at du arbejder hos et bureau, der hedder Crema. Er det sådan, man udtaler det?
Alexa Huston:
Det udtales Crema. Det kommer fra det gyldne lag, der stiger til tops i en espresso, så hvis du kender til kaffe eller tidligere har arbejdet som barista, lyder det måske bekendt. Men mange siger Crema. Det er faktisk Crema, og begge dele er okay.
Ben Aston:
Tak, fordi du rettede mig. Da jeg læste din biografi, blev jeg faktisk ret interesseret. Det virker, som om du, når du ikke er på kontoret, bliver stærkere, laver noget lækkert i køkkenet eller rejser. Vi talte faktisk om nogle af dine rejser tidligere, men det her med at blive stærkere – hvordan går det?
Alexa Huston:
Det er stadig under udvikling, men ja. Jeg begyndte i et fantastisk fitnesscenter i slutningen af sidste år, og det er sjovt. Jeg laver ting, jeg aldrig havde troet, jeg skulle lave, som olympiske løft, MetCon-træning og den slags. Det har bare fyldt lidt mere i mit liv det seneste år end tidligere. Det har været virkelig sjovt.
Ben Aston:
Det lyder meget seriøst. Deltager du i nogle konkurrencer?
Alexa Huston:
Det tror jeg aldrig, jeg kommer til.
Ben Aston:
Eller kæmper du mod folk?
Alexa Huston:
Nej. Nej, det handler bare om at blive stærkere og sundere og om at lave noget sammen med min kæreste, så jeg kan blive lidt bedre hver dag.
Ben Aston:
Fedt. Fortæl mig lidt om dig selv. Hvordan endte du med at blive digital projektleder? Jeg tog et hurtigt kig på din LinkedIn-profil, og jeg kan se, at din karriere – eller i hvert fald en del af den – begyndte som underviser i skrivefærdigheder og tidsstyring. Det lyder som den perfekte træning til at blive projektleder.
Alexa Huston:
Ja, det kan man godt argumentere for. Det var faktisk også lidt af et tilfælde. Jeg gik på et fantastisk universitet, som havde et læringscenter, og jeg havde et studiejob dér. De spurgte, om jeg ville undervise i tidsstyring og skrivning, så det gjorde jeg gennem hele studiet. Efter nogle omveje efter dimissionen blev jeg faktisk traditionel projektleder hos et reklamebureau og lærte det grundlæggende i projektledelse fra en traditionel marketingbaggrund.
Jeg var der i et par år, før jeg tog en lille pause for at rejse og bo på Hawaii i en måned. Da jeg fortalte, at jeg skulle rejse, kontaktede en tidligere kollega mig og spurgte: “Hvad er din plan, når du kommer tilbage?” Jeg sagde: “Jeg har ikke rigtig nogen endnu, men har du noget i tankerne?” Han er strateg for forretningsudvikling hos Crema og sagde: “Vi leder efter endnu en projektleder. Vi udvikler webapps og mobilapps.” Jeg tænkte: “Hvor anderledes kan det være?” Det viste sig at være meget anderledes. Det har jeg lært, men jeg faldt lidt tilfældigt ind i det. Det har dog været to fantastiske år, hvor jeg har lært, hvordan livet som digital projektleder fungerer.
Ben Aston:
Fedt. Før du gjorde det – jeg har en lignende historie, hvor jeg begyndte hos traditionelle reklamebureauer og derefter skiftede til det digitale. Hvordan var det skifte for dig? Var du teknisk anlagt i forvejen, eller hvordan fungerede det?
Alexa Huston:
Det er et godt spørgsmål. Ikke nødvendigvis. Jeg havde været involveret i et par digitale projekter hos reklamebureauet, men når jeg ser tilbage, var det knap nok det. Jeg hjalp med at styre noget indholdsproduktion på en hjemmeside, så jeg troede, jeg kendte lidt til området. Jeg er vokset op med teknologi, men jeg vil ikke kalde mig teknolog. Derfor var indlæringskurven ret stejl, da jeg begyndte, og jeg overtog næsten med det samme mit første projekt, hvor vi skulle genopbygge et FinTech-produkt. Der var en hel masse ting, jeg ikke engang havde overvejet. Heldigvis havde jeg et fantastisk team, som hjalp mig igennem det, men jeg kom virkelig ind uden megen erfaring. Ikke fra et projektlederperspektiv, men mere fra et digitalt projektlederperspektiv. Der er meget at lære, som vi alle sikkert ved.
Ben Aston:
Ja, helt sikkert. Fortæl mig lidt om Crema. Arbejder I primært med web- og mobilapps?
Alexa Huston:
Det er rigtigt. Vi specialiserer os primært i JavaScript-baseret web- og mobiludvikling. Vi arbejder meget med React og React Native. Men vi arbejder også en del med forretningsstrategi, prototyper, brugertest og validering af idéer og betjener primært to forskellige kundetyper. Den ene type kan være en iværksætter, der har prøvet kræfter med området nogle gange og har penge til at eksperimentere med en ny idé. Vi hjælper med at validere og teste produktet, som vi forhåbentlig derefter kan udvikle. Det er virkelig sjovt.
Ben Aston:
Ja.
Alexa Huston:
Vi arbejder også med mere etablerede virksomheder, som måske har et innovationsteam eller en produktchef, der har fået til opgave at skabe innovation. De kommer til os og siger: “Jeg har dette budget, og jeg skal gøre nogle ting bedre. Det er det, jeg overvejer. Kan vi designe det og teste det?” Andre gange siger de: “Vi skal genopbygge det her nu,” og så svarer vi: “Det lyder godt, men lad os først undersøge det nærmere og forstå den bedste måde at gøre det på.”
Ben Aston:
Det lyder sjovt. Arbejder I med ting som designsprints for den slags iværksættere, der har mange penge og gerne vil teste en idé? Hvordan validerer I?
Alexa Huston:
Ja, vi laver designsprints. Vi henter meget inspiration fra Googles proces for designsprints, men vi har tilpasset den til vores behov. Ofte foreslår vi et forløb på fire til seks uger, hvor vi mødes med kunden og gennemfører en kickoff-session på halvanden til to dage med en lean-model, storytelling-øvelser og forskellige andre metoder. Det hjælper med at udfolde idéen og sikre, at der for det første er et problem, som folk ønsker løst, og for det andet at dette er den rigtige løsning på problemet.
Vi ved naturligvis ikke alt efter de to dage, men ofte kommer der rigtig meget frem. Derefter siger vi: “Okay, ud fra det, vi ved, lad os eksperimentere med disse forskellige scenarier,” og vores designere og strateger går i gang med at skabe detaljerede skitser. Faktisk bruger vi ikke rigtigt det begreb, men går direkte til design. Der findes mange gode værktøjer, som hjælper designerne med at komme i gang, og vi er heldige at have et fantastisk team.
De begynder at skabe visninger og interaktive prototyper, som vi kan sende ud og teste. Nogle gange tester vi med tilfældige personer, vi finder på Craigslist, andre gange med personer, kunden rekrutterer, eller med interne interessenter fra forskellige kundeteams, som vi ved, vi har brug for input fra. Det er en slags sprintplan, hvor vi designer i fem dage, tester i to dage og derefter gentager processen, indtil vi kan færdiggøre tilgangen. Hvis vi især planlægger at gå videre til udvikling bagefter, sørger vi helst for at have udviklerne med i processen, så de kan rådgive undervejs og træffe informerede beslutninger. På den måde har vi ved slutningen en god eller i det mindste bedre forståelse af, hvad der skal til for at bygge løsningen.
Ben Aston:
Fedt. Det lyder sjovt. Jeg har gennemført nogle af Googles designsprints, så jeg synes, det er interessant, at jeres proces er anderledes. I et typisk Google-designsprint skal kunden være fuldt engageret i en hel uge og være fysisk til stede på fuld tid. Kunden udvikler koncepter sammen med jer og arbejder på de første prototyper. Problemet er, at de fleste kunder ikke har råd til at have deres vigtigste medarbejdere væk fra kontoret en hel uge for at deltage i et sprint. Det er simpelthen ikke realistisk.
Alexa Huston:
Det er rigtigt.
Ben Aston:
Vi oplevede derfor, at kunderne gerne ville lave et designsprint, men at det tog tre eller fire måneder at planlægge. Det fungerede ikke rigtigt. Det lyder, som om I reducerer den indledende afklaringsfase og derefter går direkte til design og konceptudvikling, i stedet for at holde kunden engageret gennem hele det første sprint. I får dem involveret i begyndelsen, og det lyder som en god løsning.
Alexa Huston:
Ja, og det er helt rigtigt. Folk har travlt, og de betaler også mange penge for at teste idéen. Derfor begrænser vi involveringen til en eller to dage og går derefter i gang. Men vi inviterer også kunderne ind i vores produktstyringssystem. Selvom de ikke fysisk er i rummet, opdaterer vi dem næsten konstant asynkront via Asana, ZenHub eller andre værktøjer, som vi bruger internt. De er stadig meget involverede i processen, men de behøver ikke fysisk at sidde i et rum i en hel uge. Det ville være fantastisk, hvis vi kunne gøre det, men det er bare ikke realistisk.
Ben Aston:
Ja, og det er fantastisk, når kunderne faktisk gør det. For en af vores kunder lavede vi et designsprint, og det gode var, at fordi kunden var engageret hele ugen, fandt vi frem til et koncept, der var så anderledes, at det faktisk var til … ja, det kan jeg godt fortælle om. Det var for BCLC, British Columbias lotteriselskab. De ønskede en sjovere måde at hjælpe folk med at vælge deres lottotal på, fordi nogle mennesker tænker på at spille og derefter står ved kiosken og siger: “Jeg ved ikke, hvilke tal jeg skal vælge.”
Vi ville gøre det sjovere at vælge tallene, så konceptet blev en hvalpevælger. Man valgte sine tal ud fra billeder af hunde. Hver hund havde et forskelligt tal, som man ikke kendte, men man valgte bare de hunde, man bedst kunne lide, og så blev tallene valgt for en. Det var den mest vanvittige og egentlig ret dumme idé, men fordi kunden var engageret gennem hele processen, gik de med på noget, man ellers ville have troet, at en kunde aldrig ville acceptere. Nu er det live, og man kan bruge hvalpevælgeren til at vælge sine lottotal.
Alexa Huston:
Det er fantastisk.
Ben Aston:
Det er ret vildt, ikke? Når man involverer kunderne, kan der ske fantastiske ting, og nogle idéer, som vi måske normalt ville afvise, bliver faktisk ført ud i livet. Det er ret fedt.
Alexa Huston:
Ja, det lyder fantastisk.
Ben Aston:
Arbejder du på nogle spændende projekter i øjeblikket, som du kan fortælle om?
Alexa Huston:
Jeg arbejder på rigtig mange projekter lige nu. Uden at gå i detaljer kan jeg i det mindste nævne de forskellige brancher: netværkssikkerhed, onlinechat, dermatologi og jobformidling efter behov samt en masse interne ting.
Ben Aston:
Hvad er jobformidling efter behov?
Alexa Huston:
Det er måske ikke det rigtige ordvalg, men produktet hjælper gymnasieelever med at komme i kontakt med arbejdsgivere, der må ansætte personer på deres alder. Jeg har lært, at mange gymnasieelever typisk kører rundt for at finde et sommerjob eller et job, når de har tid. De besøger virksomheder, de gerne vil arbejde for, og henter en ansøgning. Først efter at de har afleveret ansøgningen, finder de ud af, om de overhovedet må arbejde for virksomheden på grund af aldersregler. Appen hjælper med at undersøge arbejdsgiverne i en markedsplads med to sider, så man kun matches med job, man er kvalificeret til på baggrund af sin alder.
Ben Aston:
Hvilke slags job kan man ikke få? For eksempel arbejde på en bar?
Alexa Huston:
Det er et eksempel. Men på nogle restauranter skal man også være fyldt 16 år. Andre arbejdsgivere ansætter unge på 14 eller 15 år. Appen matcher dem derfor ud fra de brancher, de er interesserede i, og andre kriterier, så de ikke støder ind i aldersproblemet undervejs. Det kan være ret nedslående.
Ben Aston:
Lad os tale om den artikel, du skrev. Hvis du ikke allerede har læst den, bør du gøre det. Den handler om at lede procesændringer og gøre procesforbedringer lettere. Hvis du tænker: “Vent, min proces fungerer ikke,” eller: “Lad os prøve Scrum i vores bureau,” så læs artiklen først. Den er bestemt værd at læse.
Men først skal vi tale lidt om proces. Proces er et af de emner, man altid hører projektledere tale om, og projektledere elsker også at tale om procesændringer. Når vi taler om proces, taler vi om den måde, vi gør tingene på. Det er den eksisterende måde at arbejde på. Det er sådan, vi ved, om folk følger reglerne, og om tingene sker korrekt. Projektledere taler hele tiden om det, fordi vi forsøger at finde den bedste måde at gøre tingene på. Vi forsøger at gøre det så effektivt som muligt og strømline det. Derfor taler projektledere altid om det: Vi forsøger at gøre vores måde at arbejde på bedre.
Procesforbedring bør derfor ske hele tiden. Vi bør forsøge at ændre den måde, vi arbejder på, forbedre den og gøre den bedre. Men måden, vi gør det på, er vigtig, og det er det, Alexa har skrevet en artikel om. Du taler om at være empatisk, strategisk, realistisk, engageret og tålmodig. Lad os sætte det ind i den sammenhæng, du beskriver i artiklen: at ændre eller forsøge at flytte dit bureau over til Scrum.
Alexa Huston:
Det er rigtigt.
Ben Aston:
Jeg vil gerne vide, hvordan du nåede frem til, at det var en god idé, og hvordan det gik. Fortæl mig om det.
Alexa Huston:
Vi er et ret lille bureau med færre end 25 medarbejdere. En vigtig ting er, at vi virkelig værdsætter løbende forbedringer. Det er en fælles værdi i virksomheden at eksperimentere, blive bedre og forsøge at forbedre alles arbejdsgange. Det passer også godt til den, jeg er som person, og det er rart at vide, at det er en værdi, virksomheden deler.
For omkring to år siden, da jeg begyndte, var bureauet struktureret mere som en vandfaldsorganisation. De kunder og projekter, vi arbejdede med, passede bare ind i den model. Der er ikke noget galt med det. Selv de designsprints og prototypeforløb, jeg nævnte tidligere, har i høj grad en vandfaldskarakter.
Når man begynder på udvikling, bliver tingene dog langt mindre forudsigelige og meget mere variable, især når forløbene bliver længere. Derfor begyndte vi langsomt at bevæge os væk fra projekter med et omfattende fast scope og en vandfaldsbaseret tilgang og over mod aftaler baseret på varighed og pris. Det betyder, at kunden ideelt set betaler for vores team i en bestemt periode, og at prisen afhænger af varigheden. Inden for den periode hjælper den agile tilgang os med at reagere på kundens behov. Vi ved måske præcis, hvor vi vil begynde, og har en god idé om, hvor vi ender, men undervejs gør agile metoder det muligt at ændre det, der sker.
For at gøre en lang historie kort har vi arbejdet med aftaler baseret på varighed og pris og er blevet mere agile. Jeg har et fantastisk projektlederteam. Vi er kun tre, men vi er alle meget engagerede i denne model. For omkring seks måneder siden sagde vi til hinanden: “Vi bør nok blive Scrum-certificerede.” Det var en del af vores faglige udvikling, så vi kunne blive mere fortrolige med de konkrete detaljer i processen. Vi havde allerede lånt nogle af de ting, Scrum lærer os, men vi ville gerne være bedre uddannet, så vi kunne forklare processerne bedre for teamet og skabe en fælles forståelse uden for projektlederteamet og i hele organisationen.
Ben Aston:
Har du så rollen som Scrum Master? Er det projektlederens rolle, eller har I en udvikler, der gør det?
Alexa Huston:
Det er et godt spørgsmål. Vi har rollen som Scrum Master.
Ben Aston:
Det er interessant, for Scrum fungerer ikke for de fleste bureauer, fordi samarbejdsmodellen er forkert. Der er et fast scope, og den model, du taler om, hvor kunden betaler for varighed, fungerer tydeligvis godt. Den passer godt sammen med Scrum.
Alexa Huston:
Det gør den, selvom den kan være svær at sælge. Kunderne bryder sig ikke altid om at se et stort beløb, der ikke er knyttet til specifikke leverancer.
Ben Aston:
Hvordan fungerer det?
Alexa Huston:
Kunderne bryder sig ikke altid om et stort beløb uden specifikke leverancer, uanset hvordan vi formulerer det. Hvis jeg selv satte mig i deres sted, ville jeg også tænke: “Er det virkelig rigtigt?” Under salgsprocessen og i vores samarbejde med dem forsøger vi at forklare fordelene og bruger cases og andre eksempler til at understøtte pointen. Der har naturligvis også været tilfælde, hvor det ikke fungerede for kunden, og så tilpasser vi os. Men det er den foretrukne tilgang: “Lad os arbejde ud fra varighed og pris, være agile og springe ud i det.”
Ben Aston:
Hvor ofte har kunder sagt: “Det her fungerer ikke. Vi er to måneder inde, og vi har ikke fået noget brugbart endnu”?
Alexa Huston:
Det er svært. Det var faktisk her, vi ville understrege betydningen af Scrum-processen, fordi den lærer dig at have noget, der kan leveres, ved slutningen af hvert sprint.
Ben Aston:
Ja.
Alexa Huston:
Det leverbare resultat kan få kunden til at føle sig bedre tilpas med fremskridtene, fordi vi bevæger os mod et mål, som er synligt og mere eller mindre fysisk, og som kunden kan interagere med på sin enhed. Skiftet til Scrum har måske tidligere hjulpet med at mindske spændingerne med en kunde. Før kunne kunden have sagt: “Der er gået to eller tre uger – hvor er der noget?” Scrum har ikke været perfekt, men det gør det lettere for os at sætte mere realistiske sprintmål og sige: “Ved slutningen af dette sprint har vi X.” Kunden kan se og interagere med X, føle sig tryg ved, hvor vi er, og give feedback.
Ben Aston:
Det giver mening. En af de ting, du taler om, er at være empatisk. Hvordan kom det til udtryk i dette eksempel? I ændrede måden, I samarbejdede med kunderne på, og måden, I arbejdede som team på. Hvordan brugte du princippet om empati over for teamet, da I indførte det? Folk kan generelt ikke lide forandringer. Udviklere vil altid gerne bruge Scrum, men bortset fra det – hvordan fik du folk med på idéen, når I havde besluttet jer for Scrum? I forsøgte at få input fra folk, men havde allerede en plan. Planen var Scrum.
Alexa Huston:
Det er det interessante punkt. Vi var lidt udspekulerede bag kulisserne. I virkeligheden ville vi gøre det, og hele teamet vidste, at det ville ske. Vi forsvandt ikke mystisk i to dage og vendte tilbage med en beslutning. Vi arrangerede i stedet et frokostmøde med læring, hvor vi gennemgik Scrums principper, hvordan Scrum fungerer, og hvorfor vi ville bruge Scrum.
Det gav mere kontekst. Mange i teamet havde erfaring med Scrum fra tidligere job, men her så de det gennem Cremas perspektiv og den måde, vi ville implementere det på. Ved afslutningen delte vi os i tre grupper, som hver blev ledet af en af os, og spurgte: “Hvilke spørgsmål har I? Hvad er I bekymrede for? Hvad synes I fungerer godt?”
Vi samlede al feedbacken i en ny proces i Asana, hvor vi indsamler forslag til procesforbedringer fra teamet og idéer, der er opstået under overgangen til Scrum. I løbet af de næste par måneder vil vi gennemgå det, finde ud af, hvem der ejer de enkelte initiativer, og beslutte, hvordan vi vil forbedre processen. Kernen i det – og svaret på dit spørgsmål – var: “Lad os blive certificerede, lære mere om det, gøre det ordentligt og derefter vende tilbage til teamet, som udfører arbejdet, for at sikre, at vi besvarer alle deres spørgsmål.” Vi satte os i deres sted for at sikre, at der ikke var usikkerhed omkring det, der skete. Og hvis der var, arbejdede vi på at håndtere den.
Ben Aston:
Det er vigtigt. Når man ændrer en proces, skal man få folk til at bakke op om den på forhånd i stedet for bare at komme med en stor meddelelse: “Fra næste uge arbejder vi med Scrum. Held og lykke, alle sammen – jeg tager på ferie.”
Alexa Huston:
Det kan virke voldsomt og forvirrende, så vi ville begrænse det så meget som muligt. Der var også projekter i den periode – det var tidligere på sommeren – hvor vi ikke forsøgte at indføre store ændringer, fordi vi tog hensyn til, hvor langt vi var i projekterne. Vi sagde: “Lad os bevare den eksisterende måde på dette projekt, men på det andet projekt sørger vi for, at tingene følger den nye tilgang.”
Det var ikke meningen, at alt skulle ændres fra den ene dag til den anden. Vi ville blive certificerede og gennemføre en gradvis ændring, når omstændighederne var til det.
Ben Aston:
Det er også en af pointerne i din artikel: at være strategisk. Der er et rigtigt tidspunkt og sted til at ændre ting, og det handler ikke nødvendigvis om at sige: “Fra i morgen ændrer alt sig – held og lykke.” Det er også vigtigt at have en proces for selve procesændringen. Der skal ikke bare være en plan for at skifte til Scrum, men også en plan for, hvordan man vurderer, om et projekt egner sig til den nye proces. Når man implementerer en ny proces, er det altid en udfordring at beslutte, hvad man gør med de eksisterende projekter. Hvis man siger, at alle eksisterende projekter fortsætter som hidtil, og at den nye proces kun gælder nye projekter, kan man ende med aldrig at bruge den nye proces, fordi man tænker: “Lad os bare gøre det på den gamle måde. Den kender vi.” Der skal helt sikkert findes en balance.
Alexa Huston:
Det er en rigtig god pointe. Det er ikke altid let at vide med det samme. Man må stole på sin mavefornemmelse og tale med teamet: “Føles det rigtigt? Er tidspunktet rigtigt? Giver strategien mening? Vil det forstyrre jer for meget?”
I artiklen nævner jeg, at vi besluttede at skifte ret hurtigt til ZenHub, som er et projektstyringslag til GitHub. Det har været fantastisk, fordi det er så tæt knyttet til koden, og det er et virkelig elegant værktøj. Men vi traf beslutningen få dage før, vi skulle begynde udviklingen på et projekt, vi havde prototypet og testet. Vi samledes og talte om det, og jeg sagde: “Hvad synes I? Skal vi gøre det? Jeg ved, at det bliver nyt og lidt mærkeligt, og helt ærligt føler jeg mig ikke helt sikker på alle funktionerne endnu, men hvis vi ikke gør det nu, går vi glip af muligheden i de næste ti uger.”
På baggrund af det og nogle andre grunde, som udviklerne fremførte, sagde vi: “Det kan gøre ondt i begyndelsen, men lad os springe ud i det.” Jeg fortalte kunden, at vi ville gøre det, fordi vi igen forsøger at involvere kunden så meget som muligt. Kunden sagde: “Det lyder godt. Sig til, hvordan jeg kan hjælpe.” Vi bruger det stadig i dag. Det var en af de situationer, hvor vi sagde: “Okay, lad os gøre det. Det føles rigtigt, og hvis det ikke fungerer, hvad er så planen?” Vi havde planen klar og var parate til at gå i gang.
Ben Aston:
Det er lidt som at rive et plaster af, ikke?
Alexa Huston:
Jo.
Ben Aston:
Man skal rive det af, og nogle gange er det bedst at gøre det hurtigt. Men man skal blive ved med at huske, hvorfor man gør det. Det bliver smertefuldt, og ting vil gå galt, men man skal blive ved med at minde folk om det: “Husk, hvorfor vi gør det her. Det er, så vi ikke skal indtaste alle data og opgaver tre gange i vores timesedler,” eller hvad årsagen nu måtte være.
Alexa Huston:
Helt sikkert. Jeg var næsten mere bange end alle andre, fordi jeg var så vant til den måde, vi havde kørt projekter på i Asana. Asana er fantastisk, men når man begynder at bruge det til udviklingsstyring, kan det blive ret kompliceret. Takket være min kollega havde vi bygget et ret genialt system ind i programmet, og det fungerede. Men det skabte meget dobbeltarbejde for udviklerne. Derfor byggede beslutningen om at skifte til det nye værktøj på samtaler, vi havde haft gennem de seneste par år, om hvordan vi kunne gøre processen bedre for alle.
Jeg vil derfor hævde, at det næsten var mere skræmmende for mig som projektleder på projektet end for en udvikler, der var klar til at bruge noget, der var tættere knyttet til arbejdsgangen.
Ben Aston:
Som projektleder er det også os, der normalt skal samle stumperne op, hvis noget går galt. Det er vores ansvar. Det kan derfor godt være lidt skræmmende. En anden pointe i artiklen handler om at være realistisk. Projektledelse handler i sidste ende om at hjælpe folk med at udføre deres bedste arbejde, ikke om at stå i vejen.
Det er helt afgørende. Vi forsøger at gøre tingene bedre, men vi skal ikke have et ego med i det. Det handler ikke om: “Jeg har fået denne fantastiske idé, så lad os gøre det,” og derefter holde fast i den, selvom det er en dårlig idé. Hvis noget ikke fungerer eller skal ændres, er det et godt råd at vurdere det og finde ud af, om det fungerer, og derefter forbedre processen i stedet for stædigt at holde fast og tænke: “Det er min måde eller ingen måde.”
Alexa Huston:
Præcis. Det er også noget, Scrum hjælper med at gøre tydeligt. Selv før vi brugte Scrum-rammeværket, havde vi altid gennemført evalueringer efter hvert sprint og ved slutningen af hvert projekt. Det er en god måde at få feedback fra teamet på. Målet er at få konkrete handlinger ud af det: “Lad os tale om, hvad der gik godt, og hvad der ikke gik så godt, men lad os også finde løsninger på problemerne og eksperimentere med dem.”
På den måde understøtter Scrum-metoden det og hjælper os med ikke kun at teste og gentage det produkt, der udvikles, men også at teste og gentage selve processen undervejs. Evalueringerne er afgørende. Der findes mange forskellige måder at gennemføre en evaluering på. Jeg vidste ikke, at man kunne gribe det an på så mange måder, naturligvis med forskellige spørgsmål. Det er vigtigt for os at eksperimentere med dem og forsøge at få svar gennem forskelligt formulerede spørgsmål.
Et konkret eksempel er en evaluering, vi for nylig gennemførte. Et teammedlem sagde: “ZenHub fungerer godt, men jeg er ikke helt sikker på, hvordan jeg kan se, hvad der er i gang på et bestemt tidspunkt. Jeg ved, hvad jeg er ansvarlig for i dette sprint, men det ville hjælpe at vide præcis, hvilken opgave jeg arbejder på.” Derfor besluttede vi ikke kun at have en kolonne med sprintbacklog, men også en kolonne for igangværende arbejde. På den måde var der en klar forskel mellem alle de ting, vi arbejdede på i sprintet, og den konkrete opgave, som personen arbejdede med. Bare det at tilføje en ekstra kolonne i ZenHub var et resultat af en nylig evaluering.
Ben Aston:
Det er fantastisk, når vi kan lytte til teamet og foretage ændringer. Det koster ingenting at tilføje en kolonne, men det får folk til at føle sig hørt og til at mærke: “Det betyder faktisk noget. Jeg fik denne idé,” og så …
Alexa Huston:
Ja, og det gør os bedre.
Ben Aston:
Du har nævnt ZenHub, som jeg aldrig selv har prøvet. Er der andre værktøjer, du for nylig har fundet, som gør dit liv lettere?
Alexa Huston:
Vi elsker værktøjer hos Crema. En af vores grundlæggere skrev for nylig en blogartikel om, at vi bruger omkring 36 forskellige SaaS-produkter og værktøjer til at drive virksomheden.
Ben Aston:
Det lyder dyrt.
Alexa Huston:
Det kan det være. Noget af det er G Suite og den slags, men ja, vi elsker bestemt vores værktøjer. Vi gennemgår dem også lejlighedsvis for at sikre, at de stadig skaber værdi, opfylder vores behov, eller om der findes en bedre løsning eller slet ingen løsning. ZenHub er fantastisk. Jeg har nævnt Asana, som er vores vigtigste værktøj og har været det i mange år. Vi er store fans af det.
Vi bruger stadig Asana til nogle projekter og intern kommunikation, men vi prøver virkelig at holde øje med, hvad teamet finder derude. Vi er alle meget nysgerrige på forskellige og bedre værktøjer. ZenHub er det seneste eksempel, men vi holder altid øjnene åbne efter noget andet, der kunne fungere. Der findes mange gratis prøveperioder, så vi tøver normalt ikke med at tilmelde os og eksperimentere undervejs.
Ben Aston:
Afprøver I noget i øjeblikket?
Alexa Huston:
Jeg prøver at komme i tanke om noget. Lige nu gør jeg ikke. Måske gør min kollega, men jeg kan ikke komme i tanke om noget i øjeblikket. Jeg er sikker på, at der er noget, jeg glemmer.
Ben Aston:
Ud over Asana og ZenHub, hvilke projektstyringsværktøjer bruger I så? Hvordan holder I øje med forbruget, hvis I styrer projekter efter varighed? Den forventede pris og den faktiske pris er vel præcis den samme, ikke?
Alexa Huston:
Det burde de være. Vi bruger også Harvest og Forecast til at følge det. Når vi taler om ZenHub, vil jeg gerne rose det en gang til: Det har en fantastisk rapportering, så vi kan se vores nedbrænding i hvert sprint undervejs. Harvest og Forecast hjælper os med at holde øje med kapacitet og den slags. Vi har brugt Dropbox Paper til notater, og det har fungeret rigtig godt. Det er meget samarbejdsorienteret, og vi kan virkelig godt lide det. Og naturligvis Slack, fordi det er det bedste chatværktøj i Amerika – i verden.
Ben Aston:
I Amerika.
Alexa Huston:
Ja, her i Amerika er det det bedste. Vi bruger altså en række forskellige værktøjer. Jeg elsker vores værktøj til medarbejderengagement, som hedder 15Five. Hver fredag udfylder jeg et kort spørgeskema, der sendes direkte til min chef, så jeg kan få feedback på, hvordan det går. Det minder lidt om en evaluering, og det har skabt mange gode samtaler mellem min chef og mig og med teamet generelt om, hvad der går godt, hvad der kan forbedres, og hvad vi ser frem til.
Ben Aston:
Det lyder godt. Alexa, mange tak fordi du ville være med. Det har været fantastisk at have dig med.
Alexa Huston:
Mange tak. Jeg sætter virkelig pris på tiden.
Ben Aston:
Hvis du gerne vil bidrage til samtalen, hvis du har gennemført procesændringer og har nogle gode råd, eller hvis du har forsøgt at skifte til Scrum, hvorfor så ikke deltage i samtalen med tusindvis af andre digitale ledere i vores DPM-forum? Du finder det under sektionen “Fællesskab” på thedigitalprojectmanager.com, hvor der foregår alle mulige samtaler. Du kan også skrive en kommentar til Alexas artikel, så svarer hun sikkert. Men indtil næste gang: Tak fordi du lyttede med.
