Introduktion til Scrum og de Agile principper

For at forstå Scrum og de forskellige mekanismer af Scrum, så er det vigtigt at man forstår de underliggende principper, som driver og skaber disse mekanismer. 

Jeg vil derfor i dette indlæg gå i dybden med de agile principper der ligger til grund for Scrum og sammenligne dem med traditionel projektledelse. 

Ved at få en forståelse for disse principper og forskellene mellem dem, får du en bedre forståelse for hvordan Scrum differentierer sig fra traditionelle former af projektledelse.

Overblik

Den bedste måde at forklare og skabe en dybere forståelse for de underliggende Scrum principper er ved at sammenligne dem med de overbevisninger som driver mere traditionelle projektledelsesmetoder. Det gør det langt nemmere at forstå hvordan Scrum er magen til, eller anderledes fra, metoder du allerede kender.

Målet med at sammenligne agile principper med traditionelle udviklingsprincipper er ikke for at sige, at traditionel projektledelse er dårligt og Scrum er godt. Begge er redskaber i den professionelle projektleders værktøjskasse. Der findes ikke et dårlig projektledelses-redskab, blot et dårligt tidspunkt at bruge det på. Den overordnet forskel er, at Scrum og traditionel projektledelse er gode til forskellige typer af problemstillinger.

Når jeg sammenligner de to tilgange, så bruger jeg den helt klassiske form for traditionel projektledelse, da jeg ved at tage dette perspektiv meget klart kan forklare forskellene mellem de principper der ligger under Scrum-baseret udvikling.

Planlagte processer er kaldt dette, fordi de forsøger at planlægge og forudsige alle de features en bruger vil have i det færdige projekt, og at planlægge hvordan man bedst muligt kan bygge disse features. Idéen er her, at jo bedre planlægning, jo bedre en forståelse og dermed jo bedre en eksekvering. 

Planlagte processer er ofte kaldt for sekventielle processer fordi udviklerne sekventielt eksekverer en komplet kravsanalyse efterfulgt af et komplet design, som så bygges og testes.

Traditionel projektledelse fungerer godt, hvis du bruger det på problemer, som er klart defineret, forudsigelige og der er lav sandsynlighed for at der sker nogle betydelige ændringer undervejs i projektet. 

Problemet er, at projekter oftest er alt andet end forudsigeligt, specielt i starten. Så hvor en planlagt proces giver udtryk for en velordnet, ansvarlig og målbar tilgang, så kan dette udtryk føre til en falsk fornemmelse af sikkerhed. 

Det skyldes, at udviklingen af et produkt sjældent går efter planen.

For mange, så vil en planlagt sekventiel proces bare give mening; forstå den, design den, kode den, test den og release den, alt efter en veldefineret, klar plan. Man tror på, at det bør virke. 

Hvis man bruger en planlagt tilgang og det ikke virker, så er den overordnet attitude, at man må have gjort noget forkert. 

Selv hvis en planlagt process gentagne gange giver skuffende resultater, så er der mange organisationer, som fortsat bruger den samme tilgang med den tro, at hvis bare de gør det bedre, så vil deres resultater også blive bedre. 

Problemet er dog ikke med eksekveringen. Problemet er, at planlagte tilgange er baseret på et sæt af overbevisninger, som ikke matcher usikkerheden der er, når man udvikler et produkt.

Scrum er dog på den anden side baseret på et anderledes sæt af overbevisninger, som er gode til problemer med nok usikkerhed til at gøre præcise planer tæt på umuligt. 

I dette indlæg vil jeg forklare principper fra “Agile Manifesto” (Beck et al. 2001), “lean product development” (Reinersten 2009b; Poppendieck and Poppendieck 2003) og sidst “The Scrum Guide” (Schwaber and Sutherland 2011).

Disse principper er organiseret om til flere forskellige kategorier.

Jeg starter ved at diskutere principperne, som udnytter forandringen og usikkerheden der er i projekter. Dette bliver efterfulgt af en diskussion af principperne, som imødekommer balancen mellem up-front forudsigelser med Just-in-Time tilpasning. 

Derefter vil jeg diskutere principperne, som er fokuseret på læring, efterfulgt af principperne for at håndtere work-in-progress. 

Til sidst vil jeg konkludere ved at fokusere på fremskridt og performance principper.

Forandring og usikkerhed

Scrum udnytter forandringen og usikkerheden i projekter til at skabe innovative løsninger. 

Jeg vil beskrive fire principper der er relateret til dette emne:

  • Omfavn forandring
  • Anvend iterativ og incremental development
  • Udnyt forandring gennem inspektion, tilpasning og gennemsigtighed
  • Minimer alle former for usikkerhed på samme tid

Omfavn forandring

Planlagte processer behandler projekter som produktion – de undgår forandring og opfordrer tilpasning til en defineret proces. 

Problemet er, at projekter på ingen måder minder om produktion. Ved produktion er målet at tage et fast sæt af krav og følge et sekventielt sæt af veldefineret skridt for at producere et færdigt produkt der er ens hver gang.

I projekter er målet dog at skabe unikke enkelttilfælde af produktet, ikke at producere produktet. 

Dette enkelttilfælde er magen til en unik opskrift. Vi ønsker ikke at skabe den samme opskrift to gange, hvis vi gør det, så har vi spildt vores penge. 

I stedet, så ønsker vi at skabe en unik opskrift for et nyt produkt. En mængde forandring er nødvendigt for at producere et nyt produkt hver gang. 

Hver feature vi bygger til et produkt er endda forskellig fra alle de andre features i produktet, så forandring er nødvendigt selv på dette niveau. 

Først når vi har opskriften begynder vi på at producere produktet – i tilfælde af software produkter, så er det så nemt som at kopiere dele ind.

Når det så er sagt, så er der nogle produktionskoncepter, som passer til projekter og bør udnyttes. 

Så projekter og produktion er ikke den samme ting og de kræver derfor meget forskellige processer.

Anvend iterativ og incremental development

Planlagt, sekventiel udvikling antager at vi vil få tingene til at gå op fra start af og at det meste eller alle projektets delelementer vil passe sammen senere hen.

Scrum, på den anden side, er baseret på iterativ og incremental development. Selvom disse termer ofte er brugt som var de et enkelt koncept, så er iterativ udvikling meget anderledes end incremental development.

Iterativ udvikling anerkender, at vi sikkert vil gøre tingene forkert før vi gør dem rigtigt og at vi vil gøre tingene ringe før vi gør dem godt. 

Derfor er iterativ udvikling en planlagt re-work strategi. Hvis vi bruger flere omgange for at forbedre det vi bygger, så vi kan ende med en god løsning. 

For eksempel, kan det være, at vi starter med at bygge en prototype for at skaffe vigtig viden omkring en del af produkt vi ikke har meget viden om. Derefter kan vi lave en revideret version, som er en smule bedre, som så til gengæld er efterfulgt af en meget god version. 

Et eksempel kan være, når jeg skal skrive en artikel som denne. Her starter jeg med at skrive et afsnit, som jeg kan læse igennem, så jeg derefter får en bedre forståelse for det jeg gerne vil kommunikere. Herefter kan jeg omskrive indtil jeg opnår en artikel, som jeg er godt tilfreds med.

Iterativ udvikling er en god måde at forbedre det produkt, som udvikles. Den største ulempe ved iterativ udvikling er, at i tilfælde af usikkerhed kan det være meget svært, at planlægge hvor mange omgange af forbedringer der er nødvendige.

Incremental development er baseret på det ældgamle princip “Byg noget af det før du bygger det hele.” Vi undgår dermed at have et stort big-bang tilfælde i slutningen af udviklingen, hvor alle de forskellige dele sættes sammen og hele produktet er leveret. 

I stedet, så bryder vi produktet ned i mindre dele, så vi kan bygge noget af det, lære hvordan hver del kan overleve i det miljø det skal eksistere, tilpasse baseret på hvad vi lærer, og så bygge mere af det. 

Incremental development giver os vigtig information, som gør det muligt for os at tilpasse vores udviklingsarbejde og ændre hvordan vi skal fortsætte. Den største ulempe ved incremental development er, at ved at bygge i små dele, så kan vi risikere at overse det store billede. Vi ser alle træerne, men ikke hele skoven.

Scrum udnytter fordelene ved både iterativ og incremental development, samtidigt med at ulemperne ved at bruge dem individuelt fjernes. Scrum gør dette ved at bruge begge ideer i en tilpassende serie af time-boxed iterationer kaldet sprints.

Scrum overview

Under hver sprint laver vi alle de aktiviteter der er nødvendige for at skabe et produkt trinvist (noget af produktet, ikke hele produktet). Denne all-at-once tilgang har den fordel at man hurtigt kan validere de antagelser der laves når product features udvikles. 

For eksempel, så laver vi nogle designbeslutninger, laver noget kode baseret på disse beslutninger, og så tester vi design og kode – alt sammen i den samme sprint. 

Ved at gøre alt det relateret arbejde i en sprint kan vi hurtigt omarbejde features, hvilket giver os fordelene ved iterativ udvikling, uden at det er nødvendigt at planlægge for ekstra iterationer.

En måde sprint konceptet misbruges på er ved at fokusere hver sprint på kun en type arbejde. For eksempel, sprint 1 (analyse), sprint 2 (design), sprint 3 (kodning) og sprint 4 (test). Sådan en tilgang forsøger at bruge Scrum tilgangen med en waterfall-stil arbejdsstruktur. 

Denne tilgang refereres ofte til som WaterScrum eller Scrummerfall. Med Scrum arbejder vi ikke på en fase af gangen, vi arbejder på en feature af gangen. Dermed vil vi i slutningen af hver sprint have skabt et værdifuldt produkt inkrement. 

Dette inkrement inkluderer eller er integreret og testet med alle de tidligere udviklet features, ellers er det ikke betragtet som færdigt. I slutningen af en sprint kan vi få feedback på de nyeste færdiggjorte features indenfor konteksten af de allerede færdiggjorte features. Dette hjælper os med at se produktet i det store billede.

Vi modtager feedback på sprint resultaterne, hvilket gør det muligt for os at tilpasse. Vi kan vælge forskellige features at arbejde på i næste sprint eller ændre processen vi vil bruge til at bygge det næste sæt af features. 

I nogle tilfælde kan det være, at vi lære at delelementet, selvom det teknisk set passer godt ind, ikke er så godt som det bør være. Når det sker kan vi planlægge omarbejde til en fremtidig sprint som del af vores forpligtelse til iterativ udvikling og kontinuerlige forbedringer. 

Dette hjælper os med at overkomme problemet med ikke at kende til at starte med hvor mange omgange af forbedringer vi får brug for. Srum kræver ikke, at vi bestemmer et fastsat antal af iterationer. Denne kontinuerlige strøm af feedback vil hjælpe os med at gøre det rigtige og økonomisk fornuftige antal iterationer samtidigt med at vi inkrementelt udvikler produktet.

Udnyt forandring gennem inspektion, tilpasning og gennemsigtighed

Planlagte processer og Scrum er fundamentalt anderledes i forhold til flere forskellige dimensioner.

En planlagt, sekventiel udviklingsproces antager lav eller ingen forandring. Den følger et veldefineret sæt af skridt og bruger kun meget små mængder af feedback sent i processen. I modsætning omfavner Scrum det faktum, at i projekter er et niveau af forandring en nødvendighed for at bygge noget nyt. 

Scrum antager også, at processen der er nødvendig for at skabe produktet er kompleks og vil derfor trodse en klar og up-front definition. Yderligere, så generer Scrum tidlig og fast feedback for at forsikre, at det rigtige produkt er bygget, samt at produktet er bygget rigtigt.

I hjertet af Scrum er principperne inspektion, tilpasning og gennemsigtighed. I Scrum inspicerer og tilpasser vi ikke kun det vi bygger, men også hvordan vi bygger det.

For at gøre dette godt, så er gennemsigtighed vigtigt. Alt den information der er nødvendig for at producerer et produkt skal være tilgængelig til personerne der er involveret i at skabe produktet. 

Gennemsigtighed gør inspicering muligt, hvilket er nødvendigt for tilpasning. Gennemsigtighed tillader også alle at observere og forstå hvad der sker. Det fører til mere kommunikation og etablerer tillid.

Minimer alle former for usikkerhed på samme tid

Udviklingen af et nyt produkt er en kompleks rejse, som har en høj grad af usikkerhed. Denne usikkerhed kan man dele ind i to brede kategorier.

  • Produkt usikkerhed – usikkerhed omkring de forskellige features af det færdige produkt
  • Metode usikkerhed – usikkerhed omkring de processer og teknologier der bruges til at udvikle et produkt

I nogle områder eller ved specifikke produkter kan der også være kunde usikkerhed. For eksempel, så har start-up organisationer måske kun antagelser om hvem der bliver den endelige kunde af deres produkter. Denne usikkerhed skal adresseres, da man ellers kan ende med at bygge geniale produkter til de forkerte markeder.

Traditionel, sekventiel udviklingsprocesser fokuseres først på at eliminerer alt slut usikkerhed ved at definere præcist hvad der skal bygges inden man går i gang, og adresserer derefter kun metode usikkerhed.

Den simplistiske, lineære tilgang til usikkerheds nedsættelse passer dårligt til det complex domain af projekter, hvor vores aktioner og det miljø vi opererer i begrænser hinanden.

For eksempel:

  • Vi beslutter os for at bygge en feature
  • Vi viser så denne feature til en kunde, som efter at have set den, ændrer sin belustning for hvad han eller hun gerne vil have, eller opdager, at han eller hun ikke har forklaret detaljerne af de ønskede features præcist nok.
  • Vi laver designændringer baseret på feedback.

I Scrum begrænser vi os ikke ved at adresserer en type af usikkerhed før vi går videre til næste type. I stedet tager vi en mere holistisk tilgang og fokuserer på samtidigt at reducerer alle usikkerheder. 

Naturligvis, så vil vi på et tidspunkt  fokusere på mere end en type af usikkerhed. Samtidig adresserer vi mange forskellige typer af usikkerhed, ved hjælp af iterativ og incremental development, som er guidet af konstant inspektion, tilpasning og gennemsigtighed. 

Sådan en tilgang gør det muligt for os, at sondere og udforske vores miljø for at identificere og lære mere om unknown unknowns som de opstår.

Forudsigelse og tilpasning

Når vi bruger Scrum, så balancerer vi konstant ønsket for forudsigelse med behovet for tilpasninger. Jeg vil nu forklare fem agile principper, som er relateret til dette emne.

Hold muligheder åbne

Planlagt, sekventiel udvikling kræver at vigtige beslutninger i områder som krav eller design laves, gennemtjekkes og godkendes inden for deres retrospective faser. Yderligere, så skal disse beslutninger laves før vi kan gå videre til næste fase, selv hvis disse beslutninger er lavet på begrænset information.

Scrum hævder at, vi aldrig bør lave en beslutning for tidligt bare fordi en generisk proces vil diktere, at det nu er tid til at lave et nyt møde. I stedet, når du bruger Scrum, så favoriserer vi en strategi der holder alle muligheder åbne. 

Dette princip er ofte refereret til som last responsible moment, hvilket betyder at forpligtelser udsættes og ikke tager vigtige beslutninger, som vi ikke kan ændre indtil det sidste ansvarlige område. Og hvornår er det? Det er det, når prisen for ikke at tage en beslutning er større end prisen for at tage en beslutning.

For at værdsætte dette princip, så tænk over dette. På vores første dag af projekter har vi kun minimal information om det vi laver. På hver efterfølgende dag af udviklingen lærer vi en smule mere. Hvor vil man så nogensinde vælge, at tage alle de mest kritiske beslutninger, som potentielt set er umulige at ændre, på den første dag eller bare meget tidligt i processen?

De fleste af os vil foretrække at vente indtil vi har mere information, så vi kan tage en veloplyst beslutning. Når vi har at gøre med vigtige beslutninger som ikke kan ændres, og vi beslutter os for tidligt og det viser sig at være forkert, så vil vi være på den eksponentielle del af af cost of deciding kurven. 

I takt med at vi får en bedre forståelse i forhold til beslutningen, falder prisen for beslutninger. (Og dermed falder sandsynligheden for at lave en dårlig beslutning på grund af et stigende marked eller teknisk usikkerhed). Derfor bør man vente med denne type beslutninger til, at man har mere information.

Accepter at du ikke kan have ret til at starte med

Planlagte processer kræver ikke kun fulde kravspecifikationer og en komplet plan; de antager også, at vi kan have ret fra start af. 

Realiteten er dog, at det er meget usandsynligt, at vi kan opnå alle kravene, eller at den detaljeret plan, som er baseret på disse krav, er korrekt lige fra starten af. Hvad der er endnu værre er, at når kravene ændrer sig, så skal vi modificerer alle kravene og planerne, så de passer til den nuværende realitet.

I Scrum anerkender vi, at vi ikke kan have ret i forhold til alle kravene og planerne lige fra start af. Vi mener endda, at det er farligt at forsøge på dette, da der er stor sandsynlighed for, at vi misser vigtig information, hvilket fører til skabelsen af store kvantiteter af krav af lav kvalitet.

Når man bruger en planlagt, sekventiel proces, så er et stort antalt af krav produceret tidligt, når vi har den mindst kumulative viden om produktet. Denne tilgang er meget risikabel, da der er en illusion at vi har fjernet slut usikkerhed. Det er også potentielt meget sløset, når vores forståelse forbedres eller ting ændrer sig.

Med Scrum producerer vi stadig nogle krav og planer fra start af, men kun det der er behov for, og med den antagelse, at vi vil udfylde detaljerne af disse krav og planer i takt med at vi lærer mere omkring det produkt vi bygger. 

Selv hvis vi tror, at vi er 100% sikre på hvad der skal bygges og hvordan det skal organiseres for at bygge det, så vil vi lære hvor vi er forkerte på den, så snart vi leverer vores tidlige inkrementelle leveringer til det miljø hvor de skal eksistere. 

På det tidspunkt vil alle de ubelejlige realiteter af hvad der virkelig er nødvendigt drive os til at lave ændringer.

Foretræk en tilpassende og udforskende tilgang

Planlagte, sekventielle processer fokuserer på at bruge hvad man ved og forudsige hvad man ikke ved. Scrum foretrækker en mere tilpassende, trial-and-error tilgang baseret på passende brug af udforskning.

Udforskning referer til tidspunkter hvor vi vælger at skaffe viden ved aktiviteter, som at bygge en prototype, skabe proof of concept, lave et studie eller at lave et eksperiment. Med andre ord, når vi bliver mødt af usikkerhed, så køber vi information ved at udforske.

Vores redskaber og teknologier har en stor indflydelse på prisen for udforskning. Historisk set har software projekter været meget dyrt, som også har været grunden til, at man har foretrukket en forsøg-på-at-få-ret-fra-start-af tilgang.

Heldigvis, så er vores redskaber og teknologier blevet bedre og prisen for udforskning er faldet enormt meget. Der er ikke længere nogen økonomisk grund til ikke at udforske. 

Faktisk, så er det i dag ofte billigere at bruge bruger-feedback baseret på, at bygge noget hurtigt, end det er at forsøge på at ramme alt perfekt fra start af. Det er også en god ting, da den kontekst, altså de andre teknologier der eksisterer, som vores løsning skal passe ind i, hele tiden bliver mere kompleks.

Med Scrum, hvis vi har nok viden til at lave et informeret, fornuftigt skridt videre med vores løsning, så går vi videre. Når vi dog bliver mødt med usikkerhed, så vil vi, i stedet for at forsøge på at lægge en plan, bruge billig udforskning til at købe relevant information, som vi så kan bruge til at lave et informeret, fornuftigt skridt videre med vores løsning. 

Feedback fra vores aktion vil hjælpe os med at finde ud af om det er nødvendigt med mere udforskning.

Omfavn ændringer på en økonomisk fornuftig måde

Når man bruger sekventiel udvikling, så er ændringer, som beskrevet, væsentligt dyrere senere hen end det er i starten.

For eksempel vil en ændring lavet under “analysis” måske koste 10 kroner. Den samme fejl lavet senere hen under “testing” koster måske 10.000 kroner. 

Men hvorfor er det? Hvis vi laver en fejl under analysis, og finder den under analysis, så er det billigt og nemt at fikse. Hvis den samme fejl ikke er fundet indtil design, så skal vi ikke bare fikse det forkerte krav, men potentielt set også dele af vores design, som er baseret på det forkerte krav. Denne kumulative mængde af fejl fortsætter gennem hver fase, hvilket gør hvad måske har været en lille fejl under analysis til en meget større fejl at fikse under testing eller operations.

For at undgå senere ændringer, så forsøger sekventielle processer forsigtigt at kontrollere og minimere ændrede krav eller designs ved at forbedre hvor præcise deres forudsigelser er om hvad systemet har behov for eller hvordan systemet skal gøre det.

Desværre, så har det at være overdrevet planlæggende i tidlige aktivitets faser ofte den modsatte effekt. Det fejler ikke kun i forhold til at eliminere ændringer, det bidrager faktisk i forhold til at gøre leveringer sene og over budgettet. 

Så hvorfor denne paradoksale sandhed? For det første, så tvinger ønsket om at eliminere dyre ændringer os til at overinvestere i hver fase – at gøre mere arbejde end nødvendigt og praktisk. 

For det andet, så er vi tvunget til at lave beslutninger baseret på vigtige antagelse tidligt i processen, før vi har valideret disse antagelser med feedback fra vores stakeholders baseret på vores arbejdende aktiver. Som et resultat, så producerer vi en stor mængde inventar af arbejde-produkter baseret på disse antagelser. 

Senere, så skal denne inventar højst sandsynlig rettes eller smides ud, i takt med at vi validerer vores antagelser, eller ændringer finder sted, som de altid vil. 

I Scrum, der antager vi at ændringer er normen. Vi tror på, at vi ikke kan planlægge os væk fra den usikkerhed, som der er når man udvikler et produkt, ved at arbejde længere og hårdere inden vi går i gang. 

Derfor skal vi forberede os på at omfavne ændringer. Og når de ændringer finder sted, så ønsker vi at det økonomiske aspekt skal være mere tiltrækkende end med traditionel projektledelse, selv når ændringerne sker senere i projekterens arbejde.

Vores mål er derfor at holde cost-of-change kurven flad i så lang så tid som muligt, hvilket gør det økonomisk fornuftigt at omfavne selv sene ændringer. 

Vi kan opnå dette mål ved at håndtere mængden af work in process og vores arbejdsflow så at udgiften ved ændringer, når vi bruger Scrum, er mindre påvirket af tid end den er ved sekventielle projekter.

Uanset om hvilken projekters tilgang vi bruger, så skal det følgende forhold være sandt; en lille ændring i krav skal give en proportionel ændring i implementationen og derfor i udgifter.

En anden fordel ved dette forhold er at vi vil have, at det skal være sandt, uanset hvornår ændringen finder sted.

Med Scrum producerer vi mange arbejdsprodukter, som f.eks. detaljeret krav, designs og tests, på en just-in-time måde, hvor vi undgår skabelsen af potentielt unødvendige genstande. Som resultat, når en ændring er lavet, så er der typisk langt færre genstande eller begrænsende beslutninger baseret på antagelser, som kan fjernes og omarbejdes, hvilket holder denne udgift proportionel til størrelsen på ændringen.

Ved brug af sekventiel udvikling er den tidlige skabelse af genstande og pres for for tidlige beslutninger med til at gøre, at udgiften af ændringer stiger kraftig over tid som inventar vokser. 

Dette skaber et inflations-punkt som sker tidligt. Når der udvikles med Scrum, så kommer der en tid hvor prisen for ændringer ikke længere er proportional med størrelsen på ændringen, men dette punkt i tiden finder først sted senere hen.

Balancer forudsigeligt up-front arbejde med tilpassende Just-in-Time arbejde

En fundamental tro af traditionel projektledelse er at detaljeret up-front krav og planlægning er kritiske og bør færdiggøres før man går videre til senere faser. I Scrum tror vi på at up-front arbejde bør være hjælpsomt uden at der skal være for meget af det.

Med Scrum anerkender vi, at det ikke er muligt at få krav og planer fuldstændigt korrekt lige fra start af. Betyder det, at vi ikke skal lave nogle krav eller nogen form for planlægning? 

Naturligvis ikke. Scrum handler om at finde balance – balance mellem planlæggende arbejde og tilpassende just-in-time arbejde.

Når der udvikles et produkt, så bør balancepunktet sættes på en økonomisk fornuftig måde for at maksimere mængden af kontinuerlig tilpasning baseret på fast feedback og minimering af mængden af planlægning, mens vi stadig overholder reguleringer og virksomhedens mål.

Præcis hvordan denne balance er opnået er drevet til dels af den type produkt der bygges, graden af usikkerhed der eksisterer i både hvad vi vil bygge og hvordan vi vil bygget det, og de begrænsninger der er placeret på udviklingen. 

Er man for planlæggende, så vil det kræve at vi laver mange antagelser foran stor usikkerhed. Er vi for tilpassende kan det resultere i at vi befinder os i et stadie af uendelige ændringer, hvilket vil medføre at arbejdet føles ineffektivt og kaotisk. For at udvikle innovative produkter hurtigt, er vi nødt til at operere i et område, hvor tilpasningsevnen har en modvægt af lige nok planlægning for at undgå, at vi bevæger os ind i kaos. 

Scrum Framework’et operere godt i dette balancepunkt af orden og kaos. 

Valideret læring

Når vi bruger Scrum, så organiserer vi arbejde for hurtigt at skabe valideret læring. Vi anskaffer valideret læring, når vi opnår viden der bekræfter eller benægter en antagelse vi har lavet. Her vil jeg gå i dybden med tre agile principper relateret til dette emne:

  • Valider vigtige antagelser hurtigt
  • Udnyt flere lærings loops på samme tid
  • Organiser dit arbejdsflow for fast feedback

Valider vigtige antagelser hurtigt

En antagelse er et gæt, noget man tror er sandt, rigtigt eller helt sikkert, selvom vi ikke har noget valideret læring der gør, at vi virkelig kan vide, at det er rigtigt. 

Traditionel projektledelse er meget mere tolerant for antagelser der har levet i lang tid, end Scrum er. Med traditionel projektledelse producerer vi mange up-front krav og planer, som højst sandsynligt er en del af mange vigtige antagelser, hvoraf mange ikke bliver valideret før meget senere i udviklingen.

Antagelser repræsenterer en betydelig udviklingsrisiko. I Scrum forsøger vi at minimere antallet af vigtige antagelser der eksisterer gennem hele processen. Vi vil heller ikke lade antagelser leve uden validering i for lang tid. 

Kombinationen af iterativ og incremental development sammen med fokus på billig udforskning kan bruges til at validere antagelser hurtigt. Som resultat, hvis vi laver fundamentalt dårlige antagelser, når vi bruger Scrum, så vil vi højst sandsynligt opdage vores fejl hurtigt og have muligheden for at fikse den. 

Med planlagt, sekventiel udvikling kan den samme dårlige antagelse, hvis den først bliver valideret sent, medføre en betydelig eller total fiasko af vores udvikling.

Udnyt flere lærings loops på samme tid

Der er læring, som opstår når man bruger sekventiel udvikling. En vigtig form for læring sker dog først efter features er blevet bygget, integreret og testet, hvilket betyder, at betydelig læring sker i slutningen af udviklingen. 

Denne sene læring betyder færre fordele, fordi det kan være der ikke er tid til at udnytte læringen eller at prisen for at udnytte den er for høj.

I Scrum forstår vi, at konstant læring er meget vigtigt for vores succes. Når vi bruger Scrum, så identificerer og udnytter vi feedback loops for at øge læring. 

Et gentagende mønster i denne stil af projekter er, at lave en antagelse eller sætte et mål, bygget noget eller lave en aktivitet, få feedback på hvad der er blevet bygget og derefter at bruge denne feedback til at inspicere hvad vi gjorde i forhold til hvad vi antog. Vi kan så lave tilpasninger til produktet, processen og/eller vores antagelser baseret på hvad vi har lært.

Scrum udnytter flere foruddefineret lærings loops. For eksempel, så er den daily Scrum et daily loop og et sprint review er et iterations-niveau loop. 

Et Scrum Framework er også fleksibelt nok til at omfavne mange andre lærings loops. For eksempel, selvom det ikke er specificeret af Scrum, så er tekniske feedback loops, som f.eks. pair programming og testdrevet udvikling ofte brugt sammen med Scrum udvikling.

Organiser arbejdsflow for fast feedback

Tolerance over for antagelser der har levet i lang tid gør også planlagte processer tolerante over for sen læring, så fast feedback er ikke et fokus. 

Med Scrum, går vi efter fast feedback, fordi det er kritisk for at hjælpe med at afkorte forkerte afveje hurtigere og er vigtigt for hurtigt at opdage og udforske tids-sensitive, pludselige muligheder.

I traditionel projektledelse skal hver aktivitet der er planlagt ske på et planlagt tidspunkt baseret på en veldefineret fase sekvens. 

Denne tilgang antager, at tidligere aktiviteter kan færdiggøres uden feedback genereret af senere aktiviteter. Som resultat, så er der måske en lang periode af tid mellem at lave noget og at få feedback på det vi gjorde.

Lad os bruge komponent udvikling og test som et eksempel. 

Hvis man f.eks. udvikler tre komponenter parallelt. På et tidspunkt skal disse komponenter integreres og testes før vi ved om vi har et produkt der kan lanceres. Indtil vi tester, så ved vi ikke rigtigt om det vi har udviklet, passer ind korrekt. test vil give kritisk feedback til komponentens udvikling. 

Ved brug af traditionel projektledelse, så vil udvikling og tests ikke finde sted indtil den foruddefineret downstream fase, hvor mange eller alle af komponenterne skal integreres. 

Desværre, så er ideen at vi kan udvikle en masse forskellige komponenter på samme tid og så senere, i integrationsfasen, føre dem sammen nemt og hurtigt, hvor alt virker som det skal. 

Faktisk, så selv med gode interfaces, som er defineret inden vi udvikler komponenterne, så er der stadig god sandsynlighed for, at der er noget der går galt, når vi integrerer dem.

Feedback-genererende aktiviteter, som finder sted lang tid efter udviklingen har uheldige sideeffekter, som f.eks. at forvandle integration om til et stort test-and-fix fase, fordi komponenter der er blevet udviklet væk fra hinanden sjældent fungerer perfekt sammen. 

Hvor lang tid det vil tage og hvor meget det vil koste at fikse problemet kan man kun gætte sig frem til det ved dette punkt.

Med Scrum organiserer vi arbejdsflowet til at passere gennem vores lærings loop og dermed få feedback så hurtigt som muligt. Ved at gøre det, så sikrer vi, at feedback-genererende aktiviteter finder sted tæt på der hvor det originale arbejde har fundet sted. 

Fast feedback giver gode økonomiske fordele, fordi fejl samler sig når vi udsætter feedback, hvilket resulterer i eksponentielt større fiaskoer. 

Lad os igen kigge på vores eksempel med komponent udvikling. Da vi designede komponenterne, lavede vi en vigtig antagelse for hvordan de vil blive integreret. Baseret på disse antagelser fortsatte vi ned af en design sti. Vi kommer ikke på noget tidspunkt til at finde ud af om det valgte design er rigtigt eller forkert. Det er bare vores bedste gæt.

Når vi vælger en sti, så tager vi dog alle andre beslutninger som er baseret på dette valg. Jo længere vi venter med at validerer den originale design antagelse, jo større er antallet er afhængige beslutninger. 

Hvis vi senere hen finder ud af at den originale antagelse var forkert, så vil vi stå tilbage med en stor samling af fejl. Vi vil ikke bare have truffet mange dårlige beslutninger, som der nu skal arbejdes på igen, vi vil også blive nødt til at gøre det efter lang tid er gået.

Fordi udviklerne vil have glemt meget af det de har arbejdet på, så skal de også bruge tid på at komme i tanke om alt det arbejde de lavede tidligere.

Når vi medregner den totale udgift ved at omarbejde potentielt dårligt afhængige beslutninger, og udgiften for at produktet er forsinket, så er de økonomiske fordele ved fast feedback meget tiltalende. 

Fast feedback lukker lærings loops hurtigt, hvilket gør det muligt at opdage og undgå dårlig udviklingsretninger før de kan resultere i stor økonomisk skade.

Work In Process (WIP)

Work In Process, eller WIP, refererer til alt det arbejde, som vi har startet på, men endnu ikke er færdige med. Under projekter skal WIP anerkendes og håndteres effektivt. Jeg vil nu gå i dybden med fire agile principper relateret til dette emne.

  • Brug økonomisk fornuftige batch sizes
  • Fokusér på ledigt arbejde, ikke ledige medarbejdere
  • Overvej Cost of Delay

Brug økonomisk fornuftige batch sizes

Endnu en kerne antagelse der ligger under planlagte, sekventielle udviklingsprocesser er, at det er bedre at samle alt af en type arbejde og lave det i en enkelt fase. 

Det kan man kalde for en alt-før-noget tilgang, hvor man færdiggøre alt af en type aktivitet inden man starter på den næste. Lad os sige, at vi skaber alle kravene under vores analytiske fase. 

Derefter flytter vi samlingen af krav ind i design fasen. Fordi vi har genereret et komplet sæt af krav, så er vores batch size i dette eksempel 100%.

Denne alt-før-intet tilgang er, til dels, en konsekvens af troen på at gamle produktionsprincipper som stordriftsfordele gælder ved projekter. Dette princip siger, at prisen for at producere en enhed vil gå ned i takt med at vi øger antallet af enheder der produceres. Den sekventielle udviklings-overbevisning er, at større mængder i projekter også vil realisere stordriftsfordele.

Med Scrum accepterer vi at selvom stordriftsfordele tankegangen er et fuldstændigt solidt princip i produktion, så vil det resultere i betydelig økonomisk skade, at bruge det dogmatisk ved projekter.

Selv om det måske lyder ulogisk, så er det mest fordelagtigt at arbejde i små grupper under projekter. Så hvis det er tilfældet, bør man så ikke bare arbejde i grupper af 1, hvilket betyder at vi kun arbejder på et krav ad gangen og bevæger det gennem alle aktiviteterne indtil det er færdigt og klar til en kunde? Nogle mennesker foretrækker denne single-piece flow. 

Det at vælge en gruppestørrelse på en kan måske være passende i nogle tilfælde, men at antage at “en” er målet kan potentielt være skadeligt for flow og den overordnet økonomi.

Fokusér på ledigt arbejde, ikke ledige medarbejdere

Med Scrum, der tror vi på at ledigt arbejde er langt større ødsel og økonomisk skadende end ledige medarbejdere. Ledigt arbejde er arbejde, som vi gerne vil gøre (som f.eks. bygge eller teste noget), men ikke kan gøre fordi noget forhindrer os i det. 

Måske er vi blokeret, fordi vi venter på en anden projektgruppe skal gøre noget, og indtil den projektgruppe færdiggør sit arbejde, kan vi ikke gøre vores. 

Eller måske har vi bare så meget arbejde at gøre, at vi ikke kan gøre det hele på en gang. I dette tilfælde, så sidder noget af arbejdet som ledigt indtil vi er tilgængelige til at arbejde på det. Ledige medarbejdere, på den anden side, er personer som har kapaciteten til at gøre mere arbejde, fordi de ikke på nuværende tidspunkt er 100% brugt.

Mange projekters organisationer fokuserer mere på at eliminere spildet at ledige medarbejdere end på at minimere ledigt arbejde. For eksempel, med den traditionelle tankegang, hvis jeg ansætter dig til at være tester, så forventer jeg, at du bruger 100% af din tid på at teste. Hvis du bruger mindre end 100% af din tid på at teste, så er det spild for mig (du er ledig, når du kunne være i gang med at teste). For at undgå dette problem, vil jeg finde mere testarbejde for dig, måske ved at tilskrive dig flere projekter, for at få din indsats op på 100%.

Desværre, så reducerer denne tilgang en form for spild (ledige medarbejdere), men den øger en anden form for spild (ledigt arbejde). Og, for det meste, så er prisen for ledigt arbejde lang større end prisen for en ledig arbejder. Lad os undersøge, hvorfor dette er sandt.

For at illustrere dette problem, så lad os bruge en 100%-igang strategi til 4 x 100 meter racet til OL. Baseret på denne hold-dem-igang strategi, så virker racet til at være meget ineffektivt. 

Jeg betaler personer for at løbe og det virker som om, at de kun løber 25% af tiden. Resten af tiden står de bare og venter. Det kan dog ikke være rigtigt. Jeg betaler dem jo 100% løn, så jeg vil gerne have, at de løber 100% af tiden. Hvad så med, at når de ikke løber med stafetten, at de bare løber lidt frem og tilbage eller måske løber med ved et andet race? På den måde vil de være 100% i gang.

Selvfølgelig, så ved vi alle, at du ikke vinder guld ved at holde alle løbere 100% i gang. Du vinder guldet ved at få stafetten over slutlinjen først. Dermed er det vigtige takeaway, at du skal holde øje med stafetten og ikke dem der løber. 

I konteksten af projekter, så er stafetten lig med arbejde, der ligger på gulvet, som er klar til at blive gjort, men er blokeret, da man venter på nødvendige ressourcer. Du vinder ikke racet (leveringen af projekter/produkter) når stafetten ligger på gulvet. 

Denne stafet analogi er god, fordi den viser, at man skal holde øje med arbejdet og ikke dem der arbejder. Ligesom med alle andre analogier, så har den dog sine begrænsninger. I dette tilfælde, så er denne race-tilgang med at give arbejde videre præcist et aspekt af traditionel, sekventiel projekter, som vi gerne vil undvige.

Derudover kender alle konsekvenserne af, at holde en ressource 100% i gang.

Alle der ejer en computer ved hvad der kommer til at ske, hvis du kører din computer på 100% (fuld processor og hukommelse). Så vil den begynde at brænde sammen og alle opgaver på computeren bliver væsentligt langsommere. 

Med andre ord, så arbejder computeren på flere ting og ender dermed faktisk med at få mindre produktivt arbejde færdiggjort. Når først man er endt i denne tilstand, så er den meget svær at komme ud af (du bliver sikkert nødt til at lukke programmer ned eller endda genstarte computeren). Din computer vil være meget mere effektiv, hvis du kører den på 80%.

Det ledige arbejde (forsinkede arbejde) vokser eksponentielt når vi rammer høje niveauer af udnyttelse. Og det ledige arbejde kan være meget dyrt, ofte mange gange dyrere end prisen for ledige medarbejdere. 

Dermed er vi i Scrum meget opmærksomme på at finde flaskehalsproblemer i vores flow af arbejde og at fokusere vores tid på at eliminere disse er meget mere økonomisk fornuftigt end at forsøge på at holde alle 100% udnyttet.

Overvej Cost of Delay

Cost of delay er den finansielle udgift forbundet med forsinket arbejde eller forsinkelsen af at opnå en milepæl. I takt med at kapacitetsudnyttelse stiger, så stiger størrelsen på kø og forsinkelser også. Derfor, ved at reducerer mængden af ledige medarbejdere (ved at øge deres udnyttelse), så øger vi automatisk også spildet forbundet med ledigt arbejde (arbejder der er i kø og venter på at blive gjort). Ved brug af Cost of delay kan vi udregne hvilken type spild der er mest økonomisk skadelig.

Desværre, så kvantificerer 85% af organisationer ikke cost of delay. Kombiner det med det faktum, at de fleste udviklingsorganisationer ikke opdager, at de har akkumuleret arbejde (inventar) på ventelister, og det er derfor nemt at se hvorfor deres standard adfærd er, at fokusere på at eliminere det synlige spild af ledige medarbejdere.

Her er et simpelt eksempel for at illustrere hvorfor prisen for ledigt arbejde typisk er større end prisen for ledige medarbejdere. Overvej dette spørgsmål: Bør vi tildele en person til at dokumentere alle projektets features til projektgruppen på den første dag af udvikling eller i slutningen af udviklingen?

Antag at vi tildeler denne person fuldtid i 12 måneder for at arbejde på dette projekt/produkt, selv hvis der ikke er behov for ham 100% af tiden. 

At gøre det koster inkrementelt 75.000 (tænk på det som ledigt arbejder spild) over hvad det vil koste hvis vi bragte ham ombord i to måneder i slutningen når produktet når stadiet af “all but documented.”

Hvis vi tildeler en person til at gøre alt dokumentationen i slutningen, så vil vi have behov for ham fuld tid i to måneder, men vi vil også forsinke leveringen af produktet med disse to måneder. 

Hvis vi forsinker projektet med to måneder, så vil den beregnet cost of delay i forhold til lifecycle profits der er 500.000 (lifecycle profits er den totale potentielle profit af et produkt over dets livstid; i dette eksempel falder denne potentiale profit med 500.000).

I dette eksempel, så vil prisen for en ledig arbejder være 75.000 og prisen for ledigt arbejde 500.000. Hvis vi fokuserer på at optimere vores udnyttelse af denne person, så vil vi betydeligt suboptimere økonomien af det overordnet produkt. 

Under projekter er vi præsenteret med denne type trade-offs på en kontinuerlig basis; cost of delay vil være en af de vigtigste variable at overveje, når vi skal lave økonomisk fornuftige beslutninger.

Fremskridt

Når vi bruger Scrum, så måler vi fremskridt ved hvad vi har leveret og valideret, ikke ved hvordan vi bevæger os frem i følge en foruddefineret plan eller hvor langt inde vi er i en specifik fase eller stadie af udvikling. 

Under dette emne beskriver jeg tre agile principper:

  • Tilpas til real-time information og lav en ny plan
  • Mål fremskridt ved at validere arbejdende aktiver
  • Fokus på værdi-drevet leveringer

Tilpas til Real-Time Information og lav en ny plan

I en planlagt, sekventiel proces, er planen den autoritative kilde for hvordan og hvornår arbejde skal laves. Dermed er det forventet, at man følger planen. Omvendt, med Scrum, tror vi på at uhæmmet tro på en flan vil ofte blinde os til det faktum, at planen måske er forkert.

Med en Scrum udviklingsindsats er vores mål ikke at tilpasse os til en plan, en up-front forudsigelse for hvordan tingene kommer til at gå. I stedet, så er vores mål at hurtigt lægge ny planer og tilpasse os til strømmen af økonomisk vigtig information som kontinuerligt kommer under udviklingsindsatsen.

Mål fremskridt ved at validere der du har lavet

Fremskridt under en sekventiel, traditionel projektledelse er demonstreret ved at færdiggøre en fase og få tilladelse til at gå over i næste fase. 

Som resultat, hvis hver fase starter og færdiggøres som forventet, så vil projektets måske virke som at fremskride meget godt. Men i sidste ende, så vil produktet vi har skabt ifølge planen måske levere meget mindre kundeværdi end forventet. 

Kan vi virkelig sige, at det har været en succes, hvis vi bliver færdige til tiden og efter budgettet, men fejler i forhold til at møde kundernes forventninger?

Med Scrum måler vi fremskridt ved at bygge features der virker og er valideret, som giver værdi og kan bruges til at validere vigtige antagelser. 

Det giver os feedback til at vide hvad det næste rigtige skridt er. I Scrum er det ikke om hvor meget arbejde vi starter, det er om hvilket arbejde vi færdiggør, som har værdi for kunderne. 

Fokusér på Værdi-drevet leveringer

Planlagt, sekventiel udvikling fokuserer på at følge processen. Ved dets struktur, vil integrationen og leveringen af features under sekventiel udvikling ske i slutningen af projektet. Med denne tilgang er der en risiko for, at vi vil løbe ud af ressourcer (tid eller penge) før vi leverer alt den vigtige værdi til vores kunder.

I forhold til værdi af traditionel projektledelse er planlægningen og dokument artifacts som producere en route til at levere features er i sig selv værdifulde. Hvis disse artifacts rent faktisk er værdifulde, så er de for det meste kun værdifulde for virksomhedens downstream proces og ikke for kunden. 

Og, hvis de er værdifulde for kunden, så træder denne værdi kun i kraft hvis det ønsket produkt ultimativt er leveret til kunden. Indtil det sker, så viser disse artifacts ikke nogen form for direkte kundeværdi.

Scrum, på den anden side, er en kundeværdi-fokuseret form for projektledelse. Den er baseret på en prioriteret, inkrementel model af levering hvor de features der skaber højest værdi kontinuerligt er bygget og leveret i næste iteration. Som result, så får kunderne et kontinuerligt flow af high-value features hurtigere.

I Scrum er værdi generet ved at levere virkende features til kunder ved at validere vigtige antagelser, eller ved at skaffe værdifuld viden. 

Med Scrum, så tror vi på at midlertidige features ikke giver nogen værdi til kunderne og kun er et middel til målet, hvis de selv ikke kan bruges til at genere vigtig feedback eller til at skaffe vigtig viden.

Performance

Der er specifikke performance-relateret karakteristikker vi forventer når vi bruger Scrum. Jeg vil her forklare tre agile principper der er relateret til dette:

  • Arbejd hurtigt men aldrig skynd dig
  • Byg kvalitet
  • Anvend minimalt nødvendig antal møder

Arbejd hurtigt men aldrig skynd dig

traditionel projektledelse tror på, at hvis vi følger planen og gør ting rigtigt første gang, så vil vi undgå dyr og tidskrævende ekstra arbejde. Det at gå fra skridt til skridt hurtigt er selvfølgelig ønskeligt, men det er ikke et principielt mål.

Med Scrum er et core goal mål at være tilpasningsparat og hurtig. Ved at være hurtig, leverer vi hurtigt, vi får feedback hurtigt, og vi får værdi i vores hænder af kunderne hurtigt. Det at lære og reagere hurtigt tillader virksomheden at generere omsætning og/eller reducere udgifter hurtigere.

Du skal dog ikke misforstå at arbejde hurtigt med at blive skyndt på. Med Scrum er tid altafgørende, men vi skynder os ikke for at få tingene gjort færdig. At gøre det vil overtræde Scrum princippet af bæredygtigt tempo – folk bør arbejde i et tempo, som de kan fortsætte i en forlænget periode. Derudover vil det at skynde sig højst sandsynligt komme med en pris af dårligere kvalitet.

Et eksempel kan nok hjælpe med at forstå forskellen mellem hurtig og at skynde sig. Man kan bruge Muay Thai som eksempel. Som det gælder for de fleste former af martial arts, så er Muay Thai præstationer forbedret med hurtighed. Det at være i stand til at bevæge sig hurtigt og præcist ved katas eller sparring forbedre nydelsen af sportsgrenen og resultaten. Hvis man dog skynder sig gennem bevægelserne med målet om at blive færdig, så påvirker det betydeligt hvor effektivt man er og kan resultere i seriøse kropsskader under sparring. Når man udfører Muay Thai, så skal du bevæge dig hurtigt, præcist og bevidst, mens du tilpasser dig situationen. Med andre ord, så skal du være hurtig, men aldrig skynde dig.

Byg kvalitet

Under traditionel projektledelse, så er igennem forsigtig, sekventiel udførsel af arbejde, at vi får et produkt af højere kvalitet. 

Men, vi kan faktisk ikke verificere denne kvalitet indtil vi tester det endelige produkt, hvilket sker i en sen fase af processen. Hvis tests bør indikere at kvaliteten er manglende, så skal vi ind i en dyr test-and-fix fase i forsøget på at teste kvaliteten vej ind i produktet. 

Derudover, fordi forskellige projektgrupper ofte arbejder på hver fase, så vil testholdet ofte blive set på at eje kvaliteten af resultatet.

Med Scrum, så er kvalitet ikke noget et testhold “tests in” i slutningen, der er noget en cross-functional projektgruppe ejer og kontinuerligt bygger ind og specificerer i hver sprint. 

Hver inkrement af værdi som er skabt er færdiggjort til et højt niveau af sikkerhed og har potentialet for at blive sat i produktion eller fragtet ud til kunder. Som resultat, så er behovet for betydelig sene tests for at tjekke kvalitet betydeligt reduceret.

Anvend minimalt nødvendig antal møder og meget dokumentation

Planlagte processer har ofte mange møder og meget dokumentation, og er dokument-fokuseret, process-tunge tilgange. En sideeffekt ved at Scrum er værdi-fokuseret er at meget lille fokus er lagt på process-fokuseret møder. 

Jeg mener ikke at alle møder og dokumentation er dårlige. Jeg referer til møder og dokumentation der er unødvendig formalitet. Nogle kalder det også for “process for the sake of process.” Sådan en møder har en udgift, men tilføjer lidt til intet værdi (med andre ord er det en form for spild).

Med Scrum er vores mål, at eliminere unødvendig formalitet. Derfor holder vi kun de møder der er vigtige og giver værdi. 

Selvfølgelig kan det være forskelligt fra organisation til organisation hvad der beskrives som værende minimalt nok. Og hvad der giver værdi.

Ofte er Scrum fokuseret på minimalt nødvendige møder og dokumentation misforstået til at betyde ting som at “Scrum er anti-møder/dokumentation.” Scrum er ikke anti-møder eller anti-dokumentation. 

I stedet, når Scrum bruges, så adopterer vi et økonomisk perspektiv og tænker nøje over hvilke dokumenter vi laver. Hvis vi skriver et dokument, som bare kan ligge på en hylde og ikke tilføjer værdi, så har vi spildt vores tid og penge på at lave et dødt dokument. Alle dokumenter er dog ikke døde. For eksempel vil vi sikkert skrive et dokument, hvis:

  • Det er en leveringsdygtig del af produktet (for eksempel installations instruktioner.)
  • Vores mål er at fange en vigtig diskussion, beslutning eller aftale, så vi i fremtiden har en klar hukommelse om hvad der blev diskuteret, besluttet eller aftalt.
  • Det er en high-value måde at hjælpe nye udviklere med at komme up to speed.
  • Der er et regulativt krav at et specielt dokument skal skrives (en pris for at lave forretning i en reguleret industri)

Hvad vi forsøger på at undgå er arbejde, som ikke tilføjer nogen short-term eller long-term økonomisk værdi. Med Scrum tror vi på at tid og penge er bedre brugt på at levere kundeværdi.

Konklusion

I dette indlæg fokuserede jeg på core agile principper – de fundamentale overbevisninger, som driver hvordan vi udvikler med Scrum. Da jeg gjorde det, sammenlignede jeg hvordan disse overbevisninger er forskellige fra de overbevisninger, som ligger under den traditionelle, planlagte, sekventielle udvikling.

Mit mål med at lave denne sammenligning er ikke at overbevise dig at waterfall metoden er dårlig og Scrum er god. I stedet er mit mål at illustrere at de underliggende overbevisninger af waterfall metoden gør den mere passende til en anden type problem end Scrum.

Du kan selv vurdere hvilken type problemer din organisationer håndtere og dermed hvilket redskab der er det mest passende at bruge.

Mest populære indlæg:

Mark Guldbrandsen
Mark Guldbrandsen
Certificeret projektleder med speciale i digitale projekter. Jeg deler her på bloggen mine erfaringer med projektledelse.
Følg os på LinkedIn her:

Download bøger og se webinar: