Denne podkasten er en del av en artikkel publisert på The Digital Project Manager.
Du kan lese artikkelen her.
Denne podkasten presenteres av Clarizen, lederen innen bedriftsprosjekter og programvare for prosjektstyring.
Relaterte lenker:
- Clarizen | Programvare for prosjektstyring
- Skolen for digital prosjektledelse
- Ekspertvurdering: 10 av de beste verktøyene for prosjektstyring
- Slik gjennomfører du et sprintplanleggingsmøte som en proff (+ møteagenda)
- Scrum-seremonier gjort imponerende enkelt
- Slik estimerer du prosjekter: Den komplette veiledningen til prosjektbudsjett og kostnadsestimering
- Smidig vs. fossefallsmodellen. Hva bør du bruke i prosjektet ditt?
- 9 metoder for prosjektstyring gjort enkelt
- Ressurser for prosjektstyring
- Bli med i Slack-teamet vårt for prosjektledere
Les transkripsjonen:
Vi tester ut transkripsjon av podkastene våre ved hjelp av et program. Tilgi eventuelle skrivefeil, ettersom boten ikke er korrekt 100 % av tiden.
Ben Aston:
Velkommen til DPM-podkasten, der vi går forbi teorien for å gi ekspertråd til prosjektledere om hvordan de kan skape bedre digitale prosjekter. Takk for at du lytter. Jeg er Ben Aston, grunnleggeren av The Digital Project Manager.
Vær ærlig. Forlater du sprintplanleggingsmøtene dine med en veldefinert og omforent arbeidsliste, komplett med veldefinerte og estimerte oppgaver, og med full tillit til at den kommende sprinten kommer til å gå nøyaktig etter planen? Det trodde jeg ikke.
Selv om vi alle vet at sprintplanlegging er en god idé og avgjørende for prosjektets suksess, er det vanskelig. Det er vanskelig å få det riktig fordi vi prøver å redusere uklarhet, skape samsvar i teamet og komme frem til en form for enighet. Det er alltid krevende.
Hvordan kan du starte sprintene dine riktig og gjøre planleggingen som faktisk trengs for å få sprinten i riktig retning – og ikke bare en ny mislykket start som krever enda et planleggingsmøte? Som prosjektledere er det jobben vår å få dette riktig. Men hvordan gjør vi det? Riktig planlegging av en agil sprint er temaet for dagens podkast, så fortsett å lytte for å finne ut hvordan du kan starte sprinten din på riktig måte.
Dagens spesielle gjest er Alexa Huston fra Crema. Alexa er tidligere prosjektleder i DPM og jobber nå med ny virksomhet. Denne utfordringen kjenner hun svært godt. Alexa er en av våre faste prosjektledereksperter ved Digital Project Manager School. Hvis du vil lære mer av henne, kan du sjekke ut Master of Digital Project Management School, der hun skal delta. Gå til DPMSchool.com for å finne ut mer. Hei, Alexa.
Alexa Huston:
Hei, Ben.
Ben Aston:
Velkommen til 2019 – vår første samtale i 2019. Hva er de viktigste målene dine for 2019, Alexa?
Alexa Huston:
Det er et omfattende spørsmål. Jeg gjorde faktisk dette på nyttårsaften og skrev ned noen ting. Jeg er ikke spesielt opptatt av nyttårsforsetter, fordi jeg føler at jeg hele tiden setter meg mål. Men jeg vil at 2019 skal bli året der jeg lærer å slappe av. Jeg har en tendens til å være litt rastløs og travel, så jeg prøver å finne flere muligheter til å ta et skritt tilbake, meditere og være mer til stede.
Ben Aston:
Og hvor mange ganger den siste uken har du klart det?
Alexa Huston:
Jeg vil ikke snakke om hvor vellykket jeg har vært.
Ben Aston:
Ansvarliggjøring er viktig.
Alexa Huston:
Ja.
Ben Aston:
Det er bra. Det jeg har lagt merke til, er at nyttårsforsetter virker å være på vei ut, mens 30-dagersutfordringer er på vei inn.
Alexa Huston:
De er veldig populære. Treningssenteret mitt arrangerer 30-dagersutfordringer.
Ben Aston:
Ja.
Alexa Huston:
Det er en trend jeg også har lagt merke til. På en måte virker det bedre. Det er litt mindre overveldende når oppgaven deles opp i måneder.
Ben Aston:
Per måned, ja. Så kanskje du kan ha 30 dager med meditasjon neste måned.
Alexa Huston:
Kanskje. Det kunne jeg.
Ben Aston:
Du kan alltid–
Alexa Huston:
Det er for sent å begynne i januar, men kanskje i februar.
Ben Aston:
Lykke til med det. Jeg prøver fortsatt å definere mine egne mål. Jeg bestemte meg for at de skulle være riktige. Jeg mener, vi er én uke inne i året, men jeg vil ikke forplikte meg til noe før jeg vet at jeg faktisk kan følge det opp. Så jeg jobber fortsatt med det. Men bortsett fra målene dine – hva annet er nytt? Fortell oss om Crema og hva dere har planlagt i år.
Alexa Huston:
Ja, det er et godt spørsmål. Crema vokser helt utrolig raskt. Når det gjelder jobben, venner jeg meg til å jobbe eksternt på heltid for første gang. Teamet vårt vokser, og jeg flyttet til Arizona mot slutten av 2018. Jeg var heldig nok til å fortsette som medlem av Crema-teamet. Så jeg tilpasser meg et liv med fjernarbeid, og heldigvis har alle i Crema vært svært støttende. Vi har faktisk et par andre som også jobber fra ulike steder. Mellom dem, meg og noen få personer ved hovedkontoret vårt i Kansas City i Missouri har vi denne lille arbeidsgruppen for fjernarbeid.
Vi er alle opptatt av å sørge for at vi fortsatt føler oss knyttet til kontoret, at vi identifiserer hvilke forbedringer og endringer som må gjøres, og at vi fortsatt kan bidra til kulturen – og at kulturen fortsatt kan støtte oss – selv om vi ikke er under samme tak. Det har vært morsomt. Det er en ny utfordring for meg. Det utfordrer hvordan jeg tenker på arbeidsdisiplin. Jeg trodde alltid at jeg hadde god arbeidsdisiplin, men når du ser deg rundt og tenker: «Jeg har virkelig lyst til å sette på den klesvasken», og du faktisk kan gjøre det, lærer du å si nei til slike distraksjoner.
Ben Aston:
Ingen mer klesvask.
Alexa Huston:
Nei, nettopp. Ingen klesvask i 2019.
Ben Aston:
Hva er de tre tingene arbeidsgruppen din gjør? Jeg kom på tre, men du kan kanskje komme på hundre. Hva vil du si til folk som går over til å bygge et eksternt team, eller som har vært samlokalisert og blir eksterne? Nevn gjerne tre ting du har opplevd som mest virkningsfulle, og som kan endre effektiviteten eller følelsen av tilhørighet til det samlokaliserte teamet.
Alexa Huston:
Det er et godt spørsmål. Én ting jeg virkelig har likt – og dette er veldig grunnleggende – er å sette av tid hver uke til å snakke med folk om ting som ikke handler om jobb. Jeg savner virkelig noen gode venner som jeg jobbet sammen med i tre år, men som jeg har flyttet fra. Det er lett å miste kontakten når vi ikke jobber med de samme prosjektene eller i de samme teamene. Den eneste grunnen til at jeg tidligere snakket så mye med dem, var at de var vennene mine og satt nær meg. Nå som jeg har flyttet, snakker jeg med dem på Slack eller har videosamtaler for å høre hvordan livet går. Det har gjort en stor forskjell for følelsen av fortsatt å være en del av familien.
Ben Aston:
Ja.
Alexa Huston:
Det har altså vært viktig å sette av tid til uformelle samtaler med de menneskene du ønsker å snakke med. Og med alle – nye teammedlemmer, folk som begynner, og så videre. En annen ting er noe vi nettopp gjorde, og som var veldig nyttig. Vi har brukt Mural eller RealTime Board i de eksterne møtene våre. Det fungerer omtrent som en digital tavle. Det har vært veldig bra for å skape interaktive møter når du sitter foran en datamaskin. Du kan fortsatt lage små lapper, stemme over ting og flytte elementer rundt på tavlen sammen. Det har vært veldig nyttig.
Ben Aston:
Og det heter Mural?
Alexa Huston:
Og den siste tingen … ja, Mural. M-U-R-A-L. RealTime Board er et annet alternativ. Det siste tipset mitt for fjernarbeid er å være villig til å skape det vi kaller en underkultur – en egen underkultur for fjernarbeid. Vi har en fantastisk kultur som vi har bygget internt, det jeg igjen vil kalle hovedkontoret. Men det føles annerledes når du ikke lenger er på kontoret og kobler deg til fra datamaskinen hver dag. Derfor har vi som eksternt team forsøkt å skape en underkultur der vi også samles og finner måter å få personlighetene våre inn i hverdagen på, selv om vi ikke er på kontoret. Vi har ikke landet på noe konkret ennå, men vi har alle snakket om at vi ønsker å skape vår egen lille kultur som støtter de større verdiene og det overordnede oppdraget Crema har.
Ben Aston:
Ja. Jeg synes fjernarbeid er en egen ferdighet. Særlig når du ikke får den ansikt-til-ansikt-tiden med folk. Som du sier, er det svært verdifullt å sjekke inn med folk utenom jobben bare for å snakke litt. Men da bygger du på relasjoner du hadde fra før. I en situasjon jeg har vært i, har jeg prøvd å bli kjent med folk for første gang eksternt. Det er vanskelig å utvikle en kultur når alle jobber eksternt og folk befinner seg i ulike tidssoner. Jeg synes det krever mye.
Alexa Huston:
Ja, det gjør det. Det er ingen liten oppgave. Hvis alle er engasjerte og ser muligheten til å eksperimentere med ulike verktøy, bruker vi også AppearIn. Det er en plattform for folk som ønsker å vises på skjermen og være synlige. Det har også vært nyttig. Men du har rett: Jeg kan bygge på de tre årene jeg jobbet med disse menneskene, men jeg vet at det ikke alltid er tilfelle. Og dette vil fortsette å endre seg etter hvert som vi får flere ansatte. Vi vokser mye, og bare forrige uke begynte tre nye personer. Jeg sendte dem Slack-meldinger og skrev: «Hei, jeg heter Alexa. Jeg jobber sammen med deg, men jeg vet ikke når jeg får se deg. Her er litt om meg – jeg vil gjerne vite mer om deg.»
Ben Aston:
Ja.
Alexa Huston:
«La oss finne tid til å snakke.»
Ben Aston:
Ja. Flott. Lykke til med det. Jeg vil gå videre til temaet jeg introduserte i begynnelsen, nemlig sprintplanleggingsmøter. Alexa har skrevet et grundig innlegg som går gjennom hele prosessen og hvordan vi kan gjøre dette. Som jeg sa i innledningen, tror jeg den virkelige utfordringen er at vi alle vet at sprintplanlegging er riktig å gjøre, men at det faktisk kan være utrolig krevende å gjøre det riktig og effektivt. La oss begynne med dem som ikke har lest innlegget ennå: Hva er sprintplanlegging, og hvorfor er det viktig?
Alexa Huston:
Det kommer fra Scrum-metodikken. Det er en av seremoniene eller møtene dere bør ha. Men jeg mener at alle kan bruke sprintplanlegging hvis dere i praksis organiserer arbeidet i sprinter, altså perioder der arbeidet begynner og avsluttes. Sprintplanleggingen skal besvare spørsmålet: «Hva kan vi levere i neste sprint, og hvordan kan vi gjennomføre dette arbeidet?» Dette er to svært viktige spørsmål som ofte krever at mange mennesker samarbeider for å finne svarene. Sprintplanleggingsmøtet er tidspunktet for å gjøre dette. Vi kommer sannsynligvis til å snakke mer om det senere, men det kreves mye forarbeid. Hvis du ikke setter av tid til å forberede sprintplanleggingsmøtet, hjelper det egentlig ikke. Det kan gjøre ting mer rotete.
Vi skal derfor snakke om noen måter å forberede seg på, slik at du er på rett spor før du sier: «Ja, dette kan vi gjøre. Og slik skal vi få det gjort.»
Ben Aston:
Flott. En av tingene du skriver om i innlegget, er å skape en definisjon av den arbeidsmengden vi skal begynne på de neste ukene – for eksempel en sprint på to uker. Du snakker om å gi dette en tydelig definisjon, slik at det ikke bare blir en tilfeldig samling oppgaver. Du kan for eksempel definere et sprintmål: Ved slutten av sprinten ønsker vi å ha levert en form for verdi, noe som betyr noe for kunden, og som tar oss et skritt videre.
Men det jeg ofte har opplevd, særlig i begynnelsen av et prosjekt, er at det er vanskelig å komme frem til et meningsfylt mål når man bygger noe fra grunnen av. Jeg kan forstå det senere i utviklingen, når produktet allerede finnes og man bare forbedrer det trinnvis. Men hvordan finner man et meningsfylt sprintmål mens man bygger produktet for første gang?
Alexa Huston:
Du har rett. Det kan være krevende, særlig i starten, når du ikke har mye erfaring å bygge på – verken med produktet eller som team. En ting ved sprintplanlegging er at den blir bedre jo mer modent teamet er. Modenhet kan bety hvor lenge dere har jobbet sammen, eller hvor lenge dere har jobbet med produktet. I begynnelsen har du ikke den fordelen. Derfor må du være ærlig med folk. Det hjelper om du har litt støtte – kanskje kan du spille rollen som den snille og den strenge sammen med produkteieren.
I praksis må du få teamet til å spørre: «Hva sier magefølelsen? Hvor mye tror vi at vi på en rimelig og realistisk måte kan få gjort?» Vi kan nok alle være enige om at noen overforplikter seg, mens andre blir nervøse og underforplikter seg. Noe som har hjulpet meg, særlig i de tidlige fasene av sprintplanleggingen, er å be teamet identifisere hvilken historie som er minst og enklest, og hvilken som er mest kompleks og vanskeligst, blant historiene dere vurderer for neste sprint. Bruk disse som sammenligningspunkter i samtalen. Når dere vurderer en oppgave, kan dere spørre om den kan sammenlignes med den aller minste eller den aller største arbeidsmengden.
Over tid bør samtalen hjelpe dere med å sette noen rammer. Fortsett å spørre teamet: «Er dere enige?» Hvis ikke, må du sørge for at folk får mulighet til å si hva de mener og komme med perspektivene sine. Denne delen av prosjektet kan være vanskelig fordi folk kan nøle med å ta opp bekymringer. Forhåpentligvis klarer du å skape et miljø der de føler seg trygge nok til å dele dem. Sjekk derfor jevnlig inn og spør: «Er alle enige? Er alle enige her? Bør vi gå videre?»
Ellers kan du gå glipp av et perspektiv som kunne ha endret planen. Det handler om å stoppe opp underveis og spørre: «Føles dette riktig? Er alle enige?»
Ben Aston:
Ja. Jeg opplever ofte at det finnes en spenning mellom utviklingsteamets grunner til å være begeistret for prosjektet og produkteierens grunner til å være begeistret for det. Hvordan skaper du samsvar og oppslutning? Hvordan får du teamet med deg og på linje med produkteierens perspektiv på hva som vil skape mest verdi?
Alexa Huston:
Jeg har et par ting som har hjulpet. Det ene er å lage en visjonserklæring for prosjektet. Ha den synlig under møtet – helst alltid synlig – for eksempel skrevet på tavlen eller vist på skjermen. Da kan alle raskt se på den og si: «Dette er formålet. Det er derfor vi gjør dette.» Du har rett i at utviklere, designere og produkteieren kan ha ulike motivasjoner. Men hvis alle kan se opp og si: «Det er derfor vi gjør dette», hjelper det med å skape en felles forståelse.
En annen ting jeg har gjort, siden jeg ikke er teknisk av yrke, er å gjenta det jeg hører på en svært enkel måte. Det er den eneste måten jeg kan formulere det på. Når folk snakker, særlig om den tekniske oppbyggingen eller bestemte hensyn knyttet til brukeropplevelsen, bør du stoppe opp hvis du ikke merker at alle er på linje. Gjenta det på en måte som gjør at du kan spørre: «Er det dette vi snakker om? Er det virkelig dette som er målet?» Det kan vise seg at du har forstått det riktig, eller det kan starte en samtale om at dere faktisk ikke er enige. Da kan dere sørge for at dere kommer på samme side. Du fungerer på en måte som megler og forenkler saken slik at alle forstår den likt.
Ben Aston:
Jeg tror mye av formålet med det vi prøver å gjøre her – å skape samsvar og oppslutning – handler om definisjonen vi skaper gjennom planleggingen før møtet. Hvis vi bare lar selve møtet være stedet der vi prøver å etablere denne visjonen og dette målet, uten å ha snakket om det med teamet på forhånd, kan det bli ganske krevende. Men hvis vi har rukket å snakke med folk på forhånd, kan det hjelpe mye. Du kan for eksempel spørre en utvikler: «I neste sprint tenker jeg på dette – høres det bra ut?» Slike uformelle samtaler kan være spesielt nyttige når du har et vanskelig teammedlem som mener at han eller hun vet best, eller har en annen idé om hvilken retning ting bør ta.
Alexa Huston:
Ja, det stemmer. Det ironiske med sprintplanlegging er at den bare går bra hvis du planlegger før sprintplanleggingen. Du må sette av tid til å bearbeide arbeidslisten, sørge for at produkteieren har gjort grundig arbeid med å hente inn nesten to sprinter med oppgaver, og sørge for at alt er klart. Det krever mest innsats å komme til et punkt der du føler deg forberedt til sprintplanleggingen. Det er ikke enkelt. Hvis noen sier at det er enkelt, må de være en trollmann, for det finnes ingen annen forklaring. Det er krevende, det tar tid og innsats, og mange har for lite kapasitet til å gjøre det skikkelig.
Forhåpentligvis har produkteieren og du som prosjektleder nok tid til å bearbeide arbeidslisten sammen med kunden. Arbeidslisten inneholder ikke bare brukerhistorier og funksjoner, men også feil, tilbakemeldinger fra interessenter, tilbakemeldinger fra kunder og en rekke andre ting som må med fordi alt er en del av produktet i arbeid. Hvis det ikke er satt av tid til å forberede sprintplanleggingsmøtet, kommer dere til å gå inn i møtet uten nok tid til å gå gjennom og estimere alt, og uten mulighet til å gå derfra og si: «Dette skal vi gjøre, og slik skal vi gjøre det.»
Dere kommer til å gå gjennom to historier og så må du si: «Jeg må gå.» Dere får aldri nok tid.
Ben Aston:
Ja.
Alexa Huston:
Så det kan være svært krevende.
Ben Aston:
Når dere er midt i en aktiv sprint, hvordan forbereder dere arbeidslisten? Tanken er at selve sprintplanleggingsmøtet skal starte med historier som allerede er godt bearbeidet: De er tydelig definert, har akseptansekriterier, og ferdigdefinisjonen er oppdatert ved behov. De er på en eller annen måte størrelsesestimert, slik at dere vet omtrent om det er verdt å vurdere dem for sprinten. Hvem gjør estimeringen og har disse samtalene mens sprinten pågår? Det bør vel være teamet?
Alexa Huston:
Jo.
Ben Aston:
Men teamet er midt i en aktiv sprint. Hvordan har du håndtert dette på en god måte?
Alexa Huston:
Det er et godt poeng. Når sprintplanleggingen er over, bør teamet arbeide effektivt med oppgavene sine. Men det finnes også et forberedelseselement du kanskje bør ta hensyn til når du lager sprintmålet og fastsetter forpliktelsen. Hvis du vet at du trenger litt mer tid fra teamet til å hjelpe med neste sprint, bør du ta det opp i møtet og kanskje justere hvor mye dere er villige til å ta på dere. Du trenger teamets innspill for å sikre at neste sprint blir god. Det er litt smertefullt og føles som en uendelig syklus, fordi folk ikke kan gjøre begge deler hele tiden. Teamet må arbeide med sprinten og produktet etter hvert som det utvikler seg.
Men du trenger også innspillene deres for å vite hva som kommer. For å svare på spørsmålet ditt: Det jeg har erfart, er at det i stor grad ligger hos produkteieren og prosjektlederen å samarbeide med kunden og interessentene i bakgrunnen, mens teamet hovedsakelig fokuserer på å utvikle, designe og teste produktet. Sett likevel av korte tidsperioder når det er mulig. Det kan være etter det daglige statusmøtet. Si: «Hei, vi trenger virkelig å snakke om dette i 15 minutter. Jeg har bare noen få spørsmål om denne arbeidsoppgaven før du begynner på dagen.» Finn tidspunkter der folk ikke er helt oppslukt av noe annet. Det gjør samtalen mer effektiv og gjør at de raskere kan gå tilbake til arbeidet.
Det krever litt empati og intuisjon å vite når du kan be folk snakke om dette. Men etter hvert som produktet og sprinten utvikler seg, vil du finne muligheter til å spørre: «Kan jeg trekke deg bort i ti minutter for å snakke om dette, eller kan vi ha et møte på 30 minutter? Jeg vil bare sørge for at alt er på plass.»
Ben Aston:
Én ting jeg har hatt nytte av, er å justere sprintplanen litt. Du kan legge inn et lite mellomrom, eller begynne med kodefrys eller en tidlig lansering mot slutten av sprinten, slik at du får en halv dag med uallokert tid før sprintplanleggingsmøtet. Hvis du for eksempel har en omtrentlig syklus på to uker, kan du fryse koden onsdag i den andre uken, distribuere eller lansere onsdag kveld eller torsdag morgen, bruke torsdagen til å rydde opp i løse tråder, og ha tom tid torsdag ettermiddag. Sprintplanleggingen kan da være fredag morgen, slik at du har en halv dag i planen. Det forkorter sprintsyklusen litt, men gir folk tid til å snakke om ting og undersøke dem før møtet. Det kan være en annen måte å gjøre det på.
Alexa Huston:
Ja, den ideen liker jeg veldig godt.
Ben Aston:
Ulempen er at sprinten blir litt kortere. Men det er en måte å gjøre det på, særlig når prosjektet er uklart og folk ellers ville kommet inn i sprintplanleggingsmøtet og sagt: «Hva er dette? Hvorfor har vi ikke snakket om det ennå?» Da kan dere si: «Vi snakker om det nå.» Hvis du bare har to eller fire timer til å planlegge to ukers arbeid, kan det være en stor oppgave. Derfor er det svært viktig å gi seg selv nok tid til å gjøre det effektivt. Mange som skal gjennomføre et Scrum-prosjekt tenker: «Det er agilt, det er Scrum. Vi trenger ikke så mye planlegging.» Hele poenget er vel at vi tar ting som de kommer. Men i virkeligheten trenger du enda mer planlegging fordi du arbeider i toukerssykluser. Disse syklusene må planlegges skikkelig. Du kan ikke bare begynne å utvikle uten videre. Det er en misforståelse at agil utvikling, Scrum og sprinter betyr at du ikke trenger å planlegge særlig mye. Det krever faktisk mye planlegging.
Alexa Huston:
Ja, det stemmer. Jeg tror noen ser på agil arbeidsmetodikk som noe uten dokumentasjon eller kravarbeid, men det er heller ikke riktig. Du setter kanskje bare av mindre tid til det. Det finnes fortsatt et forberedelseselement som ikke kan ignoreres, uansett hvilken metodikk du bruker. Du får ganske enkelt ikke resultater uten en plan. Og du må være villig til å endre planen hvis den ikke fungerer. Det vet du ikke før du har gjennomført en hel sprint og deretter har en retrospektiv der du spør: «Var dette bra? Var det ikke bra? Hvordan kan vi forbedre oss videre?» Det morsomme med å lage en plan er at du også må være komfortabel med at du ikke følger den slavisk. Men du må lage den. Det må skje.
Ben Aston:
Ja, det er en pågående prosess. Det er ikke en engangsaktivitet. Det er noe du hele tiden må korrigere og endre retning på. I selve møtet prøver vi å komme til et punkt der vi gjennomgår elementene i arbeidslisten, bestemmer sprintmålet sammen med teamet, skaper samsvar og oppslutning, og fastsetter retningen for neste sprint. Vi går gjennom arbeidslisten, flytter oppgaver inn i sprintens arbeidsliste og sørger for at alle forstår dem og at de er riktig størrelsesestimert. Deretter prøver vi å få teamet til å bli enige om hva de skal levere ved slutten av sprinten – det som utgjør sprintmålet.
Det som ofte er krevende, og som igjen handler om planlegging og forberedelse, er at teamet ikke alltid har fått tid til å gjennomgå materialet ordentlig. Så ender vi i sprintplanleggingsmøtet etter fire timer med bare et par størrelsesestimerte og avtalte brukerhistorier, mens vi har to ukers arbeid å planlegge. Da blir oppgavene ofte gjort om til tekniske undersøkelser: «Vi setter av en dag til å undersøke denne nye funksjonen som vi ennå ikke vet hvordan vi skal estimere.» Har du noen tips til hvordan man kan gjøre sprintplanleggingsmøtet raskere, slik at man ikke blir sittende fast i alle detaljene og ender opp med for lite arbeid planlagt?
Alexa Huston:
Ja, det er et vanlig problem. Prøv å tenke taktisk. Én ting jeg har gjort, er å minne folk på at sprintplanleggingen nærmer seg. Ikke på en irriterende måte, men ved å oppfordre dem til å gjennomgå det som er gjort tilgjengelig for dem. Det er sannsynligvis mye støy. Utviklere har ofte mye å gjøre, enten de jobber med ett eller flere produkter. Jeg prøver derfor å kommunisere tydelig: «Sprintplanleggingsmøtet vårt er på tirsdag eller onsdag. Sørg for å sette av tid til å stille meg spørsmål eller gå gjennom historiene vi skal snakke om.»
For du har rett. Hvis dere kommer inn i møtet og bare må slite dere gjennom alle spørsmålene uten å komme videre, har dere dessverre kastet bort flere timer som ikke kan tas tilbake. Jeg vet ikke hvordan det har vært i din erfaring, men har du noen gang måttet planlegge et nytt sprintplanleggingsmøte?
Ben Aston:
Ja, jeg har måttet forlenge sprintplanleggingen. I et dårligere scenario, når det ikke har vært mulig, har vi i stedet for en sprint på to uker måttet si at denne syklusen blir en sprint på én uke, fordi vi ikke hadde planlagt to ukers arbeid. Men jeg mener det er viktig å ikke hoppe over planleggingen og si at historiene er som de er, og at man bare får finne ut av resten underveis. Hele poenget med sprintplanleggingsmøtet er å definere et mål, levere verdi ved slutten av sprinten, bli enige om størrelsen på historiene og sørge for at teamet har en rimelig mengde arbeid.
Dette er viktige trinn. Hvis vi fyller sprinten med hva som helst, vil vi komme til slutten av sprinten og bare ha ferdigstilt et par historier. Teamet blir raskt demotivert og føler at de mislykkes fordi de ikke får til noe. Scrum fungerer når vi setter mål, når målene og teamet føler fremdrift. Den typen suksess hjelper prosjektet fremover.
Alexa Huston:
Jeg er enig. En annen ting er at hvis du oppdager at noen på teamet er ekstra tydelige på at ting er uklare, eller at de prøver å fylle hullene, kan du spørre om de vil delta i møtene før planleggingen også. I min erfaring har dette vært valgfritt for utviklere. Men jeg har vært i et prosjekt der én av utviklerne var svært god på et bestemt teknisk problem vi hadde. Jeg la merke til det når vi snakket om problemet og når vi var i sprintplanleggingen. Etterpå spurte jeg ham: «Vil du delta i noen av møtene før planleggingen? Du trenger ikke forplikte deg hvis det går utover det andre arbeidet ditt, og det er viktig. Men vil du hjelpe oss med å bearbeide ting på forhånd på vegne av utviklingsteamet?» Han fungerte som representant for teamet.
Det fungerte godt i akkurat den situasjonen. Poenget mitt er at hvis du finner noen som stadig fyller hullene eller sier fra, kan du spørre om de vil være bindeledd på forhånd. Det kan hjelpe.
Ben Aston:
Det er mye bra i artikkelen din, så jeg oppfordrer virkelig folk til å lese den. Det viktigste jeg tar med meg, er at sprintplanleggingsmøtet er viktig i seg selv, men at forberedelsene før møtet sannsynligvis er enda viktigere. Vi kan ikke tro at vi bare kan gå inn i møtet og planlegge to ukers arbeid på fire eller to timer. Det kommer ikke til å skje. Sørg for å sette av tid til forarbeidet før sprintplanleggingsmøtet, så er det mye større sjanse for at det lykkes.
Alexa, tusen takk for at du ble med oss. Det har vært flott å ha deg her.
Alexa Huston:
Takk for at jeg fikk komme.
Ben Aston:
Som en av våre DPM-eksperter, som jeg nevnte tidligere, skal Alexa delta i vårt kommende kurs. Det starter i februar og heter Mastering Digital Project Management. Hvis du ikke vet hva jeg snakker om, men vet at du trenger opplæring i prosjektledelse, bør du sjekke det ut. Det er et intensivkurs på sju uker som inkluderer interaktive videoleksjoner, webinarer, oppgaver, gruppediskusjoner og mulighet for veiledning. Gå til DPM.com og meld deg på før kurset blir fullt. Hvis du vil bidra til samtalen, kan du kommentere på innlegget og gå til ressursdelen på digitalprojectmanager.com for å bli med i Slack-teamet vårt. Der finner du mange interessante samtaler om alt som handler om digitalt arbeid og prosjektledelse. Hvis du likte det du hørte i dag, kan du abonnere.
Bruk et par minutter på å skrive en ærlig anmeldelse av DPM-podkasten på iTunes. Vurderinger og anmeldelser er svært nyttige, så vær snill og gjør det. Det hjelper oss med å tilpasse podkasten og gjøre den bedre. Det setter vi stor pris på. Men frem til neste gang: Takk for at du lyttet.
