Agile Scrum – Introduktion til metoden

Op igennem 90’erne oplevede industrien en stigende tendens, hvor mange udviklingsprojekter blev påvirket af ændringer i krav og uforudsigelig kompleksitet. Tendensen betød, at der opstod et behov for at skabe en balance mellem fleksibilitet og disciplin i udviklingen. Det blev grundlaget for den agile udviklingsmetode også kaldet Scrum. Introduktion til Scrum Agile Scrum blev beskrevet […]

Op igennem 90’erne oplevede industrien en stigende tendens, hvor mange udviklingsprojekter blev påvirket af ændringer i krav og uforudsigelig kompleksitet. Tendensen betød, at der opstod et behov for at skabe en balance mellem fleksibilitet og disciplin i udviklingen. Det blev grundlaget for den agile udviklingsmetode også kaldet Scrum.

Introduktion til Scrum

Agile Scrum blev beskrevet for første gang i en udviklingssammenhæng i 1986, hvor de to professorer Hirotaka Takeuchi og Ikujiro Nonaka, i en berømt artikel fra Harvard Business Review, beskrev de mest succesfulde produktudviklings-projekter i Japan på det tidspunkt. Projekterne byggede på 4 principper, som står i skærende kontrast til den ”klassiske” lineære udvikling:

  • Individer og samarbejde frem for processer og værktøjer
  • Velfungerende produkter fremfor omfattende dokumentation
  • Samarbejde med kunden frem for kontraktforhandlinger
  • Håndtering af forandringer frem for fastholdelse af en plan

Omdrejningspunktet i udviklingsmetoden er kortere ”time to market” og tættere samarbejde. Scrum er således en mere lærende eller eksperimentel tilgang, hvor man typisk opdeler udviklingen i mindre forløb med hver sin delleverance, som i højere grad tillader ændringer, samt sikrer hurtigere fremdrift. Forløbene indeholder de almindelige udviklingsaktiviteter: analyse, design, konstruktion og test.

Beskrivelse af modellen

Agile Scrum strukturerer udvikling i små arbejdscyklusser, som strækker sig over en periode på 1-4 uger. Cyklusserne kalder man for Sprints, og de gentages efter hinanden uden pause. Hver Sprint har en fast slutdato, som aldrig kan udsættes, uanset om arbejdet er færdiggjort eller ej. Før en sprint kan påbegyndes, skal et hold af udviklere nedbryde et projekt til tidsestimerede aktiviteter, og fordele dem på udviklingsteamets medlemmer. Teamet får projekterne fra en Product Backlog, som er en prioriteret liste af indkommende udviklingsprojekter.

Agile Scrum

En product backlog skal prioriteres ud fra en kombination af tre kriterier:

  1. Strategi: Det kan være af strategisk værdi, at prioritere et udviklingsprojekt der er målrettet mod en civilisation, hvortil virksomheden planlægger at ekspandere.
  2. Værdi: Den forventede værdi er vigtig for prioriteringen. Værdi er som regel et spørgsmål om kroner og øre, men en prioritering på baggrund af værdi kunne også være ud fra ønsket om at skabe en endnu grønnere profil.
  3. Balance: Det er vigtigt at der er en balance i udviklingsprojekternes risiko, lige såvel som det er vigtigt at der er balance i medarbejdernes arbejdsbyrde på projekterne.

Når Teamet sætter cyklussen i gang, forpligter de sig til at fuldføre alle elementerne i det udvalgte projekt. Derfor afholder man hver dag et stående møde, hvor man informere hinanden om fremskridt, og koordinerer indsatsen på de resterende opgaver. Mødet må ikke tage mere end 15 minutter. Under mødet skal hvert teammedlem besvare tre spørgsmål:

  1. Hvad han/hun har gennemført siden sidste møde
  2. Hvad han/hun vil gennemføre inden næste møde
  3. Hvilke hindringer der evt. er i vejen for, at han/hun kan gennemføre sit arbejde

Når en sprint er afsluttet, præsenterer teamet resultatet og får konstruktiv feedback, som derefter kan inkorporeres i næste Sprint.

Scrum – de 3 udviklingsroller

Et Scrum team udgøres af tre roller: Product Owner, Team og Scrum Master.

Product owner

I Scrum er der kun én person der har rollen som Produkt Ejer. Denne person skal være tilgængelig i hele udviklingsforløbet, og skal sikre, at teamet arbejder fornuftigt, ud fra et forretningsmæssigt synspunkt.

En Product owner har et maksimalt vidensniveau om opgaven, og er projektets interne kunde. Han repræsenterer kundens interesser, ved at administrerer en Product Backlog; en to-do liste, hvor alle indkommende krav og produkt specifikationer er opført i henhold til, hvor vigtige/profitable de anses for at være. Backlog’en er synlig for hele organisationen, så alle er klar over, hvad de kan forvente i fremtidige versioner af produktet.

En Product owner må ikke forveksles med en projektleder, da han i Scrum ikke er uddelegerende, men rollen kræver omfattende viden om teknik, markedsføring og forretningsudviklingsprocesser.

Team

Et team er de projektdeltagere der udfører det egentlige arbejde af de projekter der ligger øverst i Product Backlog’en. Teamet er selvorganiseret og består normalt af 5-9 personer – en størrelse erfaring har vist at være bedst for denne type arbejde.

I en Sprint Backlog nedbryder teamet projekter i aktiviteter, tidsestimere dem og fordeler dem på teamets medlemmer. Time boxing indikerer et fastsat tidsrum hvor teamet ikke må forstyrres i deres arbejde med tidestimerede aktiviteter. Time boxing skal sikrer at teamet har optimale arbejdsbetingelser, således aktiviteterne bliver udført til aftalt tid.

Det er vigtigt at et Team besidder alle de nødvendige kompetencer for at fuldføre opgaven i løbet af en Sprint, og for at understøtte mest mulig fleksibilitet. Udover at bygger produktet, kommer teamet også med vigtige input og ideer til Product Owner om, hvordan man kan gøre produktet endnu bedre i forhold til kundens behov.

Scrum Master

En Scrum Masters vigtigste mission, er at skabe de bedst mulige forudsætninger for at Teamet realisere de fastsatte mål. Dette sker bl.a. igennem en funktion som gatekeeper, hvor alt information fra personer uden for projektet går gennem Scrum Masteren. Denne tager de vigtigste pointer med på det daglige møde, hvor informationen deles. Denne procedure sikre at Teamets deltagere forstyrres mindst muligt i deres arbejde. Skulle Teamet støde på problemer i deres arbejde, kan de henvende sig til Scrum Master, hvis opgave er at løse disse problemer og holde hjulene i gang. Formålet er at løfte holdets niveau af aktivitet og øge motivationen forud for næste Sprint.

Visualisering

I forbindelse med Scum har man behov for et værktøj til at styre processen, og der er stor forskel på de værktøjer, der bruges til at understøtte Scrum udvikling. De spænder fra lavpraktiske lister og Post-it sedler, som udelukkende håndteres manuelt, til avancerede digitaliserede systemer. Et af de mest centrale værktøjer er en Scrum tavle, som synliggør status og eventuelle problemer.

Det er typisk omkring Scrum tavlen, at et projektteam samles i forbindelse med det daglige møde. Her kan tavlen bl.a. være med til at højne kvaliteten i diskussionerne og koordineringen af indsatser mod et fælles mål. Lavpraktiske tavler fungerer bedst i projekter, hvor hele Scrum teamet kan samles, hvorimod udviklingsafdelinger med fragmenterede og globaliserede teams stiller større krav, da kommunikation over distancer og tidszoner er meget vanskeligt.

Scrum Board

Normalt håndteres Sprint backlog’en på tavlen ved, at den opsplittes i små sedler, som flyttes og skifter status i forbindelse med det daglige Scrum møde. Hver gang en opgave er færdig, flyttes den til en ”Færdig” kategori og registreres på en Burndown graf. Burndown grafen viser status på løste opgaver i forhold til de totalt planlagte opgaver.

Her kan du få viden om scrum på 2 minutter https://youtu.be/Qoa5CS9JJPQ