Dette indlæg er alene udtryk for skribentens egen holdning.

Arbejder I med sprints? Hvorfor egentlig?

13. marts kl. 20:4241
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Har du nogensinde tænkt på, om det nu også er hensigtsmæssigt at arbejde i sprints? Har du undret dig over, hvordan det kan være, at det agile manifesto indeholder princippet:

> Agile processes promote sustainable development.
> The sponsors, developers, and users should be able
> to maintain a constant pace indefinitely.

Og undret dig over at måden, vi organiserer vores arbejde på er navngivet efter en af den mest anstrengende fysiske aktiviteter mennesket kan udføre, og derfor kun kan gøre i kort tid - at sprinte?
Har du deltaget i et planning- eller grooming-møde og følt, at du spildte din tid, fordi det der blev talt om ikke berørte dig? Har du været nødt til at arbejde hårdt, og ikke haft tid til at lave din kode og teste den helt så godt som du gerne ville, for at kunne nå at levere i løbet af jeres sprint? Har du haft svært ved at komme i gang med din næste opgave, fordi de andre på teamet skulle runde nogle ting af fra sidste sprint først? Eller har du undret dig over, hvorfor jeres sprint har præcis den længde det har?

Sprints virker mange steder som standard

Artiklen fortsætter efter annoncen

At organisere sit arbejde i sprints virker næsten som standarden i Danmark.
Det undrer mig, fordi jeg og mine teams gik væk fra sprints for cirka syv år siden, og ikke en eneste gang siden har tanken strejfet mig, at vi skulle gå tilbage til sprints.

Hvorfor gik vi væk fra sprints?

Vi gik væk fra sprints, fordi sprints er lidt som et mini-vandfald. Da vi tænkte over hvor effektive vores møder var, kunne vi se, at vi kunne gøre dem mere effektive . At gå væk fra sprints var en åbenlys måde at forbedre.

Hvad gør vi i stedet for?

En afart af Kanban.

Arbejder I med sprints? Hvorfor egentlig?

Det undrer mig, at så mange kører med sprints, når de ville kunne undgå spild ved at gøre tingene anderledes.

Måske er det fordi sprints lugter lidt af vandfaldsmodel, og traditionen i vores branche gør, at vi hænger fast? Måske er det fordi, vi er bange for at prøve noget nyt? Måske er det fordi Scrum-sprints er blevet sat op på en piedestal, hvor de ikke hører hjemme? Eller måske er det fordi det er svært at arbejde uden sprints?
Jeg er sikker på, at ingen skal gøre præcis som vi gør; man skal finde sin egen vej, men måske har dette blogindlæg fået dig til at tænke over, hvorfor I egentlig bruger sprints?

41 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
41
17. marts kl. 17:55

Men hvor opstår opgaverne så?

Jeg er hverken produktejer eller produktmanager, men mit bedste bud er hos en stakeholder, som har set et behov der skal opfyldes.

For at svare på det spørgsmål, jeg antager du spørger om: Hvornor bliver de refinet? Det afhænger. Scrum begrænser det ikke eller dikterer hvornår eller hvordan det skal gøres.

Det kan være at produktejeren har så stor indsigt i produktet og detaljebehovet for udviklerne, at produktejeren alene kan gøre dette. Noget produktejeren normalt får igennem både sprint review, retrospective og planning.

Det kan være at man har afsat en en time til en halv dag hver uge, hvor man i fællesskab gør det.

Det kan være at udvikler, produktejer og stakeholders udveksler mails eller bruger et Kanban board, til løbende at refine "offline"/"async" i mellem context.

Det kan være at man afsætter et sprint til at refine de næste 2-5 sprints ud i fremtiden (Det er hvad SAFe gør).

Det kan være noget helt femte eller en kombination af ovenstående. Jeg har prøvet det hele og det afhænger jo helt sikkert af hvad der passer til de enkelte hold og organisationer. Scrum dikterer det ikke.

39
17. marts kl. 15:54

Er du softwareudvikler?

Jeps

Sprintet starter senere i dag og varer 14 dage.

Så har jeg brugt tid på at forfine opgaven inden da. Dykket ned i koden for at finde mulige steder. Hvis jeg ikke allerede ved det, så finde ud af om jeg har de værktøjer jeg skal bruge. Du nævner at man pludselig opdager, at man skal bruge en ny profiler.

Er opgaven meget diffus, så kan man bruge det der hedder en spike. Altså en tidsbegrænset opgave, hvor man undersøger, eksperimenter og opnår en større indsigt.

Har man mange diffuse opgaver, så har man højest sandsynligt også en kæmpe bunke "legacy" kode, som ikke har den bedste software arkitektur. Måske man har kørt deadline driven development (en term der dukker op på mit linkedin feed)?

Hvad gør du med dit SCRUM board, når "virkeligheden" ændrer sig, jeg som gav eksempler på?

Husk på at i scrum, der committer holdet sig til et sprint mål. Hvis planen man har lagt (User Stories, Task o.l.) ikke er rigtig, men målet stadig er, så bruger man daily på at lave en ny plan. Opdaterer sit Kanban board (husk at scrum ikke har et board), så det er transparent for omverdenen, hvor man er, hvor langt man er osv.

Hvis målet ikke længere er gyldigt, så stopper man sprintet. Afholder review, retrospective og ny planlægning. Ofte lader man sprintet køre færdig, da man heldigvis kun har committed sig til 2 ugers arbejde.

38
17. marts kl. 11:55

Martin: Er du softwareudvikler? Jeg spørger altså ikke for at fornærme, men fordi jeg kommer til at antage, at alle er det :)

Dit svar ligger nemlig ret langt fra det, jeg spurgte om.

Med dit mapping vil man jo som start bare vide, at "Funktionen X er for langsom". Og det, du ikke ved, er årsagen. Du har nu fået ansvaret for at dykke ned i C++ koden og løse det.

Sprintet starter senere i dag og varer 14 dage. Hvad lægger du ind i sprintet? (Opgavernes navne, epics/stories, hvad udfylder du i felterne med story points?).

Og vigtigst af alt, som jeg aller helst vil have svar på: Hvad gør du med dit SCRUM board, når "virkeligheden" ændrer sig, jeg som gav eksempler på?

37
17. marts kl. 06:38

Hvad lægger I helt konkret ind i de forskellige sprints?

Som en del af refinement af opgaven vil jeg nok bruge øvelsen "Example Mapping". Det er en konkret metode, til at finde frem til ting man ved og ting man ikke ved. Her vil personer med teknisk viden mødes med personer med forretningslogik viden (nogle gange er der overlap).

Denne øvelse er et godt udgangspunkt i at nedbryde en opgave. Så kan man prioritere de ukendte, man i fællesskab tror, kunne være løsningen. Her tager man så toppen af de prioriterede løsningsforslag og definere hvad man opnår, hvis man løser disse det. Åbenlyst, så vil en mulig løsning på problemet være noget af det man får ud af det. Men hvad ellers? Optimering af forretningsprocessen? Bedre dokumentation? Nye værktøjer til hurtigere fejlfinding i fremtiden? Refaktoring af kode der lugter (code smell), så løsningen bliver nemmere at vedligeholde? Eller?

Hvad så hvis løsningen ikke bliver fundet? Uanset hvad, så mødes minimum de samme mennesker, som var med til example mapping til sprint review. Her deler man den viden man har opnået og kan så se på, om de resterende løsningsforslag, som ikke blev taget ind, stadig giver mening at hive ind eller om man har lært noget nyt, som måske er en bedre vej. Det kan også være at forretningen prioritere en anden opgave højere nu, men er glade for det, der dog er opnået.

Og sådan bliver man ved indtil løsningen er fundet eller forretningen/kunden/stakeholder skifter prioritet.

Indtil nu har jeg ikke berørt estimater. Det er naturligt, at kunden ønsker et estimat på leverance tid eller pris. I ovenstående betaler kunden for et sprint. Ved at nedbryde opgaven, så kan i sammen sætte målsætning for, hvad der er opnået i det sprint. Du får tid til at tænke og dykke ned i koden før du bliver tvunget til at give estimater. Du giver estimater på mindre og mere konkrete løsningsforslag. Kunden får ny viden i slutningen af sprintet og har mulighed for at tage beslutninger på baggrund af den viden; Fortsætte med andre løsningsforslag eller skifte opgave til noget mere værdiskabende?

36
16. marts kl. 21:41

Martin: Hvordan har I så håndteret diffuse opgaver? Lad os sige, at en bestemt funktionalitet er langsom.

At undersøge årsagen er en naturlig første task. Men man ved ikke engang, hvor lang tid undersøgelsen tager. Måske ser man med det samme, at det er netværksdelay. Måske skal man efter 5 arbejdsdage igang med at finde en egnet C++ profiler og tage den derfra.

Årsagen findes måske midt inde i 2. sprint, og løsningen er algoritmisk. Man afsætter så noget tid til først at lære om dem, men opdager efter noget tid en helt anden og simplere løsning.

Hvad lægger I helt konkret ind i de forskellige sprints? Kunne du evt. opdigte et konkret eksempel?

34
16. marts kl. 18:32

Et af målene er vel at hjælpe med at nedbryde opgaver til overskuelige bidder, så man ikke hænger fat i en kæmpe-opgaven

Der er absolut intet galt i at have en stor opgave, tvært imod! Prøv nu at forstå det.

Jeg er "opfinder", både med software og fysiske ting, og både på hobbyplan og kommercielt. Jeg har også haft normale fuldtidsjobs med SCRUM. Så jeg har prøvet lidt af hvert.

Den håndfuld af de mest geniale ting/løsninger, som jeg har fundet på, er opstået via en meget lang grublen og tænken og en masse eksperimenter. Dernæst tilbage til start og forfra igen, utallige gange.

Tro mig, den process kan ikke opdeles på nogen måde. Den er diffus og kan ikke engang beskrives. Et sjovt eksempel er https://www.youtube.com/watch?v=13MhbNzqS_k som gennem en årrække beskriver et forsøg på at lave en blanding mellem en saks og en foldekniv.

Eller spørg enhver iværksætter, om de mon ville have haft gavn af at have haft en SCRUM master til at "hjælpe" med at styre deres tankebaner om deres nyskabende produkt.

Giv nu plads til innovation, det er det, Danmark skal leve af. Standardprodukter og hyldevarer er ret usikkert i dag.

Der er intet af det, som SCRUM gør, som du ikke kan gøre uden. Du kan lave deadlines og tidsestimater, du kan prioritere dine opgaver, du kan opfordre folk til at opdele opgaver, du kan arbejde i parallelt og du kan få endda samarbejde med dine brugere og få feedback fra dem.

Helt uden diktator.

33
16. marts kl. 13:11

Der er vel ikke noget galt med sprints, hvis det bliver lavet rigtigt. Et sprint er vel et point-in-time møde hvor opgaver nedbrydes til enheder der kan løses i sprintperioden og prioriteres. Et af målene er vel at hjælpe med at nedbryde opgaver til overskuelige bidder, så man ikke hænger fat i en kæmpe-opgaven. Og drømmen er at der kan laves en mini-release efter hvert sprint, så kunderne/testerne får leveret det der er lavet i mellemtiden.

Der er ingen der siger at det skal være fuld skrue og udmattende. Sprints er vel divide and conquer metoden. Nedbryd til tilstrækkeligt små enheder der kan laves på under x dage/uger. Og hvis de er tilstrækkeligt små, så kan man lave mange opgaver indenfor fristen.

For lederne er det vel den løbende prioritering hver 14 dag der er vigtigt, og overblik over fremskridt, ikke nødvendigvis hvor meget der laves i perioden.

32
16. marts kl. 00:10

Har set hvordan Scrum med en Scrum Master, der er proces fikseret og ikke rigtig forstår leverancerne derved skaber et team, der manisk laver tasks.

I den agile verden burde man fokusere på små teams dvs 2-3 udviklere med rette kompetancer, der arbejder tæt sammen om at løse en opgave og måske har visualiseret opgaven i et Kanban Board. Teamets selvjustits vil gøre det svært at smyge sig uden om. - I stedet burde fokus være på team samarbejde og kvaliteten af leverancen. Det kræver både faglig indsigt og social kompetance fra den der styrer.

Feedback skal komme ved at release reglmæssigt og lade udvalgte brugere arbejde med softwaren undervejs og komme med feedback af den vej. Scrum demos fra stakeholders giver ikke den form for dyb feedback.

Før vi fik Scrum arbejdede vi på den måde og var i virkeligheden mere smidige.

29
15. marts kl. 09:00

Produktivitet på grund af timeforbruget på micro management og møder, hvor man bliver afbrudt i sine tankebaner.

Det lyder til at du har haft en dårlig oplevelse med noget, som nogen har kaldt scrum. 8 sammenhængende dage kun med 15 minutters møde er hvad scrum beskriver for 2 ugers sprint. En halv dag med planlægning før dette og så afsluttet med en halv dag med feedback fra slutbrugeren, samt planlægning optimering af arbejdsprocesser, redskaber, relationer og personlig udvikling. Alt andet er ikke fra scrum, men fra en organisation, som ønsker noget andet/mere.

28
15. marts kl. 07:46

For mange enterprise software projekter/leverance er feedback fødekæden som nedenstående. Nogen gange for man 'short-circuted' sig ind lidt længere ned end nummer 2. Det er ikke flertallet af gange. Tunge leverancer kan man risikere at nå nummer 7, med kraftig overvågning af 5 og 6. Det er dog typisk 6 der laver signoff.

1.Udvikling 2.Projekt leder eller planlægning 3.SLA eller kontrakt mål 4.Egen Chef 5.Egen Chef gruppe 6.Modtagers Chef (og Køber) 7.Modtagers projektleder 8.Modtagers bruger

27
15. marts kl. 07:21

produktivt team

Jeg er ikke helt enig. I mine øjne ofrer man produktivitet OG innovation til fordel for en (falsk) følelse af kontrol.

"Falsk" fordi jeg gætter på, at hvis man lavede en statistik på overskredne deadlines, tror jeg ikke, at SCRUM virksomeheder ville klare sig signifikant bedre. Men dette er dog et gæt.

Produktivitet på grund af timeforbruget på micro management og møder, hvor man bliver afbrudt i sine tankebaner.

Innovation fordi man skal forsøge at få virkeligheden til at passe ned i en skabelon.

26
14. marts kl. 21:19

At skabe resultater kræver både en ledelse der formår, at sætte de rigtige mennesker sammen og samtidig, at kunne skabe rammer for de mennesker, at kunne leverer ud fra.

Vi arbejder med mennesker. Det kræver mere end, at kunne skrive kode. Rigtig dygtige udviklere har også nogle stærke sociale egenskaber samt forståelse for både de antropologiske og psykologiske egenskaber.

Arbejdet med, at leverer software er langt mere end, at skrive kode. Det er nærmest den mindste del. Lidt ligesom, at en koks arbejde handler om langt mere end, at lave den færdige ret. Der er meget forberedelse i, at lave software og det er ofte godt givet ud, at "gasse lidt ned" og få talt tingene og kravene igennem mere end en gang.

Også er det altså sjældent processens skyld. Selvom jeg kan være enig i, at cermonierne i f.eks SCRUM kan være tidskrævende. Men man glemmer måske også, at det ikke handler om, at blive hurtig færdig - men at bygge det rigtige.

Der er efterhånden ret god konsensus omkring, at små teams leverere bedst og, at hvis man lader de små teams have frihed, mandat og ansvar - som sin egen enhed - så skaber de bedre resultater. Der er videnskabelig evidens for det her mener jeg ?

Min erfaring med mange forskellige teams er, at dem som har en indkørt SCRUM proces der rent faktisk fungere, kan anses som værende en smule konservative og "kedelige" - fordi det virker jo bare. Til gengæld giver det arbejdsro, en god team-dynamik og ofte et produktivt team.

Min erfaring er også, at det altid fejler hos enten ledelsen, product-owner eller scrum-masteren. De er enten ikke kompetente nok eller jonglere med flere roller eller for store teams.

Held og lykke.

25
14. marts kl. 13:10

Hvad nu, hvis virksomheden er af en type, som overhovedet ikke har dette behov? Fx hvis du udvikler hyldevarer uden en bestemt kunde. Er der så ingen grund til at bruge SCRUM?

Det er vigtigt at holde sig for øje hvem der er kunden/brugeren. I dette tilfælde er det forretningen - hvad den nu mener der kan sælges. Her er det netop yderst vigtigt for f.eks marketing at vide hvornår en given feature er klar, så de kan tilrettelægge deres kampagner.

Og, kan kunden ikke se, hvad der fokuseres på, hvis man bruger Kanban? Man kan jo bare vise dem sin prioritetsliste. Du kan endda sætte tidsestimater på hver opgave uden problemer. Hvad er meningen så med SCRUM?

Det kan de sagtens. De kan bare ikke se hvornår (præcist) opgaverne er færdige eller hvorfor "super vigtig feature" ligger langt nede ad listen.

Med et sprint er det afklaret hvad hele teamet har ansvar for og fokus på. Det betyder, at hvis man er hurtig færdig med sine opgaver, hjælper man om muligt resten af teamet med deres opgaver inden man henter en fra backlog.

Det går ikke så godt med at slå søm i hvis man bruger skaftet på hammeren. Sådan er det også med SCRUM - et værktøj der kan anvendes helt og aldeles forkert.

SCRUM vrider ikke flere udviklingstimer ud af teamet - tværtimod.

Jeg ser SCRUM som et værktøj der - anvendt rigtigt - giver:

  • fokus på det kunden/brugeren har behov for
  • levering til aftalt tid
  • ansporing til sammenhold i teamet om løsning af opgaverne

Har man ikke de behov - bør man nok undlade at bruge SCRUM.

24
14. marts kl. 12:29

Der er nogle premisser for scrum man helst skal købe ind på før det virker godt. Man skal tro på at feedback giver værdi. Kundens feedback. Slutbrugerens feedback. Udviklerens feedback.

Man skal forstå at scrum er en team disciplin. Intressenter uden for teamet stiller teamet opgaver, ikke til individer på teamet. Teamets sammensætning skal helst ikke ændres for tit.

Teamet skal fungere som et team, ikke som en samling individer der fordeler opgaver og løser dem i en-mands-siloer. En del af værdien ligger i vidensdeling og om at tale om kode og løsninger.

Kode arbejdet skal kunne paralleliseres. Udviklerne skal ikke vente på hinanden. Nogle gange skal man måske starte med at afdække nogle grænseflader, så det bliver muligt. Andre gange er det måske praktisk med et proof of concept først.

På et team er der tit en der er fuld af ideer og andre der helst bare vil kode-der-ud-ad. Hvem der gør hvad finder teamet selv ud af.

Det er også en god ide med 'constant pace' og 'shift left'. Det samme gælder her - man skal tro at det giver værdi at teste, kvalitetssikre og deploye tit. Jo hyppigere des bedre. Mange starter med en arkitektur hvor hyppige deploys er umuligt, men tror man på at det giver værdi, så kan man også finde en arkitektur hvor det er lettere, og så arbejde sig frem mod den.

Scrum handler om at minimere risikoen. Den der kan sige "vi har deployet halvdelen af projektet i prod" har et bedre indblik i fremdriften end en der siger "Vi er færdige med krav-speccen og i gang med analyse".

22
14. marts kl. 11:36

Kunden/brugeren kan se præcis hvilke opgaver der fokuseres på.

Hvad nu, hvis virksomheden er af en type, som overhovedet ikke har dette behov? Fx hvis du udvikler hyldevarer uden en bestemt kunde. Er der så ingen grund til at bruge SCRUM?

Og, kan kunden ikke se, hvad der fokuseres på, hvis man bruger Kanban? Man kan jo bare vise dem sin prioritetsliste. Du kan endda sætte tidsestimater på hver opgave uden problemer. Hvad er meningen så med SCRUM?

21
14. marts kl. 11:35

Siger du, at man skal diktere, at opgaven skal tage 2 uger uanset hvad, fordi SCRUM siger det?

Jeg siger at man skal sørge for at involvere sin slutbruger og sørge for at få feedback. Om du kalder det Scrum, mini vandfald, Kanban eller Lasses model er under ordnet.

At nedbryde opgaven vil oftest blotlægge nogle af de fuldstændige uforudsigelige veje. Det vil blotlægge de antagelser de enkelte medarbejdere har. At bruge en time eller to på at kortlægge "known unknowns", kan spare en dag, en uge eller et måned i et kaninhul. Det er i øvrigt også en teknik man bruger i Kanban - hvis man vil.

Jeg siger at scrum er et værktøj. Nogle gange er det det eneste man har behov for, andre gange er det et andet værktøj, fx Kanban og nogle gange en kombination, fx Scrumban.

20
14. marts kl. 11:13

@Martin: Jeg kan ikke forstå dit svar. Siger du, at man skal diktere, at opgaven skal tage 2 uger uanset hvad, fordi SCRUM siger det?

@Ole Kaas: Præcis. SCRUM siger, at man så skal opdele opgaven. Og jeg gav et real life scenarie, hvor det kikser.

Alle steder, jeg har arbejdet med SCRUM, har burndown-grafen været vandret. Det er meningen, den skal gå linært skråt nedad.

Tilhængerne vil nu sige, at skyldes, at man ikke er dygtig nok til at underinddele sine opgaver og tidsestimere dem korrekt. Hvortil jeg typisk kommer med praktiske eksempler:

  1. Der er en mærkelig sporadisk fejl i produktet, som ermeget diffus svær at reproducere. Du aner ikke, om det vil tage 1 eller 30 dage at løse, eller hvordan du skal starte. Hvad skal ind i sprintet?

  2. En bestemt funktionalitet er langsom og skal optimeres. Som med opgave 1 kan det tage dig ned ad fuldstændig uforudsigelig veje, som overhovedet ikke kan planlægges på forhånd.

Tilhængerne vil svare, at SCRUM tillader fleksibilitet fordi verden er uforudsigelig og tilgiver dig når den ændrer sig.

Hvortil jeg så spørger, hvad værdien så består i i forhold til Kanban. Og sådan kører vi i ring.

19
14. marts kl. 10:40

opgave, som man kun ved, vil tage mellem 3 og 5 uger at løse, og ens sprints varer 2 uger?

Det afhænger. Scrum dikterer det ikke, så jeg kan tale ud fra egen erfaring. I projektplanlægning er der typisk tre parametre man kan rykke på, uden at gå på kompromis med kvaliteten: Scope, Budget, Tid.

Vi er allerede enige om at tiden er fastsat: 2 uger.

Hvad med budget? I scrum vil man gerne følge en fast og stabil rytme. Så foruden "9 gravide kvinder giver ikke en baby på 1 måned"-problemet, så bør man heller ikke tilføje flere hjerner. Hvis man på anden vis kan øge produktiviteten ved at bruge flere penge (måske bare midlertidigt) så er det et parameter der kan virke. Hurtigere udviklingsmiljø, kortere CI/CD kørselstider og lignende (I SAFe har man et system team, som kan hjælpe med det).

Og så er der scope. Den utrolig svære diciplin at mindske scope og samtidig give værdi til slutbrugeren. Det er nok her filmen knækker for mange, når man snakker Scrum.

Når man stadig er i gang med at lære disciplinen med scope, så er der mange som viser hvor man er i opgaven. Man snakker med slutbrugeren, om hvilke antagelser man har lavet, hvilke uforudsete problemer man løb ind i, hvordan man løste dem, hvor meget man er tror der er tilbage og hele tiden prøver at spore sig ind på om man er på rette vej.

Det vigtige er at man snakker med slutbrugeren. Tidligt og ofte. Afstemningsforventning samt minimere antallet af personer i mellem dem der har et behov, som skal dækkes og dem, som skal udføre opgaven.

Det er et overhead, som hjælper med at navigere i et komplekst system, forretningsområde eller kompleksitet generelt. Det er ikke noget, som alle har brug for. Hvis man arbejder på små trivielle opgaver i simple og veldefineret omgivelser, så er det kun et overhead uden værdi. Scrum er en torx skruetrækker. Nogle gange har man bare brug for lim, andre gange en pensel og nogle gange det hele.

18
14. marts kl. 10:29

Martin: Hvad gør man i SCRUM, hvis man har en opgave, som man kun ved, vil tage mellem 3 og 5 uger at løse, og ens sprints varer 2 uger?

Scrum eller ej, så bør du ikke have en "opgave" der varer mellem 3 og 5 uger. Det er ikke en opgave - det er nok mere et ønske om en funtionalitet. Den skal defineres nærmerer og brydes ned i opgaver der tager mellem en halv dag og et par dage at udføre. Så kan opagverne planlægges i sprintet, flere kan arbejde på fuktionaliteten på samme tid og man har et overblik over fremdriften.

16
14. marts kl. 10:14

Jeg var engang udsat for en scrum-evangalist. Han sagde at mange ikke udførte scrum men "scrum but". At man kun tog de dele fra scrum-modellen som man kunne finde ud af eller syntes gav mening. Man kan godt afvige fra modellen - men først når man fuldt forstår den og har anvendt den. Som så meget andet.

Et par vigtige punkter jeg har lært hvis scrum skal være noget værd:

  • afsæt tid ved siden af sprintet til møder, hasteopgaver, bugs, sygdom osv. Hvis 100% af arbejdstiden er afsat til sprintet, er det dømt til at fejle.
  • det er vigtig ikke at tage (comit) flere opgaver ind i sprintet end man er 100% sikker på at man kan nå.

Det sidste er det sværeste - fordi der naturligvis er et pres for at nå så meget som muligt. Men man når ikke mindre - for man napper bare opgaver fra backlog NÅR man er færdig med opgaver i sprintet. Omvendt skal sprintet også give kunden indtryk af at der rent faktisk er fremdrift og fokus på de for kunden vigtigste opgaver.

Fordelen er at teamet 100% når de opgaver teamet har lovet kunden og som kunden mener er de vigtigste.

Så er der al den tid der går med planning, retro, refinement osv. Det kan være en fantastisk team-building process - eller gabende kedeligt navlepilleri. Det afhænger meget af scrum-masterens evner om det bliver det ene eller det andet.

15
14. marts kl. 09:37

Martin: Hvad gør man i SCRUM, hvis man har en opgave, som man kun ved, vil tage mellem 3 og 5 uger at løse, og ens sprints varer 2 uger?

14
14. marts kl. 09:26

Du er nødt til at indføre en slags "tovholder"-opgave, som kan indeholde de opdelte underopgaver, og en slags "måleenhed" for varighed.

Nej. Det behøver man ikke. Som Morten Jensen er inde på, så bruger man refinement på det. Noget som produktejeren er ansvarlig for. Ofte kræver det input fra både slutbruger og udvikler. Ofte er det implementeret som et møde. Men det behøver det ikke at være.

Man arbejder i rytme og når man kender sin rytme, kan man "eyeball'e" om behovet kan dækkes på et sprint.

Det vigtige, fra mit perspektiv, er at man får feedback fra slutbrugeren tidligt og ofte. Scrum tvinger feedback ved at have møder i slutningen af et sprint. Kanban kan man få det i irregulære intervaller (endda nogle gange når man kommer til testfasen i vandfaldsmodellen) og andre gange endnu bedre end Scrum.

(Lidt relateret men lidt off topic, så kalder SAFe ikke-værdiskabende arbejde for Enablers. Det kan man jo så mene om hvad man vil).

13
14. marts kl. 09:22

Det er (åbenbart) svært at tage et skridt tilbage og spørge slutbrugeren om hvorfor de har deres behov og hvilke roller disse behov dækker, før man begynder at snakke om krav, arkitektur, og implementeringsdetaljer.

Det her er nok den absolut singulært vigtigste ting i hele den her tråd. Find ud af, hvad problemet er, i stedet for bare at bygge den løsning (feature), som nogen har opfundet for at løse et problem du ikke kender.

12
14. marts kl. 09:08

Morten: Det var ikke hele story'en jeg trak ind i sprintet. Det var opgave A, som var veldefineret med story points, og gik ud på at undersøge hvordan opgave B skulle løses.

11
14. marts kl. 09:00

Martin: Vi snakker forbi hinanden.

Er vi enige om, at ingen opgaver må være så stor, at de ikke kan løses i et enkelt sprint?

Hvis ja, hvordan vil du så håndtere en diffus opgave, hvor du ikke på forhånd ved, hvor mange dage den vil tage?

Du er nødt til at indføre en slags "tovholder"-opgave, som kan indeholde de opdelte underopgaver, og en slags "måleenhed" for varighed.

Det kommer tit til at kollidere med den virkelige verden. Tilhængerne af SCRUM vil så påstå, at det fint tillader, at den fysiske verden er uforudsigelig. Det forbyder ikke, at du trækker opgaver ind og ud af sprints eller at "Actual story points" blier helt anderledes end "Estimated story points".

Mit svar er så: Hvilken værdi giver det så? I forhold til bare at have en liste af opgaver, som du tager fra en ende af.

10
14. marts kl. 08:59

Du bør vel ikke trække en story ind på et sprint, der ikke er refinet, og derudover afhænger af noget afklaring med slutbrugeren. Det skal jo være afklaret inden story'en er med

9
14. marts kl. 08:43

Jeg vil anbefale alle at kikke på Kanban i stedet. Her har man en prioriteret liste af opgaver og så spiser man dem eller bare fra toppen af.

Man gør vel egentlig det samme i Scrum. Der planlægger man også bare hvad man ønsker feedback på fra slutbrugeren et sprint af gangen. Og så tjekker man hver dag om man følger planen, om den skal tilrettes og om man evt skal have hjælp fra andre til at komme videre.

Kanban og Scrum går godt hånd-i-hånd. Nogle kalder det endda for Scrumban.

8
14. marts kl. 08:27

Nu bliver der spurgt direkte til "sprint", og det er sandt nok et underligt ord for noget, som ideelt set foregår i et jævnt tempo. Men det er nok fordi, at det aldrig var blevet til noget, hvis det var blevet kaldt en "slendretur". Og var blevet misforstået, hvis det var blevet kaldt en marathon-etape.

Og møderne, ja. Det er tankevækkende, at der er så mange ting, som skal ske med en fast frekvens og på en helt særlig måde, samtidigt med at ordet "ceremoni" er udnævnt til et skældsord.

Personligt tror jeg på, at det er en form for analogi til dengang Coplien gjorde sig selv upopulær på JAOO (eller hed det Goto?) ved at sige, at TDD virkede fint, når det blev brugt af erfarne folk med en solid intuition for, hvad slutresultatet skulle være - men at det i hænderne på de uerfarne var en direkte opskrift på en katastrofe.

På samme måde er det min oplevelse, at Scrum og sprints virker fint for et dygtigt team, som allerede kan arbejde sammen (og nej, det opstår ikke af sig selv, men tager tid - og det er ikke nok at sætte en tilfældig samling af dygtige folk sammen). Og når teamet får den nødvendige ro. I bund og grund handler det om tillid imellem mennesker, både i teamet og imellem teamet og dets interessenter.

Hvis man tror, at man kan låse døren og lukke sig inde i nogle uger, og kun vil forstyrres hver anden tirsdag og onsdag imellem 10 og 14, så gør man det forkert. Hvis man bliver detailstyret undervejs, så gør man det forkert.

Det kan virke, hvis teamet har et fåtal af håndgribelige mål at arbejde henimod - en bevægelse hen imod en håndgribelig men overskuelig ændring af verden, som hverken er for stor til rammerne, men samtidig er større end hvad der kan løses individuelt. Så er der brug for samarbejde. Hvis der derimod er tale om løbende reaktion på omgivelserne eller en stadig strøm af mindre og uafhængige opgaver, og der mere er tale om samtidigt arbejde (with a little help from my friends) end om samarbejde, og så bliver det hele kunstigt.

Et godt team behøver ikke megen planlagt koordinering, de snakker løbende sammen undervejs, og de stiller sig naturligt rigtigt på banen af sig selv - så daily er ofte ret kort. På samme vis med de andre faste møder. Til gengæld er forudsigeligheden vigtigt, for det gør at man ikke behøver tage tingene i øjeblikket, når man ved, at der bliver en passende lejlighed til det snarest. Det handler meget om at finde den gode rytme.

Og når rytmen bliver så indarbejdet og naturlig, at omgivelserne også fanger den, så virker det godt.

7
14. marts kl. 08:22

Man aner ikke, hvor stor opgaven bliver. Så man må oprette en epic som siger "A: Find ud af hvordan det skal løses, B: Løs det"

Lad os lige blive enige om hvad vi snakker om. Epic er ikke en del af Scrum. Det samme med story points. Det samme med metrics og burn down.

En Epic, Feature eller User Story (for at holde os i den gængse terminologi) skal jo helst være værdiskabende for slutbrugeren. Gerne uafhængig af andre Product Backlog Items (PBI).

Din Epic burde forklare hvorfor det er værdiskabende og for hvilken slags slutbruger. Den bør forklare i akkurat nok detaljegrad, hvad det er slutbrugeren ønsker.

Hvordan det bliver implementeret er ikke en bekymring, som slutbrugeren behøver at have. Det er heller ikke sikkert at de har ekspertisen i det.

Det er (åbenbart) svært at tage et skridt tilbage og spørge slutbrugeren om hvorfor de har deres behov og hvilke roller disse behov dækker, før man begynder at snakke om krav, arkitektur, og implementeringsdetaljer.

Hvis du har afdækket hvorfor, til hvem og hvad, så er det fløjtende ligegyldigt om slutbrugeren er syg. Du ved hvad de vil have og hvorfor. Så kan du tilpasse din (langsigtet) arkitektur og implementere løsningen uden indblanding af slutbrugeren før løsningen er klar. I Scrum, der er det bl.a. det en produktejer er ansvarlig for (men de må gerne uddelegere arbejdet). I SAFe får de bl.a. hjælp af produkt manageren.

Det scenario du beskriver viser at produktejeren ikke lever op til deres ansvar.

Scrum er utrolig let at forstå og utrolig svært at gøre. Diciplinen med at forstå hvad slutbrugerens egentlige behov er og samtidig bryde det ned i stykker, som er små nok til at kunne blive leveret inden for et sprint (1-4 uger) og samtidig store nok til at være værdiskabende i sig selv. Jeg kan godt forstå at det er nemmere bare at gøre som man altid har gjort. Hvem har brug for forandring?

6
14. marts kl. 07:42

Det er synd at folk fokuserer på alt eller intet. Enten har vi scrum, eller også har vi noget andet.

Jeg har efterhånden kørt en del forskellige hold af forskellige mennesker med forskellige baggrunde.

Vi har altid i fællesskab fundet frem til den løsning der virker bedst for det hold. Det har aldrig været enten eller. Det har altid haft en smule fra Agile manifestoet, noget fra lean, noget fra en helt anden process, og sikkert noget vi selv fandt på.

5
14. marts kl. 07:25

Uanset hvilket nyt, smart og moderne system der nu blev det nye hype på arbejdspladsen, har jeg aldrig oplevet at det ændrede noget som helst - til det bedre, forstås.

Hvis afdelingslederen var god til at skimme overskrifterne, så kunne han meddele at "Fra nu af skal vi arbejde i sprints!" eller "Vi skal bruge LEAN principperne!"

Den almindelige reaktion var "Okay, så kalder vi det dét" og så gik vi tilbage til arbejdet og gjorde som vi plejer.

Det er meget muligt at alle de her smarte systemer som Lean, Scrum, Sprint, etc. lyder fint, men i mellemtiden har vi altså et job at udføre.

Jeg har tilbragt endeløse timer på at sidde og høre en tredive mand stor afdeling gennemgå deres opgaver fra i går, og de opgaver de har tænkt sig at løse i dag.

Jeg har siddet og brugt to ud af ti arbejdsdage på sprintplanlægning og -evaluering, i en gruppe på tre udviklere(!!)

Under en jobsamtale fik jeg engang et spørgsmål om hvordan jeg havde det med Scrum. Jeg prøvede at være ærlig, samtidig med at jeg ikke ville afvise det helt. Det er jo lidt sådan et hvornår-holdt-du-op-med-at-banke-din-kone-spørgsmål.

Han fortalte at han havde afskaffet hele lortet så snart han havde en lederposition. Jeg måtte minde mig selv om regningerne og udgifterne til husholdning for ikke at tilbyde ham at arbejde gratis...

4
14. marts kl. 07:13

Det er noget mere fundamentalt, der er galt.

Lad os sige, at programmet kan ikke finde ud, hvordan man tilføje et nyt kæledyr i en kæledyrsapp.

Man aner ikke, hvor stor opgaven bliver. Så man må oprette en epic som siger "A: Find ud af hvordan det skal løses, B: Løs det" og tildele 100 story points til A.

Da du ikke må forstyrres i dit sprint, skal du trække opgaven hen i næste sprint som starter om 12 dage. Da næste sprint starter, er brugeren blevet syg. Så du trækker opgaven ud af sprintet igen og trækker opgave X ind i stedet.

Brugeren er tilbage næste dag, så du er nødt til at trække opgaven ind igen, og det bliver SCRUM Burndown-grafen sur over, fordi X nu står som uløst.

Brugeren siger, at man bare skal skrive en anden tekst på brugerfladen, så er det super nemt. Du retter derfor de 100 story points til 10. Nu bliver SCRUM Burndown grafen glad igen.

Geez. Blev SCRUM opfundet i Strasbourg?

Udover det, så dræber SCRUM al innovation, fordi det ikke passer ind i rammerne.

Jeg vil anbefale alle at kikke på Kanban i stedet. Her har man en prioriteret liste af opgaver og så spiser man dem eller bare fra toppen af.

3
14. marts kl. 06:27

Hvis man ikke bruger Sprint Review på at få feedback fra slutbrugeren og retter sit produkt/opgaver til baseret på den feedback, så er Sprint Review spild af tid.

Hvis man ikke bruger Sprint Retrospective på at se tilbage på arbejdsprocesser, arbejdsforhold, individuelle færdigheder og de redskaber man bruger med henblik på at lave umiddelbare forbedringer, så er Sprint Retrospective spild af tid.

Hvis man ikke bruger Sprint Planlægning, på at forene holdets fokus, på det der giver slutbrugeren værdi og dermed sikre at alle (udviklere, stakeholders, produktejere og slutbruger) arbejder sammen, så er Sprint Planning spild af tid.

Hvis man hele tiden bliver afbrudt i sit arbejde med nye krav, process ændringer, eller arbejder ufokuseret på mange forskellige opgaver på samme tid, så er Sprint spild af tid.

Hvis man lader udviklerne arbejde uforstyrret i en kort periode (1-4 uger, typisk 2), hvor de har samme fokus, samme scope og ingen møder (udover de daglige planlægningsmøder og de førnævnte inspektion og tilretningsmøder), så giver sprint mening. Man minimere risikoen for at arbejde på det forkerte, ved relativt ofte at se om man er på rette vej, mens man lader holdet samarbejde uforstyrret på det samme.

Scrum er et redskab. Ikke alting kan fikses med en torx skruetrækker. Hvis man er vant til at bruge lim, søm eller skruer med Phillips hoved, så kan torx skruer se mærkelige ud. Det kræver lidt tilvænning. Hvis man til gengæld bruger pensel til hverdag, så er en torx skruetrækker nok ikke det rigtige redskab.

Scrum er fantastisk når det virker. Det er et helvede at være i, når det aktivt bliver modarbejdet eller aktivt presset ned over hovedet på folk.

2
13. marts kl. 22:44

Jeg afsøgte jobmarkedet for et lille års tid siden, fordi der skulle ske noget nyt. Alle jobopslag med formuleringer som "du bliver en del af et af vores SCRUM teams..." fik et omgående tryk på Næste.

Fandt et super spændende job, hvor man ikke kunne drømme om den slags.

1
13. marts kl. 21:04

Jeg har forgæves kæmpet mod SCRUM gennem hele min karriere på alle mine arbejdspladser.

Jeg er kommet til konklusionen, at det er fordi følelsen af kontrol er vigtigere end selve arbejdet.

Det samme ses mange andre steder i samfundet.

Trist.