Scrum.org kurser

Scrum er et af de Agile framework og den mest benyttede på verdensplan. I denne guide får du en definition af Scrum med tilknyttede begreber, teknikker samt kurser, og er målrettet personer, som er nye inden for Scrum eller har flere års praktisk erfaring med Scrum.

 

 

 

Guide: Hvad er Scrum

Her i denne guide finder du svaret på, hvad Scrum er og hvad Scrum betyder. Derudover gennemgår vi hvem bruger Scrum, hvad der er krævet af Scrum, værdier, begreber, teknikker, tools, scaling samt hvilke Scrum kurser, der kan være relevant at tage.

  1. Hvad er Scrum?
  2. Hvem bruger Scrum og hvorfor?
  3. Hvad er krævet af Scrum?
  4. Scrum værdier
  5. Andre Scrum begreber og teknikker
  6. Scrum Scaling
  7. Distributed Scrum
  8. Hvordan bliver jeg Scrum certificeret?
  9. Scrum kurser for begyndere
  10. Scrum kurser for mere erfarne
  11. Scrum tools
  12. Andre agile metoder
  13. FAQ – Oftest stillede spørgsmål til Scrum

Hvad er Scrum?

Scrum er et framework, hvor et team arbejder med komplekse problemstillinger, mens de produktivt og kreativt leverer produkter med den højest mulige værdi. Scrum er et af de Agile framework. At arbejde på en Agil måde, er et paradigmeskift fra en traditionel og kontrollerende proces til en empirisk proces, hvor man acceptere at arbejdet begyndes uden at kende alle detaljer på forhånd. I en empirisk process er læring indbygget, så man både leverer langt højere værdi af arbejdet og en konstant forbedrende måde at udføre det på.

Scrum er defineret ved følgende elementer

I Scrum har alle elementer et helt specifikt formål og kan ikke undlades. At Scrum er et Framework, betyder at det ikke beskriver alt, men skaber rammerne indenfor hvilket mange forskellige Agile teknikker og processer kan være relevamte at benytte. Jeff Sutherland og Ken Schwaber udviklede Scrum for Agile software udvikling i starten af 90erne 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 software udvikling tilbage i 90’erne (læs det første paper om Scrum fra 1995: [1]), men er i løbet af de sidste 5-10 år også 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 5 år, er flere  virksomheder, som ikke arbejder med udvikling af software produkter, begyndt at organisere sig med Scrum teams. Det kan være virksomheder inden for farma, medical eller virksomheder som arbejder med forskellige former for services eller ikke software produkter.

Scrum blev skabt ud fra erkendelsen af, at plandrevne tilgange ikke fungerer for softwareprojekter på grund af den store mængde af usikkerhed [2]. Efter 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 finance og healthcare [3].

I takt med at verden ændrer sig hurtigere og hurtigere, behov skifter og der er ikke 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 har fungeret (måske) og bragt dem til hvor de er i dag, er ikke den mest optimale fremadrettet. Mange skrifter til en struktur med Scrum teams, for hurtigere at kunne levere højere værdi til deres brugere og kunder ved at få hurtigere feedback på beslutninger, antagelser og løsninger og kunne reagere på denne feedback. Scrum implementerer en empirisk måde at arbejde på, som netop understøtter hurtigere feedback, levering af højere værdi, samt en struktur, som involvere langt højere medarbejderinvolvering.

[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 er krævet af 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:

  • 3 Roller (Product Owner, Development Team, Scrum Master)
  • 3 Artifacts (Product Backlog, Sprint Backlog, Increment)
  • 5 Events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective)

Derudover er forskellige regler og nogle yderligere dele, som binder det hele sammen (bla. Definition of “Done”, Product Backlog refinement, Ready og Sprint Goal).

Hvis man blot bruger enkelte dele fra Scrum er det ikke Scrum, men inspireret af Scrum. Så det er altså ikke nok at man har et dagligt møde :-).

Scrum Framework

Scrum Roller

Scrum har tre definerede roller, som hver har forskellige ansvarsområder og fokuserer på forskellige ting.

Product Owner: Er ansvarlig for at maksimere værdi, repræsentere interessenter ind til Scrum teamet samt prioritere og vedligeholde Product Backloggen.

Development Team: Er ansvarlig for at arbejde som et selv-organiseret team, som selv styrer eget arbejde inden for rammerne af Scrum samt levere værdi i helt færdige (Done) Increments.

Scrum Master: Er ansvarlig for brug og forståelse af Scrum i både Scrum team og organisationen, samt coache/facilitere/undervise når der er brug for det.

Scrum Artifatcs

I Scrum defineres tre Artifacts, som hver gør arbejde synigt i forskellige tilstande.

Product Backlog (PBL): Er én samlet 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. Produuct Owner har sidste ord ift. indhold og rangering og typisk er Product Backlog Items (PBI) med antaget høj værdi, stor risk eller afhængigheder gode kandidater til at ligge i toppen af PBL’en.

Sprint Backlog (SBL): Synliggør de PBI’er som Development Teamet har trukket ind i Sprintet, samt en nedbrydning i hvordan Development Teamet planlægger at løse dem (typisk 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 som minimum har et af hvert Sprint. Incrementet bygger oven på increments fra tidligere Sprints og skal være færdig og transparent ift. Scrum Teamets Definition of “Done”.

 

Scrum Events

i 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. Efterfølgende Sprint starter lige efter det nuværende Sprint er afsluttet.

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 laves, til at guide Sprintet.

Daily Scrum: For Development Teamet til at inspecere deres eget arbejde og er et heartbeat synkronisering i Sprintet.

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 osv. i Scrum Teamet. Minimum en action tages med i næste Sprint. For hele Scrum Teamet.

 

Scrum værdier

Scrum skaber en emperisk struktur som muliggør selvorganisering og aktivering af alle kompetencer og evner i et team. I Scrum er der 5 definerede værdier, der beskriver tankesæt og adfærd i et Scrum team. Scrum værdier

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 det bedste man kan inden for de give rammer. Committed til at levere kvalitet og til at konstant at se efter forbedringer og udføre eksperimenter, der giver læring og højere værdi.

Focus

Sprinted i Scrum giver rammer, der skaber fokus til at udføre det arbejde der har forventet højest værdi. Teamet fokuserer på det som er klart til at blive arbejdet på og afslutter det i mindre dele.

Openness

For at kunne arbejde Empirisk og udføre Inspect og Adapt er det vigtigt at der er Openness og transparent i både hvad vi udfører og hvordan det gøres. Openness bringer også problemer og misforståelser til overfladen, så vi kan accellere læring og tage nye bedre beslutninger.

Respect

Vi har respekt 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 er at organisere eget arbejde inden for rammerne af et Sprint og levere maksimal værdi.

Courage

Vi har mod (courage) til at fokusere på værdi og ikke levere løsninger som der ikke er brug for. Vi har mod til at udfordre status-quo og hele tiden lære hvordan vi kan arbejde bedre sammen go med bedre teknikker og værktøjer.

Alle værdier understøtter Scrum teamet i at arbejde sammen på bedst mulig måde og understøtter et Agilt mindset.

 

Andre Scrum begreber og teknikker

Der findes en masse begreber og teknikker som kan bruges i forbindelse med Scrum, uden at det er obligatorisk i Scrum. Der er også nogle begreber, som kan give problemer sammen med Scrum, da der kan være nogle modsat rettede principper.

Her er en oversigt over nogle af de mest almindelige.

Teknikker som ofte bruges sammen med Scrum

User Stories

Er en Agil teknik til at arbejde med ønsker og krav, som faciliterer at der opnås en fælles forståelse, ved at snakke 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 fysisk med en tavle på en væg (anbefalet) eller elektronisk, hvis team medlemmer sidder på forskellige lokationer.

Planning Poker

Er en af de ældste Agile estimeringsteknikker, hvor et team hver har et sæt estimeringskort og sammen laver en relativ estimering af f.eks. User Stories. Vigtigt at der er en fælles baseline med nogle reference User Stories og der er en defineret Definition of “Done”.

Produkt relaterede begreber

Produkt Vision

En god Product Vision er inspirerende og angiver 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 tydliggør Product strategien, fremfor at opliste en række features. Product Roadmap viser overordnet fokus, temaer, mål i forskellige perioder.

Minimum Viable Product (MVP)

MVP er et af de begreber, som rigtig mange virksomheder er begyndt at bruge. Ofte bruges det ikke, som oprindeligt defineret fra Lean Startup (Eric Ries), hvor formålet med en MVP er at få valideret lærring. 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ærring.

mvp

Begreber som ofte giver udfordringer i kombination med Scrum

Vandfaldsmodel

Hvis en del af organisationen eller leverandører bruger en traditionel vandfaldsmodel, bliver det svært at få Scrum til at virke rigtig godt. Hvis det er rammerne men pt. arbejder indenfor, er det meget vigtigt at få defineret en struktur, hvor der synkroniseres ofte mellem den del som arbejder med Scrum og den del som arbejder vandfalsorienteret. Og være forberedt på at der akkumuleres en stor mænge risk over tid.

Agile projekter

Når man snakke om Agile projekter, afspejler det ofte en organisatorisk struktur, som også afspejler både prioritering og budgetering. Det kan være 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 af Scaling af Cesario Ramos: “Scale Your Product Not Your Scrum”.

Skalering med Nexus

Nexus er skaleringsworket fra Ken Schwaber og Scrum.org. Det er tænkt som den minimale struktur, som kan hjælpe teams med at arbejde sammen.

Nexus (n): en relation eller forbindelse mellem mennesker eller ting.

 

Nexus-scrum

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 forme deres organisation som sådan. LeSS fremsætter et minimalistisk regelsæt, som teams/organisationer skal følge (fx enkeltprodukts-backlog til flere teams).

Frem for at stille spørgsmålet: “How can we apply agile at scale in our big complex organization?”

Bør man spørge om: “How can we simplify the unnecessarily big and complex organizational design, and be agile
rather than do agile?”

LeSS descales organizational complexity, dissolving unnecessary complex organizational solutions, and solving in simpler ways.

less-framework

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 stor samling af en masse 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. I konsulentbranchen er der så mange penge i SAFe, at det nok kommer til at være stort i mange år endnu. Jeg hører dog flere og flere på globalt plan, som fortæller at steder hvor SAFe har været brugt i flere år, begynder skifte til LeSS eller Nexus for at komme videre. Ofte er der en større mængde organisatorisk kompleksitet, som kan reduceres.

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 derres arbejde og udfordringer med at få helt Done Increments.

Forskellige artikler og information om Scaling: Scaling agile safe and sound 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 lokationer eller når flere Scrum teams, som arbejder sammen er placeret på 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 organisationen og en masse vilje og fokus over flere år. Mån 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 Cmm Iand Isolation To Scrum Agile Lean And Collaboration – (Xpday 2009 London, Agile 2009 Chicargo, AgileEE 2009)
  • Patterns For Successful Distributed Development – (Xpday 2009 London)
  • Offshore Software Patterns – (Agile Lean Europe 2011)
  • Distributed Scrum – (AgileEE 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 Chicargo: From CMMI and Isolation to Scrum, Agile, Lean and collaboration_Agile2009

 

 

Hvordan bliver jeg Scrum certificeret?

Helt overordnet er der globalt 2 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). Jeg selv har valgt at blive Scrum træner hos Scrum.org (PST, Professional Scrum Trainer), da de på alle måder understøttede 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

 

Scrum.org

 

 

Det kan være svært at finde rundt i alle de forskellige udbud af Scrum kurser der findes på markedet, og mange firmaere har 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 test for certificering, 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 2. forsøg. Hvis 1. password ikke bruges inden for 14 dage efter kurset, vil det stadigvæk være gyldigt, men der er ikke et 2. gratis forsøg, hvis man ikke består. Når man først har bestået certificeringen, vil den gælde for altid og skal ikke fornys og der skal ikke betales ekstra for at holde den i live. Princippet er her at der hellere skal være fokus på yderligere læring og evt. andre kurser, fremfor 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?

Professional Scrum Foundations (PSF)

  • Grundig introduktion til Scrum
  • Du har typisk ikke praktisk erfaring med Scrum

Professional Scrum Master (PSM)

  • 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 min 1/2 års praktisk erfaring med Scrum

Professional Scrum Product Owner (PSPO)

  • 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

 

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 tools

Der findes et utal af Scrum tools, agile tools og det kan være svært at finde rundt i dem.

Der er ikke nogle der er klart bedre end andre, og to spørgsmål man skal stille sig fra starten er:

  1. Hvad skal det her tool hjælpe os med?
  2. Understøtter toolet vores proces, eller begrænset det os i at lave forbedringer og ændringer i processen?

Nogle af de ofte 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.

Andre agile metoder

Der findes en lang række Agile teknikker og metoder, som med fordel kan bruges sammen med Scrum.

Kanban

Kanban (看板) er oprindeligt et japansk ord og har været en af de grundlæggende elementer i Lean (TPS). Kanban er et planlægningssystem til lean manufacturing og just-in-time fremstilling.

Inden for vidensarbejde er Kanban teknikker og principper også brugt og Kanban Guide for Scrum Teams beskriver, hvordan det med stor fordel kan bruges af et Scrum team. Her defineres Kanban som:

Kanban (n): a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system.

I Scrum.org kurset Professional Scrum with Kanban (PSK), lærer man hvordan Scrum og Kanban med stor værdi kan benyttes sammen

Extreme Programming (XP)

Extreme Programmering (XP) er et softwareudviklings framework, som har en række teknikker, der direkte er målrettet softwareudvikling. Når et Scrum Team arbejder med software produkter, er der stor fordel ved 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 til Scrum

I nedenstående er korte beskrivelser for nogle af de oftest stillede spørgsmål til Scrum.

Hvad betyder Scrum?

Scrum er ikke en forkortelse og staves ikke med store bogstaver. Ordet stammer oprindeligt spillet rugby og benyttet i en artikel fra Harward Business Review fra 1986 af Hirotaka Takeuchi og Ikujiro Nonaka: “The New New Product Development Game”. Den artikel var bla. inspiration til Ken Schwaber og Jeff Sutherland, da de lavede Scrum og præsenterede Scrum i 1995.

Hvad er Scrum?

Scrum er et framework, hvor et team arbejder med komplekse problemstillinger, mens de produktivt og kreativt leverer produkter med den højest mulige værdi. Læs mere her.

Hvad er Scrum projektledelse?

Når man snakker om Scrum projektledelse, er det typisk fordi organisationen har en governance model, som indeholder projekter. I princippet kan et Sprint betragtes som et project med maksimum længde på en måned. Læs mere her https://scrumguides.org/scrum-guide.html#events-sprint

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, undervise, hvor det er nødvendigt og skal facilitere fjernelse af impediments for Scrum Teamet. Scrum Masteren har ikke indholdsmæssig ansvar for arbejdet, det ligger hhv. hos Product Owner og i Development Teamet på forskellige niveauer.

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.

Hvem bruger Scrum?

Scrum kommer oprindeligt fra software udvikling tilbage i 90’erne, men er i løbet af de sidste 5-10 år også 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 5 år, er flere  virksomheder, som ikke arbejder med udvikling af software produkter, begyndt at organisere sig med Scrum teams. Det kan være virksomheder inden for farma, medical eller virksomheder som arbejder med forskellige former for services eller ikke software produkter. Læs mere her.

Hvorfor bruge Scrum?

Scrum er designet 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.