Få prosessendringer til å fungere (med Alexa Huston fra Crema)

Les transkripsjonen:

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

Ben Aston:

Takk for at du lytter. Jeg heter Ben Aston, og dette er podkasten til The Digital Project Manager. I dag har jeg med meg Alexa Huston. Alexa, tusen takk for at du ble med i programmet.

Alexa Huston:

Takk for invitasjonen.

Ben Aston:

I dag skal vi snakke om å gjennomføre prosessendringer, og om hvordan vi kan forbedre prosesser og gjøre alt litt mer oversiktlig. Men først, Alexa, la oss bli litt bedre kjent med deg. I biografien din ser jeg at du jobber i et byrå som heter Crema. Uttaler jeg det riktig?

Alexa Huston:

Det uttales Crema. Navnet kommer fra det gylne laget som stiger til toppen av en espressoshot. Hvis du kjenner til kaffe eller har jobbet som barista, høres det kanskje kjent ut. Mange sier imidlertid Crema. Det er egentlig Crema, men begge deler går fint.

Ben Aston:

Takk for oppklaringen. Da jeg leste biografien din, la jeg merke til at du ikke bare jobber på kontoret. Når du ikke er der, trener du for å bli sterkere, lager noe godt på kjøkkenet eller reiser. Vi snakket faktisk litt om reisene dine tidligere. Men hvordan går det med dette med å bli sterkere?

Alexa Huston:

Det er et arbeid som pågår, men det går bra. Jeg begynte på et fantastisk treningssenter mot slutten av fjoråret, og det er veldig morsomt. Jeg gjør ting jeg aldri trodde jeg skulle gjøre, som olympiske løft og MetCon-trening. Det har blitt en litt større del av livet mitt det siste året enn tidligere, og det har vært veldig gøy.

Ben Aston:

Det høres ganske seriøst ut. Deltar du i konkurranser?

Alexa Huston:

Jeg tror aldri jeg kommer til å gjøre det.

Ben Aston:

Eller slåss med folk?

Alexa Huston:

Nei, nei. Det handler bare om å bli sterkere og sunnere, og om å gjøre noe sammen med kjæresten min for å bli litt bedre hver dag.

Ben Aston:

Hyggelig. Så fortell litt om deg selv. Hvordan endte du opp som digital prosjektleder? Jeg tok en sniktitt på LinkedIn-profilen din og så at karrieren din, eller i hvert fall en del av den, startet som lærer i skriving og tidsstyring. Det høres ut som en perfekt utdannelse for en prosjektleder.

Alexa Huston:

Ja, det kan man absolutt si. Det skjedde egentlig litt tilfeldig. Jeg gikk på et flott universitet med et læringssenter, og hadde en arbeidsstudieordning der. De spurte om jeg ville være veileder i tidsstyring og skriving, så det gjorde jeg gjennom hele studietiden. Etter noen omveier etter endt utdanning ble jeg tradisjonell prosjektleder i et reklamebyrå, der jeg lærte det grunnleggende om prosjektledelse fra et tradisjonelt markedsføringsperspektiv.
Jeg var der i et par år før jeg tok en liten pause for å reise og bo på Hawaii i en måned. Da jeg fortalte at jeg skulle slutte, tok en tidligere kollega kontakt og spurte hva planen min var da jeg kom tilbake. Jeg svarte at jeg ikke hadde noen konkret plan, men spurte om han hadde noe i tankene. Han var strateg for forretningsutvikling i Crema og sa at de lette etter en ny prosjektleder. De bygget nett- og mobilapper. Jeg tenkte: «Hvor annerledes kan det være?» Det viste seg å være veldig annerledes. Jeg har lært mye, men jeg havnet egentlig i dette ved en tilfeldighet. Det har vært to flotte år med å lære meg livet som digital prosjektleder.

Ben Aston:

Kult. Jeg har en lignende historie. Jeg startet i tradisjonelle reklamebyråer før jeg gikk over til digitalt arbeid. Hvordan var overgangen for deg? Var du teknisk anlagt fra før?

Alexa Huston:

Det er et godt spørsmål. Ikke egentlig. Jeg hadde vært borti et par digitale prosjekter i reklamebyrået, men i ettertid var det knapt det. Jeg hjalp til med å administrere innholdsproduksjon på et nettsted, så jeg trodde jeg hadde litt kjennskap til området. Jeg har alltid vokst opp med teknologi, men jeg vil ikke kalle meg teknolog. Derfor var læringskurven ganske bratt da jeg begynte. Jeg tok nesten umiddelbart ansvar for mitt første prosjekt, der vi bygget om et finansteknologiprodukt, og det var mye jeg ikke hadde tenkt på. Heldigvis hadde jeg et godt team som hjalp meg, men jeg kom virkelig inn med lite erfaring. Ikke når det gjaldt prosjektledelse, men som digital prosjektleder. Det er mye å lære.

Ben Aston:

Fortell litt om Crema. Jobber dere hovedsakelig med nett- og mobilapper?

Alexa Huston:

Det stemmer. Vi spesialiserer oss hovedsakelig på JavaScript-baserte nett- og mobilløsninger. Vi bruker mye React og React Native. I tillegg jobber vi mye med forretningsstrategi, prototyping, brukertesting og validering av ideer. Vi betjener hovedsakelig to ulike typer kunder. Den ene kan være en erfaren gründer som har litt penger å eksperimentere med på en ny idé. Da hjelper vi med å validere og teste produktet, som vi forhåpentligvis kan bygge etter valideringen. Det er veldig morsomt.

Ben Aston:

Ja.

Alexa Huston:

Vi jobber også med mer etablerte selskaper som kanskje har et innovasjonsteam eller en produktleder som har fått ansvar for innovasjon. De kommer til oss og sier: «Jeg har dette budsjettet og trenger å forbedre noen ting. Dette er det jeg tenker. Kan vi utforme det og teste det?» Andre ganger sier de: «Vi må bygge dette på nytt nå», og da svarer vi: «Det høres bra ut, men la oss først undersøke det grundig og forstå den beste måten å gjøre det på.»

Ben Aston:

Det høres morsomt ut. Gjør dere ting som designsprinter med gründere som har mye penger og vil teste en idé? Hvordan validerer dere?

Alexa Huston:

Ja, vi gjennomfører designsprinter. Vi henter mye læring fra Googles prosess for designsprinter, men har tilpasset den til våre behov. Ofte foreslår vi et samarbeid på fire til seks uker. Vi møter kunden og gjennomfører en halvannen- til todagers oppstartsøkt med en lean-modell, øvelser for å finne historien og andre metoder som hjelper oss å analysere ideen. Vi vil forsikre oss om at det finnes et problem folk ønsker løst, og at dette er den riktige løsningen på problemet.
Vi vet selvfølgelig ikke alt etter disse to dagene, men mye blir ofte avdekket. Da sier vi: «Greit, basert på det vi vet, la oss eksperimentere med disse ulike scenarioene.» Designerne og strategene våre begynner å lage detaljerte skisser. Egentlig bruker vi ikke engang det uttrykket, for vi går rett til design. Det finnes mange gode verktøy som hjelper designerne våre med å komme i gang, og vi er heldige som har et fantastisk team.
De lager visninger og interaktive prototyper som vi kan teste. Noen ganger tester vi med tilfeldige personer vi finner på Craigslist, eller personer som kunden rekrutterer. Andre ganger tester vi med interne interessenter hos kunden som vi vet at vi trenger innspill fra. Det blir en slags sprintplan: Vi designer i fem dager, tester i to, og gjentar deretter testing og forbedring før vi ferdigstiller retningen. Hvis vi planlegger å gå videre til utvikling, involverer vi helst utviklerne i prosessen. De kan gi råd underveis og bidra til informerte beslutninger, slik at vi til slutt har en god, eller i det minste bedre, forståelse av hva som kreves for å bygge løsningen.

Ben Aston:

Det høres morsomt ut. Jeg har gjennomført noen av Googles designsprinter. En interessant forskjell ved prosessen deres er at kunden vanligvis må være fullt engasjert en hel uke og være fysisk til stede hele tiden. De utvikler konsepter sammen med dere og lager de første prototypene. Problemet er at de fleste kunder ikke har råd til å ta de viktigste personene ut av kontoret en hel uke. Det er rett og slett ikke gjennomførbart.

Alexa Huston:

Det stemmer. Folk er travle, og de betaler mye penger for å teste ideen. Derfor begrenser vi deltakelsen til én eller to dager og lar oss selv sette i gang. Samtidig inviterer vi kundene inn i systemet vårt for produktstyring. Selv om de ikke er fysisk til stede, holder vi dem løpende oppdatert gjennom Asana, ZenHub eller andre verktøy vi bruker internt. De er fortsatt svært involvert i prosessen, men trenger ikke å sitte i et rom en hel uke. Det hadde vært flott om vi kunne gjort det, men det er ikke realistisk.

Ben Aston:

Ja. Det er fantastisk når kundene faktisk gjør det. En av kundene våre gjennomførte en hel designsprint med oss, og det fine var at kunden var involvert hele uken. Vi kom frem til et konsept som var så uventet at kunden sannsynligvis aldri ville ha gått med på det under andre omstendigheter. Det var for BCLC, British Columbia Lottery Corporation. De ønsket en morsommere måte å hjelpe folk med å velge lottotallene sine på. Mange tenker på å spille, kommer til kiosken og sier: «Jeg vet ikke hvilke tall jeg skal velge.»
Vi ville gjøre det morsommere å velge tallene, og konseptet vi utviklet var en valpvelger. Du valgte tall basert på bilder av hunder. Hver hund hadde et tall, men du visste ikke hvilket. Du valgte bare hundene du likte, og de valgte tallene for deg. Det var en ganske sprø og egentlig dum idé, men fordi kunden var involvert gjennom hele prosessen, gikk de for den. Nå er den lansert, og du kan bruke valpvelgeren til å velge lottotallene dine.

Alexa Huston:

Det er fantastisk.

Ben Aston:

Det er sprøtt hvor mye som kan skje når man involverer kundene. Ting vi kanskje ellers ville avvist, kan faktisk bli gjennomført.

Alexa Huston:

Ja, det høres fantastisk ut.

Ben Aston:

Jobber du med noen interessante prosjekter for tiden som du kan fortelle om?

Alexa Huston:

Jeg jobber med veldig mange prosjekter akkurat nå. Uten å gå inn på detaljer kan jeg nevne bransjene: nettverkssikkerhet, nettprat, dermatologi, jobbsøking på forespørsel og en rekke interne oppgaver.

Ben Aston:

Hva betyr jobbsøking på forespørsel?

Alexa Huston:

Dette produktet hjelper elever på videregående med å komme i kontakt med arbeidsgivere som kan ansette personer i den aktuelle aldersgruppen. Mange elever kjører rundt og leter etter sommerjobber eller jobber de kan ha ved siden av skolen. De besøker selskaper de ønsker å jobbe for og henter et søknadsskjema. Først etter at de har sendt inn søknaden, finner de ut om de faktisk kan jobbe der på grunn av aldersgrensen. Appen fungerer som en markedsplass med to sider og kvalitetssikrer arbeidsgiverne, slik at du bare matches med jobber du kvalifiserer til basert på alderen din.

Ben Aston:

Hvilke typer jobber kan man ikke få? Å jobbe i en bar, for eksempel?

Alexa Huston:

Ja, det er ett eksempel. På enkelte restauranter må du være minst 16 år, mens andre arbeidsgivere ansetter 14- og 15-åringer. Produktet matcher dem med bransjer de er interessert i og andre relevante kriterier, slik at de ikke møter aldersproblemet senere. Det kan være ganske demotiverende.

Ben Aston:

La oss snakke om artikkelen du skrev. Den handler om å håndtere prosessendringer og gjøre prosessforbedring enklere. Hvis du tenker at prosessen din ikke fungerer, eller vurderer å innføre Scrum i byrået ditt, bør du lese denne artikkelen først. Den er absolutt verdt å lese.
La oss først snakke litt om hva en prosess er. Prosjektledere snakker ofte om prosesser, og om hvordan de kan endres. Når vi snakker om prosess, mener vi måten vi gjør ting på, altså status quo. Det er slik vi vet om folk følger reglene, og om ting blir gjort riktig. Prosjektledere snakker om dette fordi vi forsøker å finne den beste måten å gjøre ting på. Vi vil gjøre prosessen mest mulig effektiv og strømlinjeforme den. Prosessforbedring bør derfor skje hele tiden. Vi bør prøve å endre og forbedre måten vi arbeider på. Men måten vi gjør dette på, er viktig, og det er dette Alexa skriver om i artikkelen sin. Du snakker om å være empatisk, strategisk, realistisk, dedikert og tålmodig. La oss sette dette inn i historien du forteller om å endre byrået til Scrum.

Alexa Huston:

Vi er et ganske lite byrå, med færre enn 25 ansatte. Det er viktig å merke seg at vi virkelig verdsetter kontinuerlig forbedring. Det er en felles verdi i selskapet å eksperimentere, bli bedre og forbedre arbeidsflyten for alle. Det passer også godt med hvem jeg er som person, og det er fint å vite at dette er en verdi hele selskapet deler.
For omtrent to år siden, da jeg begynte, var byrået i større grad organisert som en fossefallsorganisasjon. Kundene og prosjektene passet ganske enkelt inn i denne modellen. Det er ikke noe galt med det. Selv design- og prototypeprosjektene jeg nevnte tidligere, har i stor grad en fossefallskarakter.
Når man begynner med utvikling, blir ting imidlertid langt mindre forutsigbare og mer variable, særlig når prosjektene varer lenge. Derfor begynte vi gradvis å gå bort fra omfattende omfangsbeskrivelser og fossefallsbaserte prosjekter, og over til avtaler basert på varighet og pris. Det betyr at kunden ideelt sett betaler for teamet vårt i en bestemt tidsperiode, og kostnaden beregnes ut fra varigheten. Innenfor denne perioden hjelper smidig arbeidsmetodikk oss med å reagere på kundens behov. Vi vet kanskje nøyaktig hvor vi vil begynne og har en god idé om sluttpunktet, men underveis gjør smidige metoder det mulig å endre det som skjer.
Kort sagt har vi brukt avtaler basert på varighet og pris, og blitt mer smidige. Jeg har et flott prosjektlederteam. Vi er bare tre personer, men vi er svært engasjerte i denne modellen. For omtrent seks måneder siden sa vi til hverandre: «Vi bør kanskje bli sertifisert i Scrum.» Det var et spørsmål om faglig utvikling og om å bli bedre kjent med detaljene i prosessen. Vi hadde allerede tatt i bruk enkelte Scrum-prinsipper, men ønsket å bli bedre utdannet og kunne forklare prosessene bedre for resten av teamet. Vi ville også etablere en felles forståelse i hele organisasjonen, ikke bare i prosjektlederteamet.

Ben Aston:

Har dere rollen som Scrum Master? Er det prosjektlederens rolle, eller er det en av utviklerne som gjør det?

Alexa Huston:

Vi har rollen som Scrum Master.

Ben Aston:

Det er interessant, for Scrum fungerer ikke for de fleste byråer fordi samarbeidsmodellen er feil. De har et fast omfang. Samarbeidsmodellen du beskriver, der kunden betaler for varighet, fungerer tydeligvis godt og passer med Scrum.

Alexa Huston:

Det gjør den, selv om det kan være vanskelig å selge inn. Kundene liker ikke alltid å se et stort beløp som ikke er knyttet til bestemte leveranser. Vi prøver å forklare fordelene gjennom salgsprosessen og samarbeidet, og viser til kundeeksempler og andre resultater. Det har selvfølgelig vært tilfeller der modellen ikke har fungert for en kunde, og da gjør vi justeringer. Men den foretrukne tilnærmingen er: «La oss jobbe etter varighet og pris, være smidige og sette i gang.»

Ben Aston:

Hvor ofte har kunder sagt at dette ikke fungerer, at de har vært i gang i to måneder uten å få noe nyttig?

Alexa Huston:

Det er vanskelig. Det er nettopp derfor vi ønsket å understreke betydningen av Scrum-prosessen. Den lærer deg å ha noe som kan leveres ved slutten av hver sprint. En slik leverbar økning gjør at kunden føler seg tryggere på fremdriften. Vi beveger oss mot et mål som er synlig og mer eller mindre fysisk, noe kunden kan samhandle med på enheten sin. Overgangen til Scrum har derfor bidratt til å redusere spenningen i enkelte kundeprosjekter. I stedet for at kunden spør hvor alt blir av etter to eller tre uker, kan vi sette mer realistiske sprintmål og si: «Ved slutten av denne sprinten har vi dette.» Kunden kan se og bruke resultatet, føle seg tryggere på fremdriften og gi tilbakemeldinger.

Ben Aston:

En av tingene du trekker frem, er betydningen av empati. Hvordan fungerte det i dette eksempelet når dere endret måten dere samarbeidet med kundene på og måten teamet arbeidet på?

Alexa Huston:

Vi ønsket å gjøre det, og hele teamet visste at det skulle skje. Vi forsvant ikke i to dager og kom tilbake med en mystisk beslutning. Vi arrangerte en lunsj og læring der vi gikk gjennom hva Scrum er, hvordan det fungerer og hvorfor vi ønsket å bruke det.
Dette ga mer kontekst. Mange i teamet hadde erfaring med Scrum fra tidligere jobber, men nå så vi på det gjennom Crema-brillene og diskuterte hvordan vi ønsket å innføre det hos oss. Etter lunsj og læring delte vi oss i tre grupper, ledet av hver vår prosjektleder. Vi spurte: «Hvilke spørsmål har dere? Hva er dere bekymret for? Hva synes dere er bra?»
Vi samlet alle tilbakemeldingene i en ny prosess i Asana, der vi samler forslag til prosessforbedringer fra teamet og ideer som har kommet opp etter overgangen til Scrum. De neste månedene skal vi gå gjennom dette, finne ut hvem som eier hvert initiativ og hvordan vi skal forbedre prosessen. Hovedideen var å bli sertifisert, lære mer, gjøre det riktig og deretter komme tilbake til menneskene som faktisk utfører arbeidet. Vi måtte svare på spørsmålene deres og sette oss inn i deres situasjon, slik at det ikke oppsto unødig usikkerhet. Hvis det gjorde det, måtte vi håndtere den.

Ben Aston:

Det er viktig. Når man endrer en prosess, må man få folk med seg på forhånd i stedet for å komme med en stor kunngjøring: «Fra neste uke går vi over til Scrum. Lykke til, jeg tar ferie.»

Alexa Huston:

Det kan bli brått og forvirrende. Vi ønsket å begrense dette mest mulig. Det var også prosjekter på den tiden der vi, basert på hvor langt de hadde kommet, ikke forsøkte å innføre store endringer. Vi sa: «La oss opprettholde dagens situasjon i dette prosjektet, mens vi i dette andre prosjektet sørger for at ting følger den nye arbeidsmåten.»
Planen var ikke å endre alt over natten, men å bli sertifisert og gjennomføre en gradvis endring når forholdene lå til rette.

Ben Aston:

Det er også et poeng i artikkelen din: å være strategisk. Det finnes et riktig tidspunkt og sted for å endre ting. Det er ikke nødvendigvis lurt å si at alt endres i morgen. Det er også viktig å ha en prosess for selve prosessendringen. Man trenger en plan for å vurdere om et prosjekt egner seg for den nye prosessen. Hva gjør man med eksisterende prosjekter? Hvis man bestemmer at alle eksisterende prosjekter kan fortsette som før og at den nye prosessen bare skal brukes på nye prosjekter, kan det hende at man aldri får brukt den nye prosessen. Når det nye prosjektet kommer, er det lett å si: «La oss gjøre det på den gamle måten, for den kjenner vi.»

Alexa Huston:

Det er et godt poeng. Det er ikke alltid lett å vite med en gang. Man må stole på magefølelsen og snakke med teamet: «Føles dette riktig? Er dette riktig tidspunkt? Gir strategien mening? Vil dette forstyrre arbeidet deres for mye?»
I artikkelen nevnte jeg at vi bestemte oss for å gå ganske raskt over til ZenHub, som er et prosjektstyringslag for GitHub. Det har vært fantastisk fordi det er så tett knyttet til koden. Vi tok imidlertid beslutningen bare noen dager før utviklingen av et prosjekt skulle begynne. Vi samlet oss og diskuterte det. Jeg sa: «Bør vi gjøre dette? Jeg vet at det blir nytt og litt rart, og jeg føler meg ikke helt trygg på alle funksjonene ennå, men hvis vi ikke gjør det nå, mister vi muligheten de neste ti ukene.»
Utviklerne hadde også andre grunner, så vi bestemte oss for å hoppe i det. Jeg informerte kunden, siden vi prøver å involvere dem så mye som mulig. Kunden svarte: «Det høres bra ut, bare si fra hvordan jeg kan hjelpe.» Vi bruker fortsatt ZenHub, men dette var en situasjon der vi sa: «Greit, la oss gjøre det. Dette føles riktig, og hvis det ikke fungerer, hva er planen vår?» Vi hadde planen klar og var klare til å begynne.

Ben Aston:

Det er litt som å rive av et plaster, ikke sant?

Alexa Huston:

Ja, det er det.

Ben Aston:

Noen ganger må man gjøre det raskt, men man må hele tiden huske hvorfor man gjør det. Det kommer til å gjøre vondt, og ting kommer til å gå galt, men man må minne folk på hvorfor: «Husk hvorfor vi gjør dette. Det er for at vi ikke skal måtte registrere alle dataene og oppgavene tre ganger i timelistene våre.»

Alexa Huston:

Helt klart. Jeg var nesten mer redd enn alle andre fordi jeg var så vant til måten vi hadde drevet prosjekter på i Asana. Asana er flott, men når man bruker det til utviklingsstyring, kan det bli komplisert. Takket være en kollega hadde vi laget et ganske genialt system i programmet, og det fungerte. Men det førte til mye dobbeltarbeid for utviklerne. Beslutningen om å bytte verktøy var basert på samtaler vi hadde hatt over flere år om hvordan vi kunne gjøre prosessen bedre for alle.
Jeg vil derfor hevde at det nesten var skumlere for meg som prosjektleder på prosjektet enn for en utvikler som var klar for å bruke noe som var tettere knyttet til arbeidsflyten deres.

Ben Aston:

Som prosjektledere er det ofte vi som må rydde opp hvis noe går galt. Det er vårt ansvar. Derfor kan det være skummelt. Et annet poeng i artikkelen din er å være realistisk. Prosjektledelse handler til syvende og sist om å hjelpe folk med å gjøre sitt beste arbeid, ikke om å stå i veien.
Vi prøver å gjøre ting bedre, men dette bør ikke handle om ego. Det handler ikke om å få en kul idé og tvinge den gjennom selv om den er dårlig. Hvis noe ikke fungerer eller må endres, må vi vurdere det og forbedre prosessen, i stedet for å holde fast ved den og tenke at det er min vei eller ingen vei.

Alexa Huston:

Det er nettopp dette Scrum også bidrar til å forankre. Selv før vi tok i bruk Scrum-rammeverket, gjennomførte vi alltid retrospektiver på slutten av hver sprint og hvert prosjekt. Det er en god måte å få tilbakemeldinger fra teamet på. Målet er å finne konkrete tiltak: Hva gikk bra, hva gikk mindre bra, og hvilke løsninger kan vi prøve ut?
Scrum-metodikken oppmuntrer til dette. Den hjelper oss ikke bare med å teste og forbedre produktet som utvikles, men også med å teste og forbedre prosessen underveis. Retrospektivene er avgjørende. Det finnes mange ulike måter å gjennomføre dem på, med ulike spørsmål. Å eksperimentere med disse og prøve å få svar gjennom forskjellige formuleringer er viktig for oss.
I et nylig retrospektiv sa et teammedlem at ZenHub fungerte bra, men at det var vanskelig å se nøyaktig hva som var under arbeid. Personen visste hva han eller hun var ansvarlig for i sprinten, men ønsket å vite hvilken oppgave som faktisk var i arbeid. Derfor la vi ikke bare til en kolonne for sprintens oppgavekø, men også en kolonne for pågående arbeid. Da ble det tydelig hvilke oppgaver vi jobbet med i sprinten, og hvilken konkret oppgave hver person arbeidet med. Bare det å legge til en ekstra kolonne i ZenHub var et resultat av et nylig retrospektiv.

Ben Aston:

Det er flott når vi lytter til teamene våre. Kostnaden ved å legge til en kolonne er ingenting, men det gjør at folk føler seg hørt og opplever at ideene deres betyr noe.

Alexa Huston:

Ja, og det gjør oss bedre.

Ben Aston:

Du har nevnt ZenHub, som jeg aldri har prøvd. Finnes det andre verktøy du nylig har oppdaget som gjør livet ditt bedre?

Alexa Huston:

Vi elsker verktøy i Crema. En av grunnleggerne våre skrev nylig et blogginnlegg om at vi bruker rundt 36 ulike SaaS-produkter og verktøy for å drive virksomheten.

Ben Aston:

Det høres dyrt ut.

Alexa Huston:

Det kan det være. Noe er G Suite og lignende, men vi liker definitivt verktøyene våre. Vi gjennomgår dem også med jevne mellomrom for å kontrollere om de faktisk gir verdi, fortsatt dekker behovene våre, eller om det finnes et bedre alternativ. ZenHub er flott, og jeg har nevnt Asana, som er det viktigste verktøyet vårt. Vi har brukt det i mange år og er store tilhengere av det.
Vi bruker fortsatt disse verktøyene i enkelte prosjekter og til intern kommunikasjon, men vi følger med på det teamet oppdager. Vi er nysgjerrige på ulike og bedre verktøy. ZenHub er det nyeste eksempelet, men vi ser alltid etter noe annet som kan fungere. Det finnes mange gratis prøveperioder, så vi nøler vanligvis ikke med å registrere oss og eksperimentere.

Ben Aston:

Tester dere noe akkurat nå?

Alexa Huston:

Jeg prøver å komme på noe. Akkurat nå gjør jeg ikke det. Kanskje en annen kollega gjør det, men jeg kommer ikke på noe for øyeblikket. Jeg er sikker på at jeg glemmer noe.

Ben Aston:

Bortsett fra Asana og ZenHub, hvilke prosjektstyringsverktøy bruker dere? Hvordan følger dere med på forbruket når dere styrer prosjekter basert på varighet?

Alexa Huston:

Vi bruker Harvest og Forecast til å følge med på dette. Når det gjelder ZenHub, har de fantastisk rapportering, så vi kan se nedbrenningen i hver sprint underveis. Harvest og Forecast hjelper oss med å følge kapasitet og lignende. Vi har brukt Dropbox Paper til notater, og det har vært svært effektivt og samarbeidsorientert. Selvfølgelig bruker vi også Slack, siden det er det beste chatteverktøyet i Amerika, eller i verden.

Ben Aston:

I Amerika.

Alexa Huston:

Her i Amerika er det best. Vi bruker også ulike andre verktøy. Jeg liker medarbeiderengasjementsverktøyet vårt, 15Five. Hver fredag fyller jeg ut et kort spørreskjema som går direkte til sjefen min. Det gir tilbakemeldinger på hvordan det går, og fungerer litt som et retrospektiv. Det har ført til mange gode samtaler mellom meg og sjefen min, og med teamet generelt, om hva som fungerer, hva som kan forbedres og hva vi ser frem til.

Ben Aston:

Tusen takk for at du ble med, Alexa. Det har vært flott å ha deg her.

Alexa Huston:

Tusen takk. Jeg setter stor pris på tiden din.

Ben Aston:

Hvis du vil bidra i samtalen, har gjennomført prosessendringer eller prøvd å gå over til Scrum, kan du gjerne delta i samtalen med tusenvis av andre digitale ledere i DPM-forumet vårt. Du finner det under delen «Fellesskap» på thedigitalprojectmanager.com. Der foregår det mange interessante samtaler. Du kan også legge igjen kommentarer i Alexas artikkel, så svarer hun sikkert. Takk for at du lyttet.