Sådan planlægger du et agilt sprint (med Alexa Huston fra Crema)

Læs transskriptionen:

Vi afprøver et program til at transskribere vores podcasts. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston:

Velkommen til DPM-podcasten, hvor vi går ud over teorien for at give ekspertråd til projektledere, så de kan skabe bedre digitale projekter. Tak fordi du lytter med. Jeg er Ben Aston, grundlægger af The Digital Project Manager.

Vær ærlig. Forlader du dine sprintplanlægningsmøder med en veldefineret og aftalt backlog, der indeholder veldefinerede og estimerede opgaver, og med fuld tillid til, at dit kommende sprint kommer til at forløbe præcis efter planen? Det tænkte jeg nok.

Selvom vi alle ved, at sprintplanlægning er en god idé og afgørende for projektets succes, er det svært. Det er svært at gøre rigtigt, fordi vi forsøger at reducere uklarhed, skabe en fælles forståelse i teamet og nå frem til en form for enighed. Det er altid vanskeligt.

Hvordan kan du starte dine sprints rigtigt og udføre den planlægning, der faktisk er nødvendig for at få dit sprint i den rigtige retning – i stedet for endnu en fejlslagen start, der kræver endnu et planlægningsmøde? Som projektledere er det vores opgave at få dette til at fungere. Men hvordan gør vi det? Det handler dagens podcast om, så lyt videre for at finde ud af, hvordan du kan få dit sprint godt fra start.

Min særlige gæst i dag er Alexa Huston fra Crema. Alexa er tidligere digital projektleder og arbejder nu med nye forretninger. Denne udfordring kender hun særdeles godt. Alexa er en af vores faste projektledelseseksperter på Digital Project Manager School. Hvis du vil lære mere fra hende, kan du se nærmere på vores Master of Digital Project Management School, hvor hun medvirker. Gå til DPMSchool.com for at få mere at vide. Hej, Alexa.

Alexa Huston:

Hej, Ben.

Ben Aston:

Velkommen til 2019 – vores første samtale i 2019. Hvad er dine store mål for 2019, Alexa?

Alexa Huston:

Det er et omfattende spørgsmål. Jeg tænkte faktisk over det nytårsaften og skrev nogle ting ned. Jeg er ikke den store tilhænger af nytårsforsætter, fordi jeg hele tiden sætter mig mål. Men jeg vil gerne have, at 2019 bliver året, hvor jeg lærer at slappe af. Jeg har en tendens til at være lidt af en travl person, så jeg forsøger at finde flere muligheder for at træde et skridt tilbage, meditere og være mere til stede.

Ben Aston:

Og hvor mange gange i løbet af den seneste uge har du formået det?

Alexa Huston:

Jeg vil helst ikke tale om mine succeser.

Ben Aston:

Det er vigtigt at holde hinanden ansvarlige.

Alexa Huston:

Ja.

Ben Aston:

Det er godt. Jeg har lagt mærke til, at nytårsforsætter er på vej ud, mens 30-dagesudfordringer er på vej ind.

Alexa Huston:

De er meget populære. Mit fitnesscenter laver 30-dagesudfordringer.

Ben Aston:

Ja.

Alexa Huston:

Det er også en tendens, jeg har lagt mærke til. På en måde virker det bedre. Det er lidt mindre skræmmende, hvis det deles op månedsvis.

Ben Aston:

Månedsvis, ja. Så måske kan du meditere i 30 dage næste måned.

Alexa Huston:

Måske. Det kunne jeg.

Ben Aston:

Du kan altid-

Alexa Huston:

Det er for sent at begynde i januar, men måske i februar.

Ben Aston:

Held og lykke med det. Jeg forsøger stadig at definere mine egne mål. Jeg besluttede, at jeg gerne ville have, at de skulle være rigtige. Jeg mener, vi er en uge inde i året, men jeg vil ikke forpligte mig til noget, som jeg ikke kan holde, alt for tidligt. Så jeg arbejder stadig på det. Men ud over dine mål, hvad er der så ellers nyt? Hvad sker der hos dig? Fortæl os om Crema og om, hvad I har planlagt i år.

Alexa Huston:

Det er et godt spørgsmål. Crema vokser helt vildt. Personligt er jeg arbejdsmæssigt ved at vænne mig til at arbejde fuldtid på afstand for første gang. Vores team vokser, og jeg flyttede til Arizona i slutningen af 2018. Heldigvis kunne jeg fortsætte som medlem af Crema-teamet. Så jeg vænner mig til livet på afstand, og heldigvis har alle hos Crema været meget støttende. Vi har faktisk et par andre medarbejdere, der arbejder distribueret. Så mellem dem, mig og et par personer på vores hovedkontor i Kansas City, Missouri, har vi en lille arbejdsgruppe for fjernarbejde.

Vi er alle engagerede i at sikre, at vi stadig føler os forbundet med kontoret. Vi identificerer, hvilke forbedringer og ændringer der er nødvendige, og sørger for, at vi stadig kan bidrage til kulturen, og at kulturen stadig kan understøtte os, selvom vi ikke er under samme tag. Det har været sjovt. Det har været en ny udfordring for mig. Det udfordrer min måde at tænke på arbejdsdisciplin. Jeg troede altid, at jeg havde styr på den, men når man ser sig omkring og tænker: “Jeg ville virkelig gerne vaske den bunke tøj, og det kan jeg jo,” så lærer man at sige nej til den slags distraktioner.

Ben Aston:

Ikke mere vasketøj.

Alexa Huston:

Nej, præcis. Intet vasketøj i 2019.

Ben Aston:

Hvad er så de tre ting, som din arbejdsgruppe gør? Jeg kom selv på tre, men du kunne måske komme med en liste på 100. Hvad vil du sige til personer, der er ved at opbygge et fjernteam, eller som går fra at være samlet til at arbejde på afstand? Fortæl os måske om tre ting, som du har fundet mest effektive, og som efter din mening kan forbedre effektiviteten eller følelsen af at være forbundet med det samlede team.

Alexa Huston:

Det er et godt spørgsmål. En ting, jeg virkelig har kunnet lide, og det er helt grundlæggende, er at afsætte tid hver uge til at tale med folk om andet end arbejde. Jeg savner virkelig nogle gode venner, som jeg arbejdede sammen med i tre år, og som jeg er flyttet fra. Det er nemt, for vi arbejder ikke på de samme projekter eller i de samme teams, og den eneste grund til, at jeg egentlig talte så meget med dem før, var, at de var mine venner, og at vi sad tæt på hinanden. Nu hvor jeg er væk, taler jeg med dem over Slack eller via videoopkald og følger op på livet uden for arbejdet. Det har gjort en enorm forskel for min følelse af stadig at være en del af familien.

Ben Aston:

Ja.

Alexa Huston:

Det har været en god ting. Bare det at afsætte tid til uformelle samtaler ved vandkøleren med de mennesker, man gerne vil tale med. Og med alle – nye teammedlemmer, folk der starter, og den slags. En anden ting er noget, vi netop har gjort, og som var meget nyttigt. Vi har brugt Mural eller RealTime Board til vores fjernmøder, så det fungerer lidt som en digital tavle. Det har været virkelig godt til at skabe interaktive møder, når man sidder og kigger på en computerskærm. Man kan stadig lave små post-it-sedler, stemme om ting og flytte rundt på elementer på tavlen sammen. Det har været rigtig smart.

Ben Aston:

Og det hedder Mural?

Alexa Huston:

Og den sidste ting … ja, Mural. M-U-R-A-L. RealTime Board er en anden mulighed. Mit sidste råd om fjernarbejde er at være villig til at skabe det, vi kalder en subkultur – en subkultur for fjernarbejde. Vi har en fantastisk kultur, som vi har opbygget internt; jeg kalder det hovedkontoret. Men det føles lidt anderledes, det gør det. Når man ikke længere er på kontoret og hver dag har kontakt fra sin computer. Derfor har vi som fjernteam forsøgt at skabe denne subkultur, hvor vi også mødes og finder måder at tilføre vores personligheder til hverdagen på, selvom vi ikke er på kontoret. Der er ikke kommet noget konkret ud af det endnu, men vi har alle talt om, at vi gerne vil skabe vores egen lille kultur, som understøtter de større værdier og den mission, Crema også har.

Ben Aston:

Ja. Jeg synes, at fjernarbejde kræver et særligt talent. Især når man ikke får den ansigt-til-ansigt-tid med folk. Som du siger, er det meget værdifuldt faktisk at tjekke ind med mennesker uden for arbejdet og bare tale med dem, men du trækker på relationer, du allerede havde. I den situation, jeg har oplevet, har udfordringen været at møde mennesker for første gang på afstand og forsøge at udvikle en kultur, når alle arbejder på afstand og befinder sig i forskellige tidszoner. Det kræver virkelig et stort talent.

Alexa Huston:

Ja, det gør det. Det er bestemt ikke nogen lille opgave. Men hvis alle er engagerede og ser mulighederne i at eksperimentere med forskellige værktøjer, bruger vi også AppearIn, som er en platform for folk, der gerne vil være synlige på skærmen. Det har også været nyttigt. Men du har ret: Jeg kan trække på de tre år, jeg har arbejdet sammen med disse mennesker, men jeg ved, at det ikke altid er tilfældet. Og det vil fortsat ændre sig, efterhånden som vi ansætter flere og flere, fordi vi vokser meget. I sidste uge begyndte tre nye personer, og jeg sendte dem bare Slack-beskeder. Jeg skrev: “Hej, jeg hedder Alexa. Jeg arbejder sammen med dig, men jeg ved ikke, hvornår jeg ser dig. Her er lidt om mig – jeg vil gerne vide noget om dig.”

Ben Aston:

Ja.

Alexa Huston:

“Lad os finde tid til at tale sammen.”

Ben Aston:

Ja. Godt. Held og lykke med det. Jeg vil gerne gå videre til det emne, jeg introducerede i begyndelsen, nemlig sprintplanlægningsmøder. Alexa har skrevet et virkelig grundigt indlæg, der gennemgår hele processen og forklarer, hvordan vi kan gøre det. Som jeg sagde i indledningen, tror jeg, at den virkelige udfordring er, at vi alle ved, at sprintplanlægning er det rigtige at gøre, men at det kan være utroligt svært faktisk at gøre det rigtigt og effektivt. Lad os begynde med dem, der endnu ikke har læst indlægget. Hvad er sprintplanlægning, og hvorfor er det vigtigt?

Alexa Huston:

Det kommer fra Scrum-metoden og er en af de ceremonier eller møder, man bør afholde. Men jeg mener, at alle kan bruge sprintplanlægning, hvis man grundlæggende forpligter sig til sprints med arbejde, altså perioder hvor arbejdet begynder og slutter. Formålet er at besvare spørgsmålet: “Hvad kan vi levere i det næste sprint, og hvordan kan vi udføre arbejdet?” Det er to meget vigtige spørgsmål, som ofte kræver, at mange mennesker arbejder sammen for at finde svarene. Sprintplanlægningsmødet er tidspunktet, hvor man gør det. Vi kommer sikkert til at tale mere om dette senere, men der ligger så meget forberedelse bag, at mødet ikke hjælper ret meget, hvis man ikke afsætter tid til at forberede sig. Det kan faktisk gøre tingene mere rodede.

Så vi taler om nogle måder, hvorpå du kan forberede dig og være på rette spor, før du siger: “Ja, det kan vi gøre. Og sådan får vi det gjort.”

Ben Aston:

Godt. Noget af det, du taler om i indlægget, er at skabe en definition af den arbejdsblok, vi skal til at begynde på i de næste par uger – lad os sige et sprint på to uger. Du taler om at skabe en definition, så det ikke bare er en bunke arbejde. For eksempel at definere et sprintmål: Ved slutningen af dette sprint vil vi have leveret en form for værdi, noget der er værdifuldt for kunden, og som bringer os et skridt videre.

Men det, jeg ofte har oplevet, især i begyndelsen af et projekt, er, at det er svært at nå frem til et meningsfuldt mål, når man bygger noget fra bunden. Jeg kan forstå det senere i forløbet, når man er midt i udviklingen, produktet allerede findes, og man blot forbedrer det gradvist. Men hvordan finder man frem til et meningsfuldt sprintmål, mens man bygger produktet for første gang?

Alexa Huston:

Du har ret. Det kan være svært, især i starten, når man ikke har meget erfaring at trække på – hverken med produktet eller som team. En ting ved sprintplanlægning er, at den bliver bedre, jo mere modent et team er. Moden kan betyde, hvor længe man har arbejdet sammen, eller hvor længe man har arbejdet på produktet. I begyndelsen har man ikke den fordel. Derfor har jeg fundet ud af, at man er nødt til at være realistisk over for folk. Det hjælper, hvis man måske kan spille god og dårlig betjent sammen med produktejeren.

I bund og grund skal man presse teamet til at sige: “Hvad er jeres mavefornemmelse her? Hvor meget tror vi, at vi med rimelighed og realisme kan nå?” Vi kan vist alle blive enige om, at nogle mennesker måske forpligter sig til for meget, mens andre bliver nervøse og forpligter sig til for lidt. Noget, der har hjulpet mig, især i de tidlige stadier af sprintplanlægningen, er at få teamet til at identificere den mindste og nemmeste opgave blandt de historier, man vil overveje til det næste sprint, samt den mest komplekse og vanskeligste opgave. Brug dem som sammenligningspunkter i samtalen. Når man siger: “Okay, hvis vi også vil forpligte os til dette, kan vi så sammenligne det med enten det meget lille eller det meget store stykke arbejde?”

Med tiden bør samtalen hjælpe jer med at sætte nogle rammer. Og bliv ved med at spørge teamet: “Er I enige?” Hvis ikke, skal du sørge for at give folk mulighed for at sige deres mening og komme med deres perspektiver. Den del af projektet kan være vanskelig, fordi folk måske tøver med at nævne deres bekymringer. Forhåbentlig kan du skabe en situation, hvor de føler sig trygge nok til at dele dem. Tjek derfor ofte ind og spørg: “Er alle enige? Er alle enige her? Skal vi gå videre?”

Ellers risikerer du at gå glip af et perspektiv, der kunne ændre sprintet. Det handler om løbende at kontrollere samtalen og spørge: “Føles det rigtigt? Er alle enige?”

Ben Aston:

Ja. Jeg synes ofte, der er en vis spænding her. Udviklingsteamet kan være begejstret for projektet af en anden grund end produktejeren. Hvordan skaber man så fælles forståelse og opbakning? Jeg kan godt lide idéen om at tage teamet med undervejs og spørge: “Lyder det rigtigt? Er jeg på rette vej? Er det et rimeligt mål?” Men hvordan når man frem til det? Har du nogle råd til at få deres opbakning og få dem til at se tingene fra produktejerens perspektiv med hensyn til, hvad der skaber mest værdi?

Alexa Huston:

Ja, der er et par ting, som har hjulpet mig. Den ene er at skabe en form for projektvision. Sørg for, at den er synlig under mødet – og forhåbentlig altid. Skriv den på tavlen eller vis den på skærmen, så alle hurtigt kan se den og sige: “Okay, det er formålet. Det er derfor, vi gør det, vi gør.” Du har ret i, at udviklere, designere og produktejeren kan have forskellige motivationer. Men hvis alle kan kigge op og sige: “Det er derfor, vi gør det,” hjælper det med at skabe en fælles retning.

En anden ting, jeg har gjort, er at gentage det, jeg hører, på en meget enkel måde, fordi det er den eneste måde, jeg kan formulere det på. Når folk taler, især om den tekniske opbygning eller bestemte brugeroplevelsesmæssige overvejelser, kan man holde pause, hvis man ikke fornemmer, at der er enighed, og formulere det igen: “Er det det, vi taler om? Er det virkelig målet her?” Det kan vise sig at være rigtigt, eller det kan sætte gang i en samtale om, at I faktisk ikke er enige. Så kan I sikre jer, at I kommer på samme side. Man spiller altså en slags mæglerrolle og forenkler tingene, så alle er enige.

Ben Aston:

Jeg tror, det er en vigtig del af formålet med at skabe fælles forståelse og opbakning gennem den planlægning, vi laver før mødet. Hvis vi bare overlader det til selve mødet og forsøger at etablere denne vision og dette mål, uden at have talt med teamet om det på forhånd, kan det være meget udfordrende. Men hvis vi faktisk har haft mulighed for at tale med folk på forhånd, kan det virkelig gøre det lettere. Man kan for eksempel spørge en udvikler: “Til det næste sprint overvejer jeg dette – lyder det godt?” Den forudgående samtale kan hjælpe, når man har et vanskeligt teammedlem, som mener, at vedkommende ved bedre eller har en anden idé om, hvilken retning tingene bør tage.

Alexa Huston:

Ja, det er helt rigtigt. Det ironiske ved sprintplanlægning er, at den kun går godt, hvis man planlægger før sprintplanlægningen. Man skal afsætte tid til at pleje backloggen, sikre sig, at produktejeren har gjort sit forarbejde og næsten trukket to sprints arbejde ind, og at alt er klar. Det kræver mest vedholdenhed at nå til det punkt, hvor man føler sig forberedt til sprintplanlægningen. Det er ikke nemt. Hvis nogen siger, at det er nemt, må de være troldmænd, for der er ingen anden forklaring. Det er svært, det kræver tid og indsats, og mange mennesker har for meget at lave til at gøre det ordentligt.

Forhåbentlig har produktejeren og du som projektleder tid nok til at arbejde sammen med kunden om at pleje backloggen. Backloggen indeholder ikke kun brugerhistorier og funktioner, men også fejl, feedback fra interessenter, feedback fra kunder og en lang række andre ting, fordi alt dette er en del af det fungerende produkt. Hvis der ikke er afsat tid til at forberede sprintplanlægningsmødet, sker der det, at man går ind til mødet – selv hvis man har afsat to til fire timer – uden at have tid til at komme igennem alt, estimere alt og gå derfra med en klar forståelse af, hvad man skal gøre, og hvordan man skal gøre det.

Man når måske gennem to historier og tænker: “Jeg er nødt til at gå.” Man får aldrig tid nok.

Ben Aston:

Ja.

Alexa Huston:

Så det kan være virkelig svært.

Ben Aston:

Når man er i et aktivt sprint, hvordan forbereder man så backloggen? Ideen er, at sprintplanlægningsmødet allerede begynder med historier, der er rimeligt velplejede. De er definerede, har acceptkriterier, og definitionen af færdig er blevet opdateret, hvis det er nødvendigt. De er blevet estimeret på en eller anden måde, så vi nogenlunde ved, om det overhovedet er værd at overveje dem til sprintet. Hvordan gør man det, mens der foregår et aktivt sprint? Hvem gør det? Hvem estimerer og har disse samtaler? Det bør være teamet, ikke?

Alexa Huston:

Jo.

Ben Aston:

Men teamet er i gang med et aktivt sprint. Hvordan har du håndteret det med succes?

Alexa Huston:

Det er et meget præcist spørgsmål. Når sprintplanlægningen slutter, bør teamet være godt i gang med arbejdet. Men der er også et forberedelseselement, som man måske bør tage højde for, når man fastlægger sprintmålet og sin forpligtelse. Hvis du ved, at du får brug for lidt mere tid fra teamet til at hjælpe med det næste sprint, så tag det op på mødet og justér måske, hvor meget I vil påtage jer. Du får brug for folks input for at sikre, at det næste sprint bliver godt. Det er lidt smertefuldt og minder om en uendelig cyklus, fordi folk ikke kan gøre begge dele hele tiden. Teamet skal udføre arbejdet i sprintet på produktet, efterhånden som det udvikler sig.

Men du har brug for deres input for at forstå, hvad der kommer bagefter. For at svare på dit spørgsmål har jeg fundet ud af, at det i høj grad ligger hos produktejeren og projektlederen at sikre, at de arbejder sammen med kunden og interessenterne i baggrunden, mens teamet primært fokuserer på at udvikle, designe og teste produktet. Indbyg tidsrum, hvor I kan – måske efter det daglige statusmøde. Sig: “Vi er nødt til at tale om dette i 15 minutter. Jeg har bare nogle få spørgsmål til denne del af arbejdet, før I begynder på dagen.” Hvis du finder muligheder for at tale med folk, når de ikke er helt optaget af noget andet, bliver samtalen mere effektiv, og de kan hurtigere vende tilbage til arbejdet.

Det kræver en smule empati og intuition at vurdere, hvornår man kan bede folk om at tale om det. Men efterhånden som produktet og sprintet udvikler sig, vil du finde muligheder for at sige: “Må jeg tage dig væk i ti minutter og tale om dette, eller kan vi holde et møde på 30 minutter? Jeg vil bare sikre mig, at vi har styr på det hele.”

Ben Aston:

En ting, jeg har fundet nyttig, er at justere sprintplanen en smule. Man kan indføre et mellemrum eller gå i kodefrysning tidligt i sprintet, så man har måske en halv dag med ikke-allokeret tid før sprintplanlægningsmødet. Hvis man for eksempel har en nogenlunde to uger lang cyklus, laver man kodefrysning onsdag i den anden uge, implementerer onsdag aften eller torsdag morgen og bruger torsdagen på at afslutte løse ender. Torsdag eftermiddag er tom, og sprintplanlægningen er fredag morgen. Så er der en halv dag i planen. Det forkorter sprintcyklussen en smule, men giver tid til, at folk kan tale om ting og undersøge dem før sprintplanlægningsmødet. Det kan være en anden måde at gøre det på.

Alexa Huston:

Ja, den idé kan jeg virkelig godt lide.

Ben Aston:

Ulempen er bare, at sprintet bliver kortere. Men det er en måde at gøre det på – især når der er meget uklarhed i projektet, og folk risikerer at gå ind i sprintplanlægningen og spørge: “Hvad er det? Hvorfor har vi ikke talt om det endnu?” Så siger man: “Det taler vi om nu.” Hvis man kun har to eller fire timer til at planlægge to ugers arbejde, kan det være en stor opgave. Derfor er det vigtigt at give sig selv nok tid til at gøre det effektivt. Mange tror, at når de arbejder med et Scrum-projekt, så er det agilt og derfor ikke kræver meget planlægning.

Men virkeligheden er, at man skal planlægge endnu mere, fordi man arbejder i disse to ugers cyklusser. De to ugers cyklusser skal planlægges ordentligt. Man kan ikke bare begynde at udvikle, og der er en misforståelse om, at fordi man arbejder agilt med Scrum og sprints, behøver man ikke planlægge særlig meget. Faktisk kræver det meget planlægning.

Alexa Huston:

Ja, det er meget rigtigt. Nogle ser måske agil udvikling som noget, hvor der ikke findes dokumentation eller kravspecifikationer, men det er heller ikke sandt. Man bruger måske bare ikke lige så meget tid på det. Der er stadig et forberedelseselement, som ikke kan ignoreres, uanset hvilken metode man bruger. Man får ganske enkelt ikke resultater, medmindre man lægger en plan. Og man skal være villig til at ændre planen, hvis den ikke fungerer. Det ved man ikke, før man har gennemført et helt sprint og derefter holder et retrospektiv og spørger: “Var det godt? Var det ikke godt? Hvordan kan vi forbedre os fremover?” Det sjove ved at lave en plan er, at man også skal acceptere, at man måske ikke følger den. Men man er nødt til at lave den. Det skal ske.

Ben Aston:

Ja, det er løbende. Det er ikke en engangsaktivitet. Det er noget, man hele tiden skal korrigere og justere. I selve mødet forsøger vi at nå frem til et punkt, hvor vi gennemgår backlogelementerne, får teamet til at blive enige om sprintmålet, skaber fælles forståelse og opbakning og fastlægger retningen for det næste sprint. Vi gennemgår backloggen, flytter elementer ind i sprintbackloggen og sikrer, at alle forstår dem og har estimeret dem korrekt. Derefter forsøger vi at få teamet til at blive enige om, hvad de vil levere ved sprintets afslutning, så det understøtter sprintmålet.

En udfordring er, at teamet ofte ikke har haft mulighed for at gennemgå tingene ordentligt på forhånd. Så efter fire timer har vi måske kun fået estimeret og aftalt et par brugerhistorier, men vi har stadig to ugers arbejde, der skal planlægges. Derfor bliver tingene ofte lavet om til spikes: “Vi afsætter en tidsbegrænset periode til at undersøge det og bruger en dag på at se nærmere på den nye funktionalitet, som vi endnu ikke ved, hvordan vi skal estimere.” Har du nogle råd til at gøre sprintplanlægningen hurtigere, så man ikke drukner i alle detaljerne og ender med for lidt arbejde?

Alexa Huston:

Ja, det er et almindeligt problem. Prøv at tænke taktisk. En ting, jeg har gjort, lyder simpel: Mind folk om, at sprintplanlægningen nærmer sig – ikke på en irriterende måde, men ved at opfordre dem til at gennemgå det materiale, der er gjort tilgængeligt. Det er sandsynligvis meget støjende. Udviklere har meget at se til, uanset om man arbejder på ét eller flere produkter. Jeg forsøger bare at kommunikere: “Vi har sprintplanlægningsmøde tirsdag eller onsdag. Sørg for at afsætte tid til at stille mig spørgsmål eller gennemgå de historier, vi skal tale om.”

For du har ret. Hvis man kommer ind til mødet, og det viser sig at være en lang gennemgang af alle mulige spørgsmål uden at nå nogen vegne, har man desværre spildt flere timer, som man ikke får tilbage. Den tid er væk. Jeg ved ikke, om du har prøvet at planlægge et ekstra sprintplanlægningsmøde. Eller om du bare har sagt: “Okay, dette er det, vi forsøger at gøre.” Hvad har du gjort i din erfaring?

Ben Aston:

Jeg har været nødt til at forlænge sprintplanlægningen. I en dårlig situation, hvor det ikke var muligt, har vi i stedet for et sprint på to uger sagt: “Denne cyklus bliver et halvt eller et ugesprint,” fordi vi ikke havde arbejde nok til to uger. Men ja, det er vigtigt at have et ekstra planlægningsmøde. Man kan ikke bare springe planlægningen over og sige: “Historierne er historierne, så jeg finder bare på noget for jer.” Hele formålet med sprintplanlægningsmødet er at definere et mål, levere værdi ved sprintets afslutning, blive enige om estimeringen af historierne og sikre, at der er en rimelig mængde arbejde for teamet.

Det er vigtige trin. Hvis vi fylder sprintet med hvad som helst, når vi sprintets slutning, og kun nogle få historier er færdige. Teamet bliver hurtigt demotiveret og føler, at det fejler, fordi det ikke opnår noget. Scrum fungerer, når vi sætter mål, når målene og oplever fremdrift. Den succes hjælper virkelig projektet fremad.

Alexa Huston:

Det er jeg enig i. En anden ting, der er værd at nævne, er, at hvis der er en person på teamet, som er mere tydelig omkring, at tingene er uklare, eller som forsøger at udfylde hullerne, kan man spørge, om vedkommende vil deltage i forplanlægningsmøderne. I min erfaring har det været valgfrit for udviklere, men jeg har arbejdet på et projekt, hvor en af udviklerne var virkelig god til et bestemt teknisk problem. Jeg kunne se det, når vi talte om det, og når vi var i sprintplanlægning. Bagefter spurgte jeg ham: “Vil du deltage i nogle af forplanlægningsmøderne? Du behøver ikke forpligte dig, hvis det forstyrrer dit andet arbejde, og det er vigtigt. Men vil du hjælpe os med at pleje tingene på forhånd på vegne af udviklingsteamet?” Han blev en slags repræsentant for teamet.

Det fungerede godt i den situation. Hvis du finder en person, som bliver ved med at udfylde hullerne eller sige fra, forhåbentlig for at gøre opmærksom på, at tingene skal udfyldes og tydeliggøres, så spørg, om vedkommende vil være forbindelsesled på forhånd. Det kan måske hjælpe.

Ben Aston:

Der er så meget godt i artiklen, at jeg virkelig vil opfordre folk til at læse den. Den vigtigste pointe for mig er, at sprintplanlægningsmødet i sig selv er vigtigt, men at forberedelsen før mødet faktisk er endnu vigtigere. Man kan ikke tro, at man bare kan gå ind i sprintplanlægningsmødet og på fire eller to timer planlægge to ugers arbejde. Det kommer ikke til at ske. Sørg for at bruge tid på forberedelsen før mødet, så er der langt større sandsynlighed for, at det bliver en succes.

Alexa, mange tak fordi du ville være med. Det har været fantastisk at have dig med.

Alexa Huston:

Tak fordi jeg måtte være med.

Ben Aston:

Som en af vores DPM-eksperter, som jeg nævnte tidligere, medvirker Alexa i vores kommende kursus. Det begynder i februar og hedder Mastering Digital Project Management. Hvis du ikke ved, hvad jeg taler om, men ved, at du har brug for uddannelse i projektledelse, så tag et kig. Det er et syv ugers intensivt kursus med interaktive videolektioner, webinarer, opgaver, gruppediskussioner og mulighed for coaching. Gå til DPM.com, og tilmeld dig, før kurset bliver fyldt. Hvis du vil bidrage til samtalen, kan du kommentere på indlægget og gå til ressourcesektionen på digitalprojectmanager.com for at deltage i vores Slack-team. Der finder du alle mulige interessante samtaler om alt inden for digitalt arbejde og projektledelse. Hvis du kunne lide det, du hørte i dag, så abonnér gerne.

Brug et par minutter på at skrive en ærlig anmeldelse af DPM-podcasten på iTunes. Bedømmelser og anmeldelser er meget hjælpsomme, så gør det endelig. Det hjælper os virkelig med at tilpasse programmet og gøre det bedre. Det sætter vi stor pris på. Men indtil næste gang: Tak fordi du lyttede.