Scrum er et af de Agile frameworks og det mest benyttede på verdensplan. I denne guide får du en definition af Scrum med tilhørende begreber, teknikker og kurser. Den er både målrettet personer, der er nye inden for Scrum, og dem, der har flere års praktisk erfaring med Scrum.
Guide: Hvad er Scrum
Denne guide giver dig svar på, hvad Scrum er, og hvad Scrum betyder. Derudover gennemgår vi, hvem der bruger Scrum, hvad det er kræver, Scrum værdier, begreber, teknikker, tools og scaling samt relevante Scrum kurser at starte med.
- Hvad er Scrum?
- Hvem bruger Scrum og hvorfor?
- Hvad kræver Scrum?
- Scrum værdier
- Andre Scrum begreber og teknikker
- Scrum scaling
- Distributed Scrum
- Hvordan bliver jeg Scrum certificeret?
- Scrum kurser for begyndere
- Scrum kurser for mere erfarne
- Scrum tools
- Andre Agile metoder
- FAQ – Oftest stillede spørgsmål om Scrum
Online minikursus
- Få essensen i Scrum på under en time
Onlinekursus
- Forstå sammenhæng i Scrum
Hvad er Scrum?
Scrum er et framework, hvor et team arbejder med komplekse problemstillinger, hvor de produktivt og kreativt leverer produkter med den størst mulige værdi. Scrum er et af de Agile frameworks. At arbejde på en Agil måde, er et paradigmeskift fra en traditionel og kontrollerende proces til en empirisk proces, hvor man accepterer, at arbejdet påbegyndes uden at man kender alle detaljer på forhånd. I en empirisk proces er læring indbygget, så man både leverer langt større værdi af arbejdet og en konstant forbedre måden, det bliver udført på.
Scrum handler mere om at skabe en proces til at udvikle produkter, end om decideret produktudvikling.
Scrum etablerer en struktur til at arbejde på en iterativ og inkremental måde.
Scrum er defineret ved følgende elementer:
- Tre accountabilities
- Tre artifacts
- Fem events
- Samt commitments, regler og begreber, som binder dem sammen.
Inden for Scrum har alle elementer et helt specifikt formål og ingen af dem kan udelades. At Scrum er et framework, betyder, at det ikke beskriver alt, men derimod skaber rammerne indenfor hvilke mange forskellige Agile teknikker og processer kan være relevante at benytte. Jeff Sutherland og Ken Schwaber udviklede Scrum til Agile softwareudvikling i starten af 90’erne og præsenterede Scrum for første gang i1995 på OOPSLA konferencen i Austin, Texas (US). Scrum er defineret i Scrum Guiden.
Læs det første paper, som Ken Schwaber skrev og præsenterede i 1995: Scrum OOPSLA 1995_orginal-paper.
Hvem bruger Scrum og hvorfor?
Scrum kommer oprindeligt fra softwareudvikling tilbage i 90’erne (læs det første paper om Scrum fra 1995: [1]), men er i løbet af de sidste fem-ti år også blevet benyttet inden for mange andre områder, hvor man arbejder med vidensarbejde (komplekst arbejde) udført af tværfaglige teams. Specielt inden for de sidste fem år, er flere virksomheder, som ikke arbejder med agil udvikling af softwareprodukter, begyndt at organisere sig med Scrum teams. Det kan være virksomheder inden for medicinalbranchen eller virksomheder, som sælger produkter og services, som ikke indeholder software.
Scrum blev skabt ud fra erkendelsen af, at plandrevne tilgange ikke fungerer for softwareprojekter på grund af mange ukendte faktorer [2]. Efter at Ken og Jeff havde arbejdet med Scrum i deres respektive firmaer og offentliggjort det første paper, var en af de første organisationer som begyndte at bruge Scrum, NewsPage (news aggregators & publishers). De efterfølgende år var det primært organisationer inden for finans og og sundhedsområdet [3], som begyndte at arbejde med Scrum.
I takt med at verden ændrer sig hurtigere og hurtigere, at behov skifter, og at der ikke er samme forudsigelighed hos kunder/markeder/brugere, indser flere og flere virksomheder, at de skal organisere sig på en måde, hvor de langt bedre kan reagere på skiftende efterspørgsler og muligheder.
Den struktur og de kompetencer, der hidtil har fungeret og har bragt dem til det sted, de er i dag, er måske ikke fremadrettet den mest optimale måde at møde nye behov og hurtigere forandringer. Mange skifter til en struktur med Scrum teams, for hurtigere at kunne levere større værdi til deres brugere og kunder ved hurtigere at kunne få og reagere på feedback på beslutninger, antagelser og løsninger. Scrum implementerer en empirisk måde at arbejde på, som netop understøtter hurtigere feedback og levering af større værdi. Samtidig skaber Scrum en struktur, der giver langt større medarbejderinddragelse.
[1] Scrum OOPSLA 1995_orginal-paper
[2] https://www.scrum.org/resources/blog/week-celebration-scrum-turns-21
[3] https://kenschwaber.wordpress.com/2017/01/12/scrum-21/
Hvad kræver Scrum?
For at kunne sige at man bruger Scrum, er der nogle elementer, som skal være på plads. Helt overordnet skal man bruge de 11 grundlæggende elementer:
- Tre accountabilities (Product Owner, Developers, Scrum Master) – Scrum Team
- Tre artifacts (Product Backlog, Sprint Backlog, Increment)
- Fem events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective)
Derudover er en række commitments, regler og elementer, som binder det hele sammen.
- Product Goal: Commitment for Product Backlog
- Sprint Goal: Commitment for Sprint Backlog
- Definition of Done: Commitment for Increment
- Product Backlog Refinement: En løbende aktivitet for at gøre toppen af Product Backloggen Ready.
Hvis man blot bruger enkelte dele fra Scrum, er det ikke Scrum men inspireret af Scrum. Så det er altså ikke nok, at man f.eks. har et dagligt møde :-).
Scrum Team
I Scrum Teamet er der tre definerede accountabilities, som hver har forskellige ansvarsområder og fokuserer på forskellige ting.
Product Owner: Er ansvarlig for at maksimere værdi, repræsentere interessenter til Scrum teamet samt prioritere og vedligeholde Product Backloggen.
Developers: Er self-managing. Styrer deres eget arbejde inden for rammerne af et Sprint, samt leverer værdi i helt færdige (Done) Increments.
Scrum Master: Er ansvarlig for brug og forståelse af Scrum i både Scrum teamet og i organisationen, samt for at coache/facilitere/undervise, når der er brug for det.
Scrum artifatcs
I Scrum defineres tre artifacts, som hver gør arbejde synligt i forskellige stadier.
Product Backlog (PBL): Er én samlet og ordered (rangeret) liste med behov eller ønsker for et produkt. Det er en liste, som er transparent, forståelig og hele tiden skal vedligeholdes i forhold til feedback, læring og optimering af indhold frem mod overordnede mål. Product Owner har sidste ord i forhold til indhold og rangering af en Product Backlog. Typisk har Product Backlog Items (PBI) i toppen af en Product Backlog, antaget stor værdi, høj risiko eller afhængigheder. Product Backlog Items i toppen af en Product Backlog, skal også være klar (Ready), så de kan gøres færdige inden for et Sprint.
Sprint Backlog (SBL): Synliggør de PBI’er som Development Teamet har trukket ind i Sprintet, samt hvordan de planlægger at løse dem (typisk nedbrudt i opgaver eller mindre PBI’er). Sprint Backloggen ejes, oprettes og vedligeholdes kun af Development Teamet.
Increment. Er den eller de incrementale tilføjelser til produktet, som Development Teamet laver i hvert Sprint. Incrementet bygger videre på incrementer fra tidligere Sprints og skal være færdig og transparent i forhold til Scrum Teamets Definition of “Done”.
Scrum events
Inden for Scrum er der fem definerede events, som alle har forskellige inspect & adapt formål for at understøtte en empirisk måde at arbejde på.
Sprint: Er en Container event, som indeholder de fire formelle events. Det efterfølgende Sprint starter umiddelbart efter, at det foregående Sprint er afsluttet. Sprint og iterationer er det samme.
Sprint Planning: Det første formelle event i Sprintet, hvor hele Scrum Teamet deltager. Development Teamet trækker PBI’er ind, baseret på erfaringer fra tidligere Sprints. Et Sprint Goal udformes, til at styre Sprintet efter.
Daily Scrum: Er den daglige rytme, som får Development Teamet til at synkronisere og revidere fremdift af sit eget arbejde i Sprintet. Mange udfører Daily Scrum som et Daily stand up, selvom det ikke er en teknik som er krævet i Scrum.
Sprint Review: For at få feedback fra relevante interessenter på det eller de Increments, som er lavet i Sprintet. For hele Scrum Teamet og interessenter.
Sprint Retrospective: For at forbedre processer, samarbejde, teknikker, værktøjer os så videre i Scrum Teamet. Actions defineres og bør tages med i kommende Sprint. For hele Scrum Teamet.
Scrum værdier
Scrum skaber en empirisk struktur, som muliggør selvorganisering og aktivering af alle kompetencer og evner i et team. I Scrum er der fem definerede værdier, der beskriver mindset og adfærd i et Scrum Team.
Commitment
Man er committet til at arbejde sammen i et team og til at hjælpe hinanden til at opnå fælles mål. Man er committet til at gøre sit bedste inden for de givne rammer. Committed til at levere kvalitet og til konstant at være opmærksom på mulige forbedringer og prøve ting af, der giver læring og større værdi.
Focus
Sprintet i Scrum giver rammer, der skaber fokus til at udføre det arbejde, der har størst forventet værdi. Teamet fokuserer på det, der er klart til at blive arbejdet på. Og Teamet har fokus på at få løbende relevant feedback fra interessenter.
Openness
For at kunne arbejde empirisk og udføre inspect og adapt er det vigtigt, at der er åbenhed (openness) og gennemsigtighed både i forhold til hvad vi udfører, og hvordan vi gør det. Åbenhed bringer også problemer og misforståelser op til overfladen, så vi kan forstærke læringen og træffe nye og bedre beslutninger.
Respect
Vi har respekt (respect) for hinanden og for at arbejde i et Scrum Team. Vi har respekt for de forskellige personer og den tværfaglighed, der er i teamet. Vi har respekt for det ansvar, det indebærer at organisere sit eget arbejde inden for rammerne af et Sprint og at levere maksimal værdi.
Courage
Vi har mod (courage) til at fokusere på værdi og kun levere de løsninger, der er brug for. Vi har mod til at udfordre status quo og hele tiden lære, hvordan vi kan arbejde bedre sammen og med bedre teknikker og værktøjer.
Alle værdier understøtter Scrum teamet i at arbejde sammen på den bedst mulige måde og med et Agilt mindset.
Andre Scrum begreber og teknikker
Der findes en række begreber og teknikker, som kan bruges i forbindelse med Scrum, uden at de er obligatoriske i Scrum. Der er også nogle begreber, som kan give problemer sammen med Scrum, da der kan være nogle modsatrettede principper.
Her er en oversigt over nogle af de mest almindelige teknikker.
Teknikker som ofte bruges sammen med Scrum
User Stories
Er en Agil teknik til at arbejde med ønsker og krav. Den skaber en fælles forståelse, ved at facilitere en samtale ud fra den enkelte User Story. I en User Story har man typisk fokus på: Who, What og Why.
Scrum Tavle
Er i princippet blot en visualisering af en Sprint Backlog for det enkelte Development Team. Det kan være både være en fysisk med en tavle på en væg (anbefalet) eller en elektronisk, hvis teamets medlemmer sidder forskellige steder.
Planning Poker
Er en af de ældste Agile estimeringsteknikker, hvor hver person i et team har et sæt estimeringskort, hvorefter teamet sammen laver en relativ estimering af eksempelvis User Stories. Det er vigtigt, at der er et fælles udgangspunkt med nogle reference User Stories, og at der er en defineret Definition of “Done”.
Burndown chart
En burndown graf (burndown chart) er en teknik, som tidligere har været foreskrevet i Scrum til at måle og synliggøre fremdrift i et Sprint. Nu er det en mulig teknik, som et Development Team kan bruge til at måle fremdrift af arbejdet i et Sprint (Sprint backlog). En burndown graf kan også benyttes til at visualisere og måle fremdrift på releaseniveau, hvor den bruges på en afgrænset del af en Product Backlog.
Produkt relaterede begreber
Produkt
En konkret eller ikke-konkret vare eller service, der giver øjeblikkelig værdi til dets slutbrugere. Definerer rammer for Product Owner, Product Backlog og Increment.
Produkt Vision
En god Product Vision er inspirerende og udstikker en retning for både teams, organisation og andre uden for virksomheden. Den kan bruges til at validere prioritering og fokus.
Produkt Roadmap
Et Product Roadmap er i princippet det element, som forbinder Product Vision med Product Backloggen.
Det er vigtigt, at et Product Roadmap tydeliggør Product strategien, frem for at opremse en række features. Product Roadmap viser overordnet fokus, temaer og mål i forskellige perioder.
Releaseplan og Release planning
Release planning er planlægning og prioritering i forhold til flere Sprints og/eller flere teams. En Releaseplan vil typisk visualisere en planlægningshorisont, som er længere end et Sprint og indikerer retning og mål.
Minimum Viable Product (MVP)
MVP er et af de begreber, som rigtig mange virksomheder er begyndt at bruge. Ofte bruges det ikke i den oprindelige betydning fra Lean Startup (Eric Ries), hvor formålet med en MVP er at få valideret læring. Man har en antagelse, som en MVP kan få valideret. Mange bruger MVP til at lave den mest skrabede release, som kan sendes ud til brugerne uden tanke på læring.
Begreber som ofte giver udfordringer i kombination med Scrum
Vandfaldsmodel
Hvis en del af organisationen eller dens leverandører bruger en traditionel vandfaldsmodel, bliver det svært at få Scrum til at virke rigtig godt. Hvis det er rammerne, vi p.t. arbejder inden for, er det meget vigtigt at få defineret en struktur, hvor der ofte synkroniseres mellem den del, som arbejder med Scrum, og den del som arbejder vandfaldsorienteret. Og at være forberedt på, at der akkumuleres betydelige risici.
Agile projekter
Når man snakker om Agile projekter eller agil projektledelse, afspejler det ofte en organisatorisk struktur, som også påvirkes af processer for både prioritering og budgettering. Det kan være svært at være Product Owner i en struktur, som er mere projektorienteret. En Product Owner skal have et Product mindset, som mere er på hele produktets levetid, og ikke blot inden for et kortere projekt.
Scrum scaling
Skalering med Scrum er, når to eller flere Scrum teams arbejder sammen på samme produkt. Her kan en struktur med skaleret Scrum hjælpe dem med at arbejde sammen på den bedst mulige måde. Selv når flere teams arbejder sammen, er det stadigvæk Scrum.
En god, kort artikel om Scaling af Cesario Ramos: “Scale Your Product Not Your Scrum”. Avoid Copy-Paste scaling.
Skalering med Nexus
Nexus er et Scrum skaleringsframework fra Ken Schwaber og Scrum.org. Det er tænkt som den minimale struktur, der skal til for, at teams kan arbejde sammen.
Nexus (n): en relation eller forbindelse mellem mennesker eller ting.
- The Nexus Guide – https://www.scrum.org/resources/nexus-guide
- Blog Why We Need Nexus – https://www.scrum.org/resources/blog/why-we-need-nexus
Skalering med LeSS
LeSS er en udvidet version af one-team Scrum. LeSS fokuserer på, hvordan teams kan bruge Scrum til at skabe produkter, og hvordan ledere kan strukturere deres organisation med mindre kompleksitet. LeSS fremsætter et minimalistisk regelsæt, som teams/organisationer skal følge (f.eks. en Product Backlog til flere teams).
Frem for at stille spørgsmålet: “Hvordan kan vi skalere Agile på tværs af vores store, traditionelle og komplekse organisation?”
Bør man spørge: “Hvordan kan vi forenkle det unødvendigt store og komplekse organisatoriske design og være agil frem for at gøre agil (be agile rather than do agile)?”
LeSS reducerer den organisatoriske kompleksitet, opløser unødvendige komplekse organisatoriske løsninger så de kan løses på mere enkle måder.
- Læs mere om LeSS online på: https://less.works/
Skalering med SAFe
I modsætning til skalering med f.eks. Nexus eller LeSS er SAFe mere en metodik (ligesom Rational Unified Process, RUP, hvor nogle af de samme personer er gået over til SAFe). Det er altså en række forskellige teknikker, strukturer, roller osv., som man selv skal vælge imellem.
For nogle virksomheder kan SAFe være “brækjernet”, som kan få dem i gang. Flere har prøvet forgæves at få etableret Scrum teams tidligere (det snakker de sjældent om). For virksomheder, som allerede har fået nogle Scrum Teams til at fungere, vil SAFe ofte være et tilbageskridt. Jeg hører dog flere og flere på globalt plan, som fortæller at steder hvor SAFe har været brugt gennem flere år, begynder at bevæge sig mod LeSS eller Nexus. Ofte vil denne ændring kunne reducere en større mængde organisatorisk kompleksitet.
Læs mere om SAFe på https://www.scaledagileframework.com/
Typiske problemer med skalering
Nogle af de helt store problemer med skalering med Scrum er afhængigheder mellem forskellige teams, løbende integration af deres arbejde og udfordringer med at få helt Done Increments.
Mange har skrevet kritiske artikler om SAFe, flere af dem er samlet f.eks. her: https://dragilefant.com/2018/07/01/scaling-agile-safe-and-sound/
Distributed Scrum
Distributed Scrum er, når et Scrum team er placeret på flere forskellige lokationer eller når flere Scrum teams, som arbejder sammen, er placeret på flere forskellige lokationer. Det er ikke let, og der er en masse ekstra elementer, teknikker, infrastruktur mv., som skal være på plads. At få et distribueret setup med Scrum til at virke fornuftigt, kræver en langsigtet strategi fra organisationens side samt en masse vilje og fokus over flere år. Man får desværre ikke de store kortsigtede resultater, som de fleste håber på.
Jeg har holdt flere præsentationer om at få Distributed Scrum til at virke. Flere af dem kan ses på https://www.slideshare.net/MadsTroelsHansen/presentations, bla.:
- From CMMI and Isolation To Scrum, Agile, Lean And Collaboration – (Xpday 2009 London, Agile 2009 Chicago, Agile Eastern Europe 2009)
- Patterns For Successful Distributed Development – (Xpday 2009 London)
- Offshore Software Patterns – (Agile Lean Europe 2011)
- Distributed Scrum – (Agile Eastern Europe 2012)
- Balancing and growing agile testing with high productive distributed teams – (Agile Testing Days 2012)
- Do’s and don’ts for distributed Scrum – (GOTO Aarhus 2013)
I 2008 skrev jeg sammen med Hans Baggesen en experience report til Agile 2009 konferencen i Chicago: From CMMI and Isolation to Scrum, Agile, Lean and collaboration_Agile2009
Hvordan bliver jeg Scrum certificeret?
På verdensplan er der to to primære Scrum organisationer, som udbyder Scrum certificeringer, Scrum.org og Scrum Alliance, og begge har Ken Schwaber været med til at stifte. Først Scrum Alliance i 2001 og efterfølgende i 2009 Scrum.org (se mere om hvorfor Scrum.org). Personligt har jeg valgt at blive Scrum træner hos Scrum.org (PST, Professional Scrum Trainer), da jeg fuldt ud kan stå inde for deres mindset, principper, værdier og struktur, som jeg kan stå inde for. Overvejer du selv at blive Professional Scrum Trainer, så læs mere her: https://www.scrum.org/become-professional-scrum-trainer
Det kan være svært at finde rundt i alle de forskellige udbud af Scrum kurser der findes på markedet. Derudover har mange firmaere selv udviklet deres egne Scrum kurser, som ofte har samme ordlyd som nogle af de officielle kurser fra Scrum.org eller Scrum Alliance.
Hos Scrum.org har alle kurser tilknyttet en certificeringstest, som tages efter kurset, hvor man bliver registreret hos Scrum.org. Som deltager får man et password til en tilknyttet test og hvis passwordet bruges inden for 14 dage efter kurset, og man ikke består, får man automatisk et andet gratis forsøg. Hvis passwordet ikke bruges inden for 14 dage efter kurset, vil det stadigvæk være gyldigt, men så får man ikke endnu et gratis forsøg, hvis man ikke består i første omgang. Når man først har bestået certificeringen, er den gyldig på ubestemt tid. Den skal ikke fornys og der skal heller ikke betales mere for at beholde den. Holdningen er, at der hellere skal være fokus på yderligere læring og eventuelt andre kurser end på at betale for at en gammel certificering.
Scrum kurser for begyndere
Hvis jeg ikke har været på Scrum kursus før, hvor skal jeg så starte? Jeg har lavet en oversigt med en lille guide til Mit første Scrum Kursus.
Hvilke kurser er gode at starte med?
Applying Professional Scrum (APS) er et 2-dags kursus, hvor du lærer Scrum på en meget interaktiv måde. Kurset er en blanding af undervisning og øvelser, hvor du selv prøver at bruge Scrum til at bygge færdige produkter. Du lærer om de forskellige mekanismer, regler og roller i Scrum-frameworket, og hvordan de passer sammen. APS kurset er en effektiv måde at lære om Scrum, og hvordan man arbejder agilt i et Scrum-team.
- Grundig introduktion til Scrum
- Inkluderer op til to forsøg til Scrum Master certification (PSM I)
- Du har typisk ikke praktisk erfaring med Scrum
Scrum.org Professional Scrum Master (PSM) kurset er et 2 dags kursus som dækker principper og den (empiriske) proces teori som underbygger mekanismer, regler og roller i Scrum frameworket. Du lærer om mindset til servant-leadership, som kan hjælpe en Scrum Master til at blive mere effektiv. Inklusiv op til to forsøg til certificering til Professional Scrum Master I.
- Hvis du allerede arbejder eller skal arbejde som Scrum Master
- Hvis du arbejder i et Scrum Team
- Du er måske leder og vil gerne have en bedre forståelse af Scrum
- Du har minimum et halvt års praktisk erfaring med Scrum
- Inkluderer op til to forsøg til Scrum Master certification (PSM I)
- Er det primære Scrum Master kursus at starte med
Scrum.org Professional Scrum Product Owner (PSPO) er det officielle Scrum.org 2-dags Scrum Product Owner kursus, som fokuserer på, hvordan man maksimerer værdien af softwareprodukter og -systemer. Scrum Product Ownership kræver mere end blot viden om at skrive krav eller styre en Product Backlog.
Professional Scrum Product Owners skal have kendskab til alt, der kan påvirke værdi for deres produkter.
- Hvis du allerede arbejder eller skal arbejde som Product Owner
- Hvis du er Scrum Master og vil lære mere om Product Ownership, så du kan coache Product Ownere
- Hvis du er leder og vil lære mere om Product Ownership
- Inkluderer op til to forsøg til Scrum Product Owner certification (PSPO I)
- Er det primære Product Owner kursus at starte med
Scrum kurser for mere erfarne
Du har praktisk erfaring med Scrum og måske bestået PSM I eller PSPO I certificeringen. Så vil kurser som PSK, PSM-II, PSPO-A, SPS, PSU være oplagte at tage for at lære mere. Se også en guide til: Mit næste Scrum kursus
Scrum.org Professional Scrum Master II (PSM II) er et udvidet kursus, som giver Scrum Masters ekstra ballast i deres professionelle udvikling. Efter kurset har deltagerne mulighed for at tage en test for at få den anerkendte PSM II certificering. Dette kursus giver dig mulighed for at gå mere i dybden med mere avancerede Scrum-områder og med rollen som Scrum Master.
For at yde service til både organisation, ledere og teams
Scrum.org Professional Scrum with Kanban (PSK) er et 2-dags kursus, som lærer folk, der praktiserer Scrum, også at anvende Kanban i deres arbejde. Gennem teori, casestudier og praktiske øvelser får deltagerne forståelse for vigtigheden af gennemsigtighed og flow i forbindelse med Scrum.
På dette kursus lærer deltagerne, hvordan Scrum Teams kan tilføre elementer fra Kanban uden at ændre Scrum.
Scrum.org Professional Agile Leadership Essentials (PAL-E) er et 2-dags kursus, som skaber grundlaget for den rolle, ledere spiller for en vellykket agil transformation i en organisation.
God ledelse er afgørende for en organisations succes, men den rolle, lederen spiller i en agil organisation, kan være temmelig anderledes, end man er vant til.
For at lære modeller, principper og teknikker til de grundlæggende Scrum Master stances
Uddannelsen Professional Agile Coach (PAC) giver dig de kompetencer og værktøjer, der skal til for at arbejde som Scrum Master eller Agile Coach i en professionel kontekst. At være Agile Coach er en kompleks rolle, som kræver en solid ballast og ikke mindst intensiv træning og præcis feedback.
Scrum tools
Der findes et utal af Scrum tools og Agile tools og det kan være svært at finde rundt i dem.
Som udgangspunkt er et bestemt tool ikke bedre end et andet.
To vigtige spørgsmål, man bør begynde med at stille sig selv, er:
- Hvad skal dette tool hjælpe os med?
- Understøtter toolet vores proces, eller begrænser det os i at lave forbedringer og ændringer i processen?
Nogle af de mest benyttede tools i Danmark i forbindelse med Scrum er:
- Jira
- Microsoft Azure DevOps (TFS)
- Trello
- Version One
- Rally
I min egen virksomhed og når jeg samarbejder med forskellige virksomheder bruger jeg primært Trello, Slack (til kommunikation) og masser af visualisering med post-it notes mv.
Version One har i deres årlige rapport, State of Agile, en samling af de primære tools brugt at virksomheder. Se State of Agile Report, 2019 udgaven (13th), hvor der også er en masser af anden information.
Andre Agile metoder
Der findes en lang række Agile teknikker og metoder, som med fordel kan bruges sammen med Scrum.
Kanban
Kanban stammer fra det japanske ord 看板 , som er en sammensætning af “kan” (visuelt kort, som repræsentere noget arbejde) og “ban” (et visuel signal for nuværende stadie). Kanban er en af de grundlæggende elementer i Lean (TPS). Et kanbansystem, er også et pull-baseret planlægningssystem til just-in-time fremstilling.
Kanban teknikker og principper bliver også anvendt inden for vidensarbejde og Kanban Guide for Scrum Teams beskriver, hvordan det med stor fordel kan bruges af et Scrum team. Her defineres Kanban som:
Kanban (n): En strategi til at optimere værd flow via en proces, som bruger et visuelt work-in-progress begrænset pull system.
I Scrum.org kurset Professional Scrum with Kanban (PSK), lærer man, hvordan Scrum og Kanban med fordel kan benyttes sammen.
Extreme Programming (XP)
Extreme Programmering (XP) er et softwareudviklings-framework med en række teknikker, der er direkte målrettet softwareudvikling. Når et Scrum Team arbejder med software produkter, er det fordelagtigt at benytte mange af de forskellige teknikker og begreber fra XP.
Se mere på http://www.extremeprogramming.org/ og https://www.agilealliance.org/glossary/xp/
FAQ – Oftest stillede spørgsmål om Scrum
Nedenfor er korte svar på for nogle af de oftest stillede spørgsmål om Scrum.
Hvorfor bruge Scrum?
Scrum er udviklet til at styre komplekst arbejde, altså arbejde, hvor ikke alt er simpelt og forudsigeligt (vidensarbejde). Så hvis arbejdet indeholder noget ukendt og skal udføres af flere personer med forskellige kompencer (et team), kan Scrum være relevant at bruge. Læs mere om Scrum her.
Hvem bruger Scrum?
Scrum kommer oprindeligt fra softwareudvikling tilbage i 90’erne (læs det første paper om Scrum fra 1995: [1]), men er i løbet af de sidste fem-ti år også blevet benyttet inden for mange andre områder, hvor man arbejder med vidensarbejde (komplekst arbejde) udført af tværfaglige teams. Specielt inden for de sidste fem år, er flere virksomheder, som ikke arbejder med udvikling af softwareprodukter, begyndt at organisere sig med Scrum teams. Det kan være virksomheder inden for medicinalbranchen eller virksomheder, som sælger produkter og services, som ikke indeholder software. Læs mere her.
Hvad er forskellen på Scrum og Kanban?
Scrum er et framework, som også indeholder en struktur og forskellige roller, hvor Kanban mere beskriver teknikker og principper. Læs mere om Kanban.
Hvad er en Scrum Master?
En Scrum Master er ansvarlig for, at Scrum bliver brugt og forstået korrekt i både Scrum Teamet og organisationen. Scrum Masteren er ansvarlig for at coache, facilitere og undervise, hvor det er nødvendigt, og skal facilitere fjernelse af forhindringer (Impediments) for Scrum Teamet. Scrum Masteren har ikke direkte ansvar for selve arbejdet, det ligger hos henholdsvis Product Owner og Development Teamet. Læs mere om hvad er en Scrum Master
Hvad er Scrum projektledelse?
Når man taler om Scrum projektledelse, er det typisk fordi organisationen har en governance model, som indeholder projekter. I princippet kan et Sprint betragtes som et projekt med maksimum længde på en måned. Læs mere her https://scrumguides.org/scrum-guide.html#events-sprint
Hvad er Scrum?
Scrum er et framework, hvor et team arbejder med komplekse problemstillinger, mens de produktivt og kreativt leverer produkter med den størst mulige værdi. Læs mere her.
Hvad betyder Scrum?
Scrum er ikke en forkortelse skrives som “Scrum” og ikke som “SCRUM”. Ordet stammer oprindeligt fra sportsgrenen rugby og bliver brugt i en artikel i Harward Business Review fra 1986 af Hirotaka Takeuchi og Ikujiro Nonaka: “The New New Product Development Game”. Den artikel var bla. inspiration for Ken Schwaber og Jeff Sutherland, da de udviklede Scrum og præsenterede Scrum i 1995. Læs mere her