Agile Marketing: slik begynner du å bruke metodikken

Siden jeg forrige uke publiserte en veiledning om Trello, tenkte jeg at det kunne være nyttig å forklare hvordan jeg bruker Agile-metodikken i prosjektene mine.

Kanskje agile metoder ikke sier deg så mye.

Eller kanskje du tror de bare er for programvareutvikling og digitale produkter.

Ingenting kunne vært lenger fra sannheten: de kan faktisk brukes på enhver prosess, ethvert prosjekt eller enhver avdeling.

Og denne artikkelen har to svært tydelig adskilte deler:

• I den første skal jeg fortelle litt om hva agile metoder er og hvordan det hele begynte. Teorien bak dem og begrepene.
• I den andre delen skal jeg forklare hvordan jeg bruker de delene av metodikken jeg liker i markedsføringsteam, slik at du, hvis du er interessert, kan begynne å bruke dem i ditt eget team med en gang. Den praktiske og operative delen.

Hvis du allerede kjenner den første delen, kan du hoppe rett hit.

La oss begynne fra starten.

Del 1: Hva Agile-metodikken går ut på

Det er en tilnærming til beslutningstaking i prosjektledelse som fokuserer på å utvikle funksjonalitet inkrementelt og iterativt, og gir brukeren / kunden mer verdi i hver syklus.

Den oppstod først innen programvareutvikling og ble kort tid etter tatt i bruk på andre områder, som prosjektledelse av alle typer (ikke bare programvare), produktutvikling, UX og markedsføring.

Den står i motsetning til fossefallsmodeller -der én del av prosjektet må være ferdig før den neste kan begynne- fordi de anses som for byråkratiske, og legger stor vekt på kommunikasjon mellom partene, fremfor dokumentasjon.

Høres bra ut, ikke sant? Men kanskje du lurer på hvordan alt dette oppstod.

Det skal du få se nå.

Historien til Agile-metodikken

På midten av 90-tallet oppstod en strømning som avviste strukturert prosjektledelse, og den kulminerte i en samling i 2001 i Snowbird, Utah.

Der ble begrepet “Agile Methodology” brukt for første gang, “Agile Alliance” ble opprettet og “Agile Manifesto”, som samler metodikkens prinsipper, ble publisert.

Agile-manifestet

Du kan lese originaldokumentet her:

http://agilemanifesto.org/

Manifestets fire verdier

Som du kan se i lenken ovenfor, står det i dokumentet:

“Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og hjelpe andre med å gjøre det. Gjennom dette arbeidet har vi lært å verdsette:

• Individer og samspill fremfor prosesser og verktøy
• Fungerende programvare fremfor omfattende dokumentasjon
• Samarbeid med kunden fremfor kontraktsforhandlinger
• Å reagere på endring fremfor å følge en plan

Det vil si at selv om punktene til høyre har verdi, verdsetter vi punktene til venstre mer.”

Og disse fire verdiene deles opp i disse tolv prinsippene.

De tolv prinsippene i Agile-manifestet

Du finner dem her:

http://agilemanifesto.org/principles.html

Men jeg kopierer dem for deg:

1. “Kundetilfredshet. Det er grunnlaget for alt. Det oppnås ved å levere verdifulle produkter som dekker et behov.
2. Nye krav er velkomne. Å endre kurs underveis er ikke å ta et skritt tilbake. Alle forslag eller løsninger er velkomne hvis de forbedrer produktet.
3. Ukentlige leveranser. Å dele arbeidet inn i produktive faser er grunnlaget for metodikken. Når det er mulig, gjennomføres én hver uke.
4. Fremgang kan måles. Utviklingen av prosesser er ikke subjektiv. Den kan måles med konkrete indikatorer.
5. Bærekraftig utvikling. Måten prosjektene gjennomføres på må i seg selv sikre kontinuiteten. Det handler ikke om å gjøre ting bare for å gjøre dem.
6. Nært samarbeid. Prosjektledere bør utføre arbeidet sitt der oppgavene faktisk skjer, ikke fra kontoret.
7. Ansikt-til-ansikt-samtale. Den ansvarlige lederen må kommunisere budskap effektivt, helst personlig. Regelmessige møter med både kunden og medarbeiderne anbefales.
8. Motivasjon og tillit. Prosessene lykkes bare hvis de som gjennomfører dem er motiverte og samarbeider i et klima preget av tillit og solidaritet.
9. Teknisk kvalitet og godt design. Formen må aldri gå tapt, og heller ikke kvaliteten på arbeidet. Alt henger sammen.
10. Enkelhet. Oppgavene bør være så enkle som mulig. Hvis en oppgave ikke kan utføres på den måten, må den deles inn i iterasjoner til kompleksiteten er redusert.
11. Selvstyrte team. Selv om det bør finnes noen som følger opp teamene, må de kunne organisere seg selv. For mye hierarki skaper avhengighet mellom medarbeiderne.
12. Tilpasning til skiftende omstendigheter. Prosjekter ender som regel ikke på samme måte som de startet. Det er avgjørende at de som gjennomfører dem kan tilpasse seg de ulike omstendighetene som kan oppstå.”

Jeg vet ikke hva du synes, men hvis du noen gang har vært involvert i utvikling av digitale produkter, er det vanskelig å ikke være enig i absolutt alle punktene.

Veldig vanskelig.

Så mye at metodikken i dag, på grunn av nytten på det opprinnelige området, som sagt er overført til ledelse av alle typer prosjekter og til og med sektorer.

Man snakker om “Agile Product Design”, “Agile Marketing” og “Agile Management”, der man alltid prøver å fokusere på:

• Kommunikasjon ansikt til ansikt.
• Åpenhet.
• Kundetilfredshet.
• Enkelhet.
• Inkrementell utvikling og kontinuerlig forbedring.

Begynner du å se poenget med metodikken?

La oss gå videre til de viktigste elementene.

Grunnleggende elementer og begreper i Agile-metodikken

Bra. Alt som er forklart så langt høres veldig fint ut, men for å komme i gang må vi bringe teorien ned på et praktisk nivå og forklare de ulike elementene som gjør planlegging og gjennomføring mulig.

Frameworket

Selv om alle agile metoder bygger på de samme prinsippene og verdiene, bruker hver av dem disse på forskjellig måte.

Og disse ulike måtene å gjøre ting på er de forskjellige frameworks eller referanserammene.

Det finnes flere, hver med sine regler, fordeler, anbefalinger og ulemper. De to vanligste og mest kjente er Kanban og Scrum.

Kanban

Det oppstod i Japan etter andre verdenskrig, som hadde etterlatt landet i en økonomisk og teknologisk katastrofe.

På 50-tallet utviklet Toyota et produksjonssystem “just in time” (JIT) der hver del ble produsert akkurat på riktig tidspunkt, verken før eller etter, og som ble beskrevet som “svært effektivt og formålstjenlig”.

For å gjennomføre det brukte man kort som identifiserte materialbehovene i produksjonskjeden.

Metodikken tar dermed ideen om kort og likestiller hvert kort med en oppgave.

Man oppretter en tavle med én kolonne for hver status som en oppgave må gjennom, for eksempel:

• Definert.
• Under arbeid.
• Fullført.
• Kontrollert.

Dette er et eksempel på en enkel tavle, men den kan gjøres så kompleks som prosjektet krever. Et mer komplekst eksempel kan være:

• Definisjon.
• Analyse.
• Utvikling
• Testing.
• Produksjonssetting.
• Dokumentasjon.

Tavlen vil være forskjellig for hver bedrift eller hvert team avhengig av behovene, og kan brukes både på nye utviklingsprosjekter (“lansere bloggen”, “åpne en TikTok-kanal”) og på vedlikeholds oppgaver (“gå gjennom bannerne på nettstedet”) eller gjentakende oppgaver (“gå gjennom affiliateprovisjoner”, “ukentlig ecommerce-rapportering”).

Tavlen kan være fysisk (det anbefales for at den skal være synlig og transparent for hele teamet) eller digital, og det er her Trello kommer inn.

Scrum

Den ligner den forrige, for som jeg sa bygger de på de samme prinsippene og den samme filosofien.

Navnet kan oversettes som “klynge” og kommer fra rugby, når hele laget samler seg.

De skiller seg i små nyanser, kanskje fordi Scrum regnes som mer restriktivt og etter min erfaring er mer rettet mot utvikling av digitale produkter:

• Anbefaler tverrfaglige team. I Kanban er spesialiserte team tillatt.
• Bestemte roller: Scrum Master, Product Owner og utviklingsteam er obligatoriske i Scrum; i Kanban kan du ha dem eller ikke
• Iterasjoner med fast varighet (mellom 1 og 4 uker): sprintene (det legges stor vekt på dette).
• Endringer: det som går inn i en sprint er låst, og ønskede endringer utsettes til neste sprint slik at burn-prosessen eller Burndown kan måles (det er ikke fullt så enkelt). I Kanban er endringer enklere å gjennomføre, siden en funksjonalitet med lavere prioritet kan byttes ut med den nye ønskede.
• Seremonier med fast varighet.
• Ny tavle i hver sprint versus Kanbans permanente tavle.

Av alle disse grunnene foretrekker jeg personlig Kanban for Agile Marketing, og det er den jeg skal forklare i denne artikkelen.

Faktisk er det ikke det vanligste, men jeg har sett og jobbet med hybridmodeller:

• Scrum for nyutvikling og Kanban for gjentakende oppgaver i samme team. Det var modellen vi hadde hos Lowi.
• Metodikken “Scrumban”, som låner deler fra begge.

User stories

Kanskje kjernen i metodikken.

Det er en enkel måte å beskrive en kortfattet oppgave som gir verdi til brukeren eller kunden.

De skrives vanligvis på kort (for hånd på post-it-lapper eller digitalt) og inneholder:

1. Tittel: kort, slik at man kan referere til den.
2. Beskrivelse: Som [brukerrolle] vil jeg [funksjonalitet] slik at [Målet med historien]. Eksempel: "Som bloggleser vil jeg se relaterte artikler nederst i artikkelen slik at jeg kan fortsette å lese om temaer som interesserer meg«.

I tillegg må de ha disse egenskapene:

1. Uavhengige: av hverandre. De må kunne håndteres separat selv om de henger sammen. I en annonsekampanje vil for eksempel designoppgaven skilles fra copywritingoppgaven, selv om de naturligvis må være relatert.
2. Forhandlingsbare: omfang og detaljer avtales mellom begge parter og reforhandles om nødvendig, for eksempel ved å dele oppgaven i to.
3. Verdifulle: de må gi kunden reell, konkret verdi.
4. Estimerbare: det vil si at innsatsen som kreves for gjennomføringen kan analyseres. I tid eller utviklingspoeng.
5. Små: hvis de er for store og ikke kan estimeres, må de deles opp.
6. Verifiserbare: testbare, med binære akseptansekriterier (bestått eller ikke bestått).

Når oppgaven er skrevet, plasseres den i den første kolonnen på tavlen, og flyttes mellom kolonnene etter hvert som statusen endres.

Backloggen

Det er samlingen av prosjektoppgaver som allerede er formulert og fortsatt venter på å bli håndtert.

Teamet

Avhengig av metodikk kan det være nødvendig eller ikke å ha bestemte roller i teamet.

I Scrum har man for eksempel vanligvis:

• Product Owner: forretningsansvarlig for produktet.
• Scrum Master: problemløser og fasilitator for utviklingen. Personen kan være teamleder eller ikke.
• Utviklingsteam / spesialister (UX, designere, SEO…): altså de som faktisk skal utføre de fleste oppgavene.
• Tech lead: teknisk ansvarlig for teamet. Det kan være samme person som har rollen som Scrum Master.
• QA: testing.

I Kanban er disse rollene ikke nødvendige, selv om det er sant at jo tydeligere rollen til hvert teammedlem er definert, desto enklere blir det å vurdere oppgaven og senere gjennomføre den.

Sprinter

Varigheten på en iterasjon, syklus eller leveranse der én eller flere prioriterte nye funksjoner eller forbedringer (features) i et digitalt produkt lanseres, eller der de relevante oppgavene i syklusen gjennomføres (“lage Instagram-innhold”).

Vanligvis varer de mellom én og fire uker. I digital produktutvikling er det ofte to eller tre, mens de i markedsføring fint kan vare én uke.

Sprintmålet

I produktutvikling har man et Sprintmål, som samler de fleste funksjonene man ønsker å gjennomføre.

I andre typer prosjekter er et slikt mål ikke alltid nødvendig.

Seremonier

Dette er navnet på teammøtene som hører til metodikken.

Dette er de vanligste, og hver av dem har sin varighet, frekvens og sine mål:

De brukes til å analysere og forbedre utvikling og prosesser iterativt

• Daily: hver dag forteller teammedlemmene svært kort hva de skal gjøre den dagen og om noe blokkerer en tidligere oppgave, slik at man kan diskutere stegene som trengs for å fjerne blokkeringen. Det bør vare omtrent fem minutter.
• Sprint plan: når den pågående sprinten avsluttes møtes teamet for å diskutere hvordan neste sprint skal angripes og estimere oppgavene.
• Refinement: dette er steget før den forrige seremonien. Under refinement skal hver story være tydelig og forståelig nok for teamet, og omfanget være definert slik at den kan estimeres i Sprint plan.
• Retrospektiv: etter at sprinten er avsluttet analyserer man hvordan det gikk, hvilke problemer man møtte og hvilke forbedringspunkter som kan tas med i fremtidige sprinter.

Hvis vi snakker om markedsføring, er alle disse seremoniene nødvendige?

Senere gir jeg deg svaret mitt, for her slutter teorien.

Nå skal jeg forklare hvordan jeg har brukt dette fra bunnen av i ulike team og prosjekter.

Du vil også se at tilnærmingen er svært enkel og at det ikke kreves radikale endringer eller nye verktøy for å begynne å bruke agile prinsipper.

Del 2: Prosessen for å innføre Agile-metodikken i Marketing

Hvis du aldri har hatt erfaring med agile metoder, er det første jeg vil at du gjør å lese manifestet og prinsippene flere ganger, for egentlig er det nok til å forstå og begynne å bruke noen av konseptene.

Det handler om et tankesettskifte der jeg vil si at det viktigste er å snakke og bli enige mellom partene (ledere, eget team, eksterne team…) med vissheten om at alle søker det felles beste.

For det andre, være fleksible. Forstå at endringer vil komme og at vi må godta dem. Selv om det irriterer oss. Det betyr ikke å alltid “gi etter”, men å gå tilbake til forrige punkt: snakke og bli enige.

For det tredje og siste, måle. For måling er den eneste måten vi har å vite hvor optimal prestasjonen vår er, hvordan teamet presterer og om alle tiltakene vi gjennomfører faktisk er verdt det.

Bra, når du har fått det godt inn i hodet, kan vi snakke om systemet.

Agile Marketing-systemet

Ideen bak er at teamet ditt er i stand til å gjennomføre et begrenset antall oppgaver innen en gitt tid.

Denne perioden kaller vi en sprint, og til å begynne med er det enklest at den varer én uke.

Da må du organisere et system slik at riktig antall oppgaver gjennomføres hver uke (sprint).

Hvor mange oppgaver er det? I begynnelsen vet du ikke, fordi du ikke har noen historikk. I de første sprintene kan du derfor maksimalt håpe å estimere med en viss feilmargin, som blir mindre etter hvert som du og teamet får mer erfaring.

Dessuten har dere ennå ingen erfaring med å formulere oppgaver, noe som legger et ekstra lag med vanskeligheter til estimatet.

Men slapp av, denne usikkerheten varer ikke lenge: når du har gjennomført flere sprinter, målt og lært å formulere oppgavene riktig, har du data som gjør at du kan estimere hver oppgave mye bedre.

Når du vet hvordan dette vil utvikle seg, er det første du trenger et verktøy der du kan opprette backloggen og skrive inn alle oppgavene i sprinten.

Verktøyene for Agile Marketing

Du har flere alternativer, avhengig av om du foretrekker online eller offline.

Fordelene med hver type?

Onlineverktøy er mer umiddelbare og kan koste svært lite, mens offlineløsninger i praksis består av en tavle og noen post-it-lapper, og gjør det svært tydelig for hele teamet hva det jobbes med samtidig som arbeidet blir mer synlig for virksomheten.

Min anbefaling?

Bortsett fra i tilfeller der det er helt nødvendig å synliggjøre alt som gjøres svært tydelig, begynn med et onlineverktøy.

Jeg anbefaler to, avhengig av hvor overbevist du er om systemet: Excel hvis du vil prøve, og Trello hvis du er sikker på at dette er noe for deg.

Agile Marketing med Excel

Jeg sier Excel fordi det er mest utbredt, men ethvert regneark (Google Sheets, LibreOffice…) fungerer.

Poenget her er ikke så mye å snakke om Kanban og tavler, men å begynne å bruke agile prinsipper med en gang.

Til det lager du et dokument der du legger til alle oppgavene som skal gjennomføres, én under den andre. Det blir din Backlog.

I tillegg lager du en rekke kolonner som hjelper deg å definere hver oppgave, planlegge og måle teamets prestasjon og innsatsen hver oppgavetype krever:

I dette tilfellet har vi følgende kolonner:

• Prioritet: selv om vi kunne plassert oppgavene med høyest prioritet i sprinten øverst, ville det hindre oss i å filtrere, derfor legger vi til en kolonne.
• Merke: hvis du jobber med flere kunder eller merkevarer, lar dette deg segmentere etter hver av dem.
• Oppgaver: her legger vi bare til tittelen, fordi det vanligvis er oppgaver vi allerede kjenner og som ikke trenger mer omfattende beskrivelser.
• Kommentar: hvis vi likevel trenger mer detalj, legger vi det til her.
• Oppgavetype: dette lar oss se hvor mye tid vi bruker på hver ulike aktivitet og analysere:
• Om tiden vi bruker er verdt det.
• Om gjennomføringstiden blir kortere etter hvert som personen får mer erfaring med samme type oppgave.
• Person: altså, hvem som skal utføre den.
• Oppgavestatus: Ikke startet, Startet eller Fullført.
• Inngangsdato: startdatoen for sprinten, som lar oss filtrere det som gjøres i hver sprint.
• Start: datoen oppgaven endrer status fra Ikke startet til Startet.
• Starttid: tidspunktet en oppgave starter.
• Sluttid: tidspunktet en oppgave avsluttes.
• Innsats i timer: forskjellen mellom Starttid og Sluttid.
• Uke: for å vite hvilken uke i året det er og kunne sammenligne senere eller lage grafer.

I hver sprint legges de nye oppgavene til med Inngangsdato, og ved å filtrere på denne datoen har vi den nye sprinten klar.

Hvis det naturligvis står igjen oppgaver fra andre sprinter, legger vi datoen for forrige sprint til filteret slik at oppgavene fra begge vises.

Denne metoden fungerer så lenge vi ikke har oppgaver som strekker seg over mer enn 2 sprinter; ellers vil de hope seg for mye opp og vi trenger et annet system, for eksempel å lage en ny oppgave i den nye sprinten som erstatter den som ikke ble fullført i den forrige.

Bra, en mal som denne er mer enn nok til å begynne å planlegge og bruke de tre pilarene i agility: bli enige, være fleksibel og måle.

Når du har brukt det en stund -og ser at det fungerer-, vil du kanskje ta et steg videre. Da er tiden inne for å bytte verktøy…

Agile Marketing med Trello

Først og fremst har du her en veiledning for å komme i gang med verktøyet.

Når du har lest den og opprettet kontoen, skal du vite at jeg også har publisert denne artikkelen om hvordan du bruker Trello til å anvende Kanban-metodikken i markedsføring, der jeg går mer i detalj, men her er uansett noen hovedpunkter:

1. Opprett bare én tavle til å begynne med. Det er mye enklere å administrere når du starter.
2. På den tavlen oppretter du 3 eller 4 kolonner, ikke flere. De kan være:
• Backlog: backloggen med alle oppgavene, både de i den pågående sprinten og alle andre som legges til for fremtidige sprinter.
• To do: flytt oppgavene som skal utføres i denne sprinten fra Backlog til denne kolonnen. Oppgavene med høyest prioritet plasseres øverst.
• Doing: når sprinten har startet, flytter personen som er ansvarlig for hver oppgave den fra To do til denne kolonnen når arbeidet begynner.
• Done: når en oppgave er fullført, flyttes den fra Doing til denne kolonnen.
3. Hvis oppgaven må valideres av en annen person enn den som utførte den, legger vi til en femte kolonne, “Validated”.
4. Når sprinten er lukket, arkiveres alle fullførte oppgaver, og vi begynner å legge oppgavene i den nye sprinten i To do.

Enkelt, ikke sant?

Nå gjenstår bare analyselaget: finne ut hva som skjedde hvis noe ikke ble ferdig, om problemet lå i analysen av teamets kapasitet, formuleringen av oppgaven, estimeringen av oppgaven…

Og én måte å håndtere dette på er gjennom seremoniene.

Seremonier i Agile Marketing

I teoridelen snakket vi om fire seremonier:

• Daily.
• Sprint plan.
• Refinement.
• Retrospektiv.

Hver av dem gjennomføres med svært klare mål, men jeg mener de er sterkt rettet mot digital produktutvikling og at ikke alle er nødvendige i markedsføring.

I praksis avhenger det også av teamstørrelsen, for jo større teamet er, desto viktigere blir det å skape orden og lytte.

Med det avklart, her er min mening om hver av dem:

Daily er uunnværlig. Det er den fordi den hjelper teamet mye med å fungere godt og fjerne blokkeringer, samtidig som alle vet hvor vi står.

En sprint plan er nyttig, men ikke nødvendig dersom teamet er lite (opptil 3-4 personer).

Og refinement, er enda enklere å klare seg uten, fordi et team som har jobbet sammen en stund ikke trenger en egen økt for å avklare ting som kan løses med en Slack-melding eller en 30-sekunders samtale mellom de to partene.

En retrospektiv er spesielt nyttig hvis det har oppstått et viktig problem i sprinten. Å lytte til meningen til hvert medlem hjelper oss å ta gode beslutninger om forbedringer.

Når det er sagt, mener jeg ikke at de må holdes etter hver sprint (særlig hvis sprintene er ukentlige), men de bør holdes regelmessig og, som sagt, alltid når det har oppstått et problem av en viss betydning.

For å avslutte vil jeg si at seremonier må være et middel for å nå et mål, ikke et mål i seg selv, slik jeg noen ganger har opplevd.

Teamstørrelse

Selv om jeg har brukt systemet som er forklart så langt i team med 10 personer, tror jeg noen justeringer ville vært nødvendige ved denne størrelsen.

Derimot tror jeg det er perfekt for mindre team på mellom 3 og 6 personer.

Hvis teamet ditt er mindre, tror jeg ikke engang Trello er nødvendig. Excel og Slack (eller Telegram) kan være mer enn nok.

Fordeler med Agile Marketing

Den største fordelen for meg er å kunne ha en oversikt over alle oppgavene som skal gjøres i hver sprint, slik at vi tydelig ser hvilke vi rekker og hvilke som må utsettes. Det er svært enkelt å prioritere og tildele oppgaver til personer.

Organisatorisk er dette fantastisk, særlig fordi teamet vet hva det skal gjøre og kan fokusere på det.

Den neste fordelen er at når systemet er implementert, kan vi måle og analysere hver type oppgave. Hvis du sammenligner innsatsen med forretningsverdien, kan du bli overrasket og slutte med oppgaver du har gjort i årevis (“Facebook-innlegg”).

Eller finne ut hvilken person i teamet som passer best til hver oppgave.

En annen fordel er at, særlig hvis du bruker Trello fremfor Excel, blir alt dokumentert, slik at vi har et ekte repository tilgjengelig.

Til slutt kan, hvis det er nødvendig, som jeg nevnte tidligere, en godt utfylt tavle eller backlog synliggjøre verdien av arbeidet som er gjort av teamet.

Til slutt er kostnaden for alt dette liten:

• I penger, fordi verktøyene er gratis eller rimelige.
• I tid, for selv om arbeidsmengden øker litt, håper jeg at jeg har gjort det klart at det mer enn betaler seg.

Konklusjoner

Selv om artikkelen er ganske lang, har jeg knapt skrapt i overflaten av Agile-metodikken.

Det er en introduksjon slik at du kan vurdere om dette passer for deg, eller om systemet du bruker nå passer bedre.

Uansett system vil jeg at du først og fremst tar med deg de tre tingene som for meg er metodikkens viktigste verdier:

• Snakke og bli enige mellom partene.
• Fleksibilitet.
• Måling.

Under forutsetning av at vi er enige om at alt dette i bunn og grunn handler om å få arbeidet / prosjektet i mål.

Med det sagt håper jeg at jeg har klart å forklare verdien av å bruke Agile-metodikken i Marketingteam, for riktig utført gir den virkelig mye verdi. Det sier jeg av egen erfaring.

Så gjør meg en tjeneste og gi den en sjanse.

Uansett, selv om jeg definitivt ikke er noen Scrum Master, er det bare å skrive til meg hvis du tror du trenger hjelp til å organisere teamet ditt i digitale prosjekter.