Det agile landskab. Få et overblik over agile metoder på team-, projekt- og enterprise-niveau

Det agile landskab Få et overblik over agile metoder på team-, projekt- og enterprise-niveau

Indholdsfortegnelse Det agile landskab 1 Opdeling af agile metoder 2 Det agile landkort 3 Metoder på teamniveau 4 Metoder på projektniveau 13 Metoder på Enterprise-niveau 25 Kræver agile projekter en projektleder? 30 Om forfatteren 31 Om Metier 32 Copyright Februar 2019, Metier Scandinavia A/S PRINCE2 og PRINCE2 Agile er registrerede varemærker tilhørende AXELOS Limited.

Det agile landskab Hvordan begynder du med agil omstilling? Det agile landskab kan være en jungle, hvis man ikke på forhånd kender mulighederne. I denne e-bog giver vi dig en oversigt over fordele og ulemper ved de mest udbredte agile tilgange. Indledning Verden har altid forandret sig, men sjældent så hurtigt som nu. Den teknologiske udvikling kobler os sammen alle døgnets timer, og derfor har mange organisationer svært ved at planlægge og eksekvere opgaver på samme måde som tidligere. Et stigende antal virksomheder har problemer med at udføre projektarbejde inden for rammerne af den gammeldags vandfaldsmodel. Krav om hurtige ændringer og løbende justeringer skaber behov for mere fleksible arbejdsgange. Derfor omstiller mange virksomheder deres udviklingsarbejde til agile metoder. Hvorfor gå den agile vej? De 3 vigtigste årsager er 1 : 1. Et ønske om at accelerere udviklingen af software 2. Et ønske om forbedret håndtering af skiftende prioriteter 3. Et ønske om øget produktivitet Organisationer, som arbejder agilt, peger på en lang række andre fordele. Agile metoder skaber fleksible udviklingsforløb, transparent projektoversigt, højere teammoral og højere medarbejdertilfredshed. Men det agile felt rummer et væld af metoder, uddannelser og certificeringer. Hvor skal du begynde? I denne e-bog har vi skitseret det agile landkort for at skabe overblik over de forskellige rammeværker. Heri gennemgår vi følgende for hver metode: Hvad kendetegner metoderne? Hvem bruger dem? Hvilke typer projekter eller opgaver anvendes de til? Hvor udbredt er de? Hvilke certificeringer kan man opnå? 1 https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report 1

Opdeling af agile metoder Agile metoder kan opdeles efter to parametre: Graden af skalering Graden af beskrivelse Skaleringsgrad Skaleringsgraden indikerer, hvilket niveau metoden passer til. På teamniveau anvender man metoder, der bruges af de enkelte teams. På projektniveau anvender man metoder til større projekter med flere involverede teams. På enterprise-niveau anvender man metoder, der fostrer samarbejde gennem en hel organisation, dvs. program- og porteføljestyring af flere projekter på en gang. Beskrivelsesgrad Beskrivelsesgraden indikerer, hvor mange detaljer metoden kræver beskrevet. En metode som Kanban har eksempelvis en meget lav beskrivelsesgrad, fordi den hverken kræver, at man specificerer roller eller dokumenter. Omvendt forholder det sig med et rammeværk som SAFe (Scaled Agile Framework). Her stilles krav til detaljeret vejledning om dokumenter, teknikker og roller. Metoder og rammeværk med lav beskrivelsesgrad giver højere frihed, fordi ansvaret overlades til brugerne. Til gengæld kan det være sværere at komme i gang med dem, fordi mange spørgsmål efterlades ubesvaret. Oversigten på næste side viser, hvordan forskellige metoder og rammeværk er placeret i forhold til skaleringsgrad og beskrivelsesgrad. Det er disse, vi gennemgår i denne e-bog. 2

Det agile landkort Enterprise-niveau SAFe DAD Meget beskrivende DSDM Scrum@ Scale PRINCE2 Agile Meget åbne Projekt-niveau Nexus LeSS Scrum Kanban Team-niveau Figur 1 Det agile landkort 3

Metoder på teamniveau

Scrum Et simpelt framework til komplekst arbejde Scrum opstod som reaktion på det, man kalder vandfaldsmodellen, hvor alle aktiviteter afhænger af noget forudgående. Vandfaldsprojekter kræver detaljeret planlægning og komplekse arbejdsgange. I 1990 erne var det muligvis årsagen til en række projektkatastrofer i IT-verden. Nogen mente, at man brugte tilgangen forkert. Andre foreslog, at der var behov for endnu mere detaljeret planlægning. Jeff Sutherland og Ken Schwaber gik den modsatte vej og skabte en fleksibel arbejdsmodel i form af Scrum. Scrum forudsætter, at man arbejder i små, selvstændige, tværfaglige teams. I stedet for langsigtet planlægning anviser Scrum korte iterationer, løbende inspektion af resultater og gradvis tilpasning af den overordnede plan. Det hele foregår fuldstændigt transparent og med vægt på fælles forståelse for mål og proces. Scrum-teams med forskellige roller Scrum muliggør komplekst arbejde gennem simple processer. Det klassiske Scrum-team er opdelt i forskellige roller. En Product Owner repræsenterer kunden/brugeren og prioriterer, hvad der skal laves. Et udviklingsteam på 5-9 personer har de nødvendige færdigheder til at udvikle det færdige produkt. Endelig har en Scrum Master ansvaret for, at hele teamet forstår og bruger Scrum korrekt. Timeboxes & Sprints I Scrum arbejder man inden for såkaldte timeboxes. En Product Owner har en ønskeliste til nye funktioner, kaldet en Product Backlog. Ingen ved, hvor længe det tager at udvikle alle funktioner, og det er heller ikke interessant. Scrum-teamet aftaler en overordnet timebox på eksempelvis seks måneder, hvor næste release skal færdiggøres. Efterfølgende inddeles disse seks måneder i kortere timeboxes de såkaldte sprints, på eksempelvis to uger. Når første sprint starter, foretager teamet en sprint planning, hvor man udvælger de højest prioriterede opgaver, som realistisk kan leveres på to uger. Disse ønsker lægges i Sprint Backlog en. Herefter får udviklingsteamet fuldstændig ro. Der kommer ingen nye krav og ingen forstyrrelser. 5

Daily Scrum, Backlog & Retrospective Udviklingsteamet mødes hver dag til en kort Daily Scrum, hvor alle teammedlemmer redegør for deres aktivitet den forudgående dag, deres aktivitet denne dag og eventuelle udfordringer, som står i vejen for arbejdet. Daily Scrum giver teamet fælles ansvar for færdiggørelsen af flest mulige opgaver. På sprintets sidste dag mødes Scrum-teamet til et Sprint Review, hvor udviklingsteamet fremviser den nye funktionalitet. Alt, der fremvises, skal være testet, dokumenteret og helt færdigudviklet. Delvist udviklede produkter er uinteressante. Product Owner en forholder sig til leverancen og skitserer nye ønsker i en Product Backlog. Derefter evaluerer udviklingsteamet det overståede sprint i et såkaldt Retrospective, som bl.a. skal genere forslag til fremadrettede forbedringer. Herefter starter processen forfra i en ny iteration/sprint. Man bør ikke estimere omfanget af det planlagte seks måneders release forud for første sprint. Det er først muligt at foretage realistiske estimater, når man har gennemført et eller to sprint. Så bliver prognoserne mere sikre og man undgår spildtid på specifikationer og estimater af opgaver, som alligevel ikke skal laves, hvis prioriteterne har ændret sig. Hvad egner Scrum sig til? Scrum er ikke svaret på alt. Det er for eksempel hverken en projektstyringsmodel eller en metode til løbende drift. Scrum er udviklet til brug i eksisterende organisationer (f.eks. en projektorganisation eller linjeorganisation). Scrum har ingen projektlederrolle, fordi metoden udelukkende fokuserer på leveranceteamet. Scrum kan fungere uden projektleder, men ikke uden ledelsesstruktur. Man kan sammenligne Scrum med spilsystemer i fodbold. Selvom der ikke er behov for en administrerende direktør til 4-4-2-systemet, er der stadig behov for en direktør i klubben. 6

FAKTA Opbygning Scrum består af tre roller, fem events og tre artefakter. Roller: Product Owner, Development Team og Scrum Master Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review og Sprint Retrospective Artefakter: Product Backlog, Sprint Backlog og Increment Kendetegn Et Scrum-team er: Selv-organiserende Samlet (co-located) Tværfagligt (kan varetage alle opgaver fra idé til færdigt produkt) Lille: 5 personer (+/-2) Stabilt over tid (de samme mennesker arbejder sammen uden egentlig slutdato) Målgruppe Anvendelse Udbredelse Scrum er blevet de-facto standardmetode til agil udvikling i mange offentlige og private virksomheder. Scrum kræver et fuldtidsallokeret multifunktionelt team med en dedikeret Scrum Master og en seriøs Product Owner. Hvis man går på kompromis med metodikken, risikerer man, at den påregnede værdi ikke realiseres. Implementering af Scrum kræver et stort leap of faith. Scrum anvendes primært til softwareudvikling, men har også spredt sig til andre former for produktudvikling. Hovedparten af al softwareudvikling involverer Scrum. I nogle undersøgelser har op mod 70% af tilspurgte virksomheder indikeret, at Scrum på Certificering Niveau Scrum er ikke en beskyttet titel. Alle kan tilbyde certificeringer. Man bør være opmærksom på valg af udbyder, eftersom certificeringens kvalitet og værdi kan variere fra sted til sted. Scrum Alliance og Scrum.org er de to mest respekterede udbydere. Begge tilbyder certificeringer til en række forskellige roller, f.eks. Certified Scrum Master (CSM) og Professional Scrum Master (PSM). Scrum anvendes på team-niveau Beskrivelsesgrad Lav 7

Kanban Yes, we Kanban! Stop starting and start finishing! Kanban betyder kort på japansk. Metoden stammer fra 1940 ernes Toyota-fabrikker, hvor produktionsteams brugte kort til at signalere behov om reservedele fra andre grene af produktionslinjen. Allerede dengang lagde Toyota stor vægt på effektivisering. Alt, hvad vi i dag kender som Lean, stammer fra Toyota. Kanban kan betegnes som en form for Lean-tilgang til softwareudvikling. Kanban vandt udbredelse i projektverdenen i årene efter 2000, hvor David J. Andersen eksperimenterede med ideer fra Lean-produktion i sine softwareudviklingsteams. Kanban vs. Scrum Kanban er kendt for de karakteristiske tavler, man ser hos mange teams, men metoden rummer mere end det. Kanban har frem for alt til formål at facilitere kontinuerlige forbedringer gennem fastlagte principper. Kanban adskiller sig fra Scrum på to væsentlige områder. Det ene er tilgangen til forandring. Scrum dikterer, at man skal gøre tingene efter en helt fastlagt procedure. I Kanban begynder man, hvor man er, og udvikler sig lidt ad gangen derfra. Det andet er spørgsmålet om tidshorisont. I Scrum arbejder man inden for afgrænsede timeboxes og korte sprints. Kanban opererer derimod med et kontinuerligt arbejdsflow. Scrum bygger på fastlagte processer og rollefordelinger, som kan tages i brug out of the box til arbejde med planer, estimater og faser. Kanban består derimod af seks byggeblokke, der hjælper teamet med at styre opgaver og optimere det løbende arbejde. Meget forsimplet kan man sige, at Scrum egner sig til projektarbejde, mens Kanban egner sig til daglig drift. 9

De seks byggeblokke i Kanban er: ❶ Visualisering på Kanban-tavle Et whiteboard opdeles i kolonner, der beskriver arbejdsprocessen (de trin, arbejdet flyder gennem). Det kan fx være To Do, Definition, Analyse, Udvikling, Test og Godkendelse. Herefter noteres hver opgave på en post-it-seddel, og alle sedler placeres på tavlen for at visualisere processen. ❷ Begrænsning af WIP (Work in Progress) Det besluttes, hvor mange aktiviteter man kan foretage samtidigt i hver kolonne. Fx kan hvert team vælge at tillade to emner ad gangen i kategorien Definition. ❸ Styring af flowet Man måler det samlede tidsforbrug, som en opgave kræver fra start til slut. Det afklares, hvilken indsats der er nødvendig, for at arbejdet skaber værdi. ❹ Tydelige regler Hvad gør man, når opgaver blokeres og ikke kan komme videre? Teamet bliver enige om et regelsæt, som bruges til at huske fælles aftaler. ❺ Hyppige feedback loops F.eks. på teamets daglige tavlemøde. ❻ Forbedring gennem samarbejde og udvikling gennem eksperimenter Formålet med Kanban er at skabe kontinuerlige forandringer og forbedringer. Kanban bruges til diskussion af processer og forslag til forbedringer. Optimering af flow Man kan betegne Kanban som en metode til at optimere flow. De enkelte teams bliver hjulpet til at minimere kalendertiden fra begyndelsen til afslutningen af deres opgaver. Tegn på, at udviklingsteam kører godt med Kanban, er: 1. Høj flow-effektivitet Hvis der fx går tyve dage fra initiering til færdiggørelse af en Change Request, og teamet har ti dages effektiv arbejdstid, vil flow-effektiviteten være 50 %. Det er i alle tilfælde en meget høj effektivitet. 2. Lav varians Hvis 95% af alle Change Requests eksempelvis bliver færdige i et tidsrum mellem 18 og 22 dage, er der tale om lav varians. Inden for rammerne af Kanban skaber man høj flow-effektivitet og lav varians ved at visualisere arbejdstrin, arbejde på en Kanban-tavle og begrænse Work in Progress (WIP). 10

FAKTA Opbygning Kanban består af 6 principper: Visualisering på Kanban-tavle Begrænsning af Work In Progress (WIP) Styring af flowet Tydelige regler Hyppige feedback loops Kanban starter, hvor I er i dag Kendetegn Kanban adskiller sig fra Scrum på flere punkter: Ingen sprints. Teamet trækker opgaver fra en kø Ingen estimater. Man måler de historiske leverancetide. Releases sker kontinuerligt, så snart noget er færdigt. Målgruppe Nogle Scrum-teams bruger Kanban som en del af Scrum. Denne metode kaldes Scrumban. Det drejer sig ofte om modne Scrum-teams, der begrænses af sprints. Det sker ved at skitsere arbejdsprocesser på en tavle med trin-kategorier som Specify, Develop og Test. Herefter aftales WIP-limits for antallet af user stories, man må arbejde med ad gangen. Anvendelse Udbredelse Kanban anvendes først og fremmest inden for softwareudvikling, men kan også bruges til vidensarbejde, produktudvikling, patienthåndtering og marketing. Kanban er også del af enterprise-frameworket SAFe. Her tilpasses metodikken til overordnet program- og portefølje-niveau. Kanban-tavler har længe været kendt i projektverden, men har først for nyligt opnået bredere systematisk udbredelse. Kanban er mere formbar og dermed mere bredt anvendelig end Scrum. Kanban har potentiale til at blive en førende metode til vidensarbejde. Certificering Kanban er ikke en beskyttet titel. Alle kan udbyde certificeringer. LeanKanban University er det mest respekterede institut og tilbyder mange forskellige certificeringer. Niveau Kanban anvendes på team-niveau Kanban kan bruges i en lang række sammenhænge til produktion og service. F.eks. ser man ofte Kanban-tavler anvendt på McDonaldsrestauranter. Beskrivelsesgrad Lav 11

Metoder på projektniveau

DSDM Agile s best kept secret! DSDM står for Dynamic Systems Development Method. Hvor Scrum og Kanban er beregnet til teamarbejde, er DSDM en komplet agil projektmetode. Den blev udviklet i 1994 og er dermed den første af sin art på verdensplan. DSDM er skabt til store softwareudviklingsprojekter og bygger på en udførlig metodik med tilhørende filosofi. Omfangsrig metode Omfanget er både en styrke og svaghed. DSDM er gradvist blevet overhalet af mere tilgængelige rammeværk som fx Scrum, men en dedikeret skare af ildsjæle sværger stadig til metoden. En række mindre konsulenthuse medbringer nogle gange DSDM, når de skal levere kritiske IT-projekter for større virksomheder. DSDM er velegnet til situationer, hvor man starter fra scratch og selv kan definere opsætningen af et projekt. Metoden indeholder alt, hvad du skal bruge: iterative processer fra præ-projekt til postprojekt, alle nødvendige roller og en lang række teknikker. 14

FAKTA Opbygning Kendetegn Målgruppe DSDM består af en grundlæggende filosofi og overbygning af praktiske elementer: Principper: Fokus på forretningsbehov, leverance til tiden osv. Processer: Fra præ-projekt til post-projekt Knowledge Areas: People, team and interactions; Requirements and user stories; Project Planning and Control m.fl. 14 produkter: Business Case, Requirement List, Solution Architecture m.fl. 13 roller: Fra styregruppe til projektleder og leveranceteam. Velbeskrevne teknikker: Iterativ udvikling, Timeboxing, MoSCoWprioritering, Prototyping, Testing, Workshop, Modelling og Configuration Management DSDM er den mest detaljerede og beskrivende metode på projektniveau. Store virksomheder med store IT-projekter DSDM er ofte knyttet til konsulenter, der hyres til projekter. Anvendelse Udbredelse Certificering Store stand-alone IT-projekter, f.eks. ERP-implementeringer. Trods lang historik er DSDM ikke særligt udbredt. Få virksomheder anvender i dag DSDM som standardtilgang. En udvalgt gruppe konsulentvirksomheder er fortsat dedikerede til systemet. Globalt set har DSDM 10 officielle partner-virksomheder. Certificeringen består af fem niveauer fra Foundation til Consultant. Manualen er frit tilgængelig. Niveau Beskrivelsesgrad DSDM anvendes på projekt-niveau. Høj 15

LeSS (Large Scale Scrum) More with LeSS! LeSS var blandt de første metoder til agil skalering. Frameworket fokuserer på skalering af Scrum, og man kan betegne det som en slags multiple team Scrum-struktur. LeSS skaber samarbejde, når flere Scrum-teams skal bidrage til samme projekt. LeSS findes i to varianter: Det almindelige LeSS, som er beregnet til grupper mellem to og otte teams, og LeSS Huge, som er beregnet til mere end otte teams. Hvert team arbejder dedikeret med egne opgaver. For at flere teams kan arbejde sammen om det overordnede produkt, udarbejdes en fælles backlog og synkroniserede sprints, som varetages af en über-product Owner. Mindre metode mere ansvar LeSS bygger på forudsætningen om, at mindre metode giver mere ansvarsfulde teams. LeSS opererer med minimal opsætning af regler for at undgå for meget proces. Målsætningen er at være barely sufficient til at kickstarte samarbejde mellem selvstyrende teams i løbende udvikling. 16

FAKTA Opbygning More with less: Distinct roles, processes & artefacts More: Self-organizing & products meeting needs : LeSS: 2-8 teams LeSS Huge: 8+ teams Synkroniserede sprints, fælles backlog LeSS Principles, LeSS Rules, LeSS Guides, LeSS Experiments Kendetegn Målgruppe LeSS kan betegnes som Scrum med Scrum udenpå. Scrum-teams arbejder sammen med hinanden i LeSS, på samme måde som medlemmerne af et Scrum-team arbejder sammen internt. Organisationer med høj agil modenhed, som selv kan finde ud af detaljerne. Anvendelse LeSS er velegnet til store projekter og initiativer, som tillader høj grad af frihed. LeSS betegnes af og til som starten på en rejse, man ikke ved hvor ender. LeSS har ikke meget metodik, som uerfarne teams kan holde fast i. Udbredelse LeSS bruges mange steder som inspiration, men tager ofte egen form eller blandes med andre tilgange. Derfor er det svært at sige, hvor udbredt LeSS egentlig er. Certificering LeSS har sin egen certificering kaldet Certified LeSS Practitioner (CLP). Niveau LeSS anvendes på projekt-niveau. Beskrivelsesgrad Lav 17

Nexus Et exoskelet til Scrum Nexus minder meget om LeSS. Begge frameworks gør det muligt at anvende Scrum til større projekter. Man fokuserer på at løse de udfordringer, som opstår, når flere Scrumteams skal samarbejde om et produkt. Et Nexus er betegnelsen for en samling af tre til ni Scrum-teams med fælles midtpunkt et Nexus. Nexus-metoden beskriver de overordnede roller, ceremonier og artefakter, som bør være fælles reference for alle teams. Færre afhængigheder Nexus er en slags Über-Scrum, som både hjælper teams med at samarbejde og reducerer deres afhængighed af hinanden. Frameworket har ingen detaljeret vejledning og kan efterlade mange ubesvarede spørgsmål. I en vis forstand kan man bedre betegne Nexus som et udgangspunkt, der giver virksomheder mulighed for at eksperimentere, fremfor et færdigt framework. Nexus har en Bottom-up-tilgang til projekter og kan fungere som virksomhedens næste, naturlige trin, når Scrum er implementeret på team-niveau. 18

FAKTA Opbygning Kendetegn Målgruppe Anvendelse Udbredelse Roller, events, artefakter og teknikker Single Product Backlog Nexus Integration Team fungerer som en slags program/projekt-team med Nexus Scrum Master som Projektleder og Product Owner som Projektejer. Fælles (Nexus) artefacts: Product Backlog, Nexus Goal, Sprint Backlog, Integrated Increment, Definition of Done Fælles Product Owner Fælles (Nexus) ceremonier: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective Nexus er Scrum med Scrum udenpå. Ligesom individer arbejder sammen med hinanden i et Scrum-team, arbejder Scrum-teams sammen med hinanden i Nexus. Nexus er velegnet for erfarne teams, der skal udføre større projekter. Softwareudvikling, hvor flere teams samarbejder om et produkt. Mange virksomheder lader sig inspirere af Nexus, men bruger ikke frameworkets regler systematisk. Certificering Scaled Professional Scrum (scrum.org) Niveau Beskrivelsesgrad LeSS anvendes på projekt-niveau. Lav 19

PRINCE2 Agile PRINCE2 på den agile måde Mange tror, at PRINCE2 er beregnet til projektarbejde efter vandfaldsmodellen. I virkeligheden er frameworket hverken designet specifikt til vandfaldsprojekter eller agile projekter. Det kan tilpasses begge tilgange. PRINCE2 er verdens mest udbredte projektmetode, som effektivt adresserer udfordringer på projektledelses- og styregruppeniveau. PRINCE2 udelader bevidst al beskrivelse fra leveranceniveauet ud fra betragtningen om, at procedurer ikke skal stå i vejen for faglig ekspertise. PRINCE2 er en generisk metode, der kan tilpasses til individuelle projekter. PRINCE2 Agile er derimod en guide, der tilpasser PRINCE2 til agilt arbejde. Metoden vejleder specifikt angående forhold omkring tolerancer, roller, faser osv. Agile teknikker i eksisterende projektmodeller PRINCE2 Agile holder fast i udgangspunktet som generisk metode, der ikke retter sig mod specifik produktudvikling. PRINCE2 Agile skaber overblik over de agile teknikker, men overlader valget af dem til brugeren. F.eks. kan man både lade sine teams arbejde i iterationer (Scrum) og flowbaseret (Kanban). PRINCE2 Agile kickstarter agile teknikker i en eksisterende projektmodel uden behov for at ændre på overordnet styring af projektet. Sammenhæng mellem projekt- og teamniveau PRINCE2 Agile er kompatibel med alle agile metoder på teamniveau. Metoden forklarer eksempelvis, hvordan underleverandører, der anvender en bestemt metode (fx Scrum), kan få integreret deres teams i kunders projektarbejde. Man skal selv tilpasse detaljerne og beslutte, hvad der passer præcist til situationen. 20

FAKTA Opbygning Introduktion til agilt arbejde. Specifik agil vejledning til samtlige PRINCE2 -temaer, -processer, -roller og -produkter Kendetegn Målgruppe Anvendelse Udbredelse PRINCE2 Agile har ikke sin egen agile tilgang, men trækker på metoder som Scrum, Kanban og flere andre, som integreres i PRINCE2 rammeværket. Velegnet til organisationer, der i forvejen har PRINCE2 og vil kickstarte agile metoder i den eksisterende model. Velegnet som agil metode, hvis man allerede anvender PRINCE2 til traditionelle projekter. PRINCE2 Agile er relativt nyt. Indtil videre anvendes det mest til ITprojekter. Certificering Niveau Beskrivelsesgrad Til at starte med var PRINCE2 Agile Practitioner en overbygning til PRINCE2 Foundation-certificeringen, men siden 2018 kan man også få en PRINCE2 Agile Foundation-certificering og herefter vælge at tage PRINCE2 Agile Practitioner-certificeringen. Begge certificeringer udbydes af AXELOS. PRINCE2 Agile anvendes på projekt-niveau. Middel 21

Scrum@Scale Letvægts-framework til skalering af Scrum Scrum@scale kommer fra Jeff Sutherlands virksomhed Scrum Inc., der bl.a. har skabt Scrum. Scrum Inc. kom sent på banen med en skaleringsguide til Scrum. Helt i Jeff Sutherlands ånd er Scrum@scale et letvægts-framework, der assisterer arbejde på tværs af flere Scrum-teams. Scrum@Scale guider teams, der er afhængige af hinanden, mod et fælles mål. Bogstavelig talt er der tale om en skalering af Scrum. Scrum of Scrums Op til fem Scrum-teams indgår i en Scrum of Scrum. Op til fem Scrum of Scrums indgår i en Scrum of Scrum of Scrums. Virksomhedens samtlige Scrum of Scrum of Scrums organiseres af et Executive Action Team. Scrum@Scale vejleder bl.a. om, hvordan Scrum Masters og Product Owners koordinerer arbejde på tværs af teams. Rammeværket introducerer nye roller som f.eks. Scrum of Scrum Master og Chief Product Owner til understøttelse af dette arbejde. Hele Scrum@Scale står beskrevet i Scrum@Scale Guide. 22

FAKTA Målgruppe Anvendelse Udbredelse Certificering Niveau Beskrivelsesgrad Organisationer med +5 Scrum-teams, der skal koordinere samarbejde om et produkt. Store IT/produktudviklingsorganisationer Scrum@scale er beregnet til høj individuel tilpasning blandt de organisationer, der benytter det. Derfor er det svært at sige noget præcist om udbredelsen. Certified Scrum@Scale Practitioner Scrum@Scale anvendes på projekt-niveau Lav 23

Metoder på Enterprise-niveau

Scaled Agile Framework (SAFe ) Nothing beats a team of teams SAFe står for Scaled Agile Framework og er blevet det førende rammeværk for kollaborativ produktudvikling i store organisationer, hvor flere teams eller afdelinger skal arbejde sammen om større agile programmer. Tre niveauer På teamniveau bygger SAFe på metoder som Scrum og XP, og de agile, selvorganiserende teams har klart definerede roller, ansvar og processer for deres kontinuerlige samarbejde og leverancer. Der arbejdes med backlog, timeboxes, sprints, retrospectives ovs. På programniveauet opererer SAFe med agile team of teams. Her gælder det om at definere produktvisionen og værdikæden og om at allokere budgetter til de såkaldte Value Streams bugetter, som går til at drive et eller flere Agile Release Trains, som kontinuerligt leverer produkter til kunderne. Også på programniveau arbejdes der med en backlog, sprints, demos osv. Formålet er hele tiden at sikre, at tingene hænger sammen. På det overordnede porteføljeniveau koordinerer SAFe alle programmer til et samlet overblik. Her bliver strategierne udarbejdet, Must Win Battles bliver defineret, og der aftales et overordnet budget for årets udviklingsarbejde. Her trækker SAFe på koncepter fra Lean-tankegangen og Kanban til at håndtere de overordnede rammer. Ingen projekter i SAFe SAFe opererer ikke med projekter. I stedet for at flytte mennesker rundt mellem projekter, opdeler man arbejdet i mindre dele, som fordeles og uddelegeres mellem forskellige stabile teams. Som agil metode indeholder SAFe alt, du skal bruge, på alle niveauer. SAFe er det nærmeste, man kommer en out-of-the-box agil leverancemodel til hele virksomheden. 26

FAKTA Opbygning Kendetegn Målgruppe Anvendelse Team Level: Kanban, Scrum, XP, Program Increments (PI), PI Planning, User Stories, Iterations Program Level: Features, Agile Release Trains, PI Objectives, PI Planning, DevOps Portfolio Level: Epics, Values Streams, Portfolio Canvas, Lean Budgets #noprojects, Lean-Agile product development Mest til store virksomheder, som kan håndtere implementeringen. New Product Development i store organisationer. SAFe inkorporerer Scrum, Kanban og Lean startup. Udbredelse SAFe er beregnet til produktudvikling og anvendes i mange brancher. F.eks. hos systemleverandører, finansinstitutioner, banker og forsikringsselskaber, der har behov for intern IT-produktudvikling Certificering SAFe -certificeringer udbydes af Scaled Agile Inc. Forskellige certificeringer baserer sig på bestemte roller. Man behøver kun en enkelt certificering for at varetage en rolle. Der findes ikke noget overbygningsniveau i SAFe. Populære SAFe -kurser er: Leading SAFe SAFe Scrum Master SAFe Scrum Product Owner/Product Manager Niveau Beskrivelsesgrad SAFe anvendes på enterprise-niveau Høj 27

Disciplined Agile 2.0 a.k.a. DAD Disciplined Agile (DAD) er et hybrid-framework, hvor metoder som Scrum, XP, Kanban, SAFe osv. udgør byggeblokke, der kædes sammen til en helhed. DAD tilgår systematisk hele IT-frameworket i store organisationer. Det er et tilpasningsbart og fleksibelt framework med fokus på slutmål, som gør det muligt at definere og tilpasse IT-processer. Til de erfarne På den ene side er DAD et gennemarbejdet og brugbart framework. Det kan bruges som landkort over en IT-organisation med masser af relevante processer, teknikker, roller osv. Omvendt kan DAD være ugennemskueligt og svært tilgængeligt, hvis man ikke har erfaring som Lean- eller Agile-konsulent. DAD er anvendeligt i det omfang, en organisation kan håndtere teknisk tunge rammeværk. 28

FAKTA Opbygning Kendetegn Målgruppe Anvendelse Certificering Niveau Beskrivelsesgrad Roller, Agile Delivery Lifecycle(s) (baseret på Scrum, Lean, Continuous Delivery eller Lean Startup), Process Guidance (Goal Driven), Agile Delivery governance DAD arbejder med fire forskellige domæner: Solution Delivery, Disciplined DevOps, Disciplined Agile IT, Disciplined Agile Enterprise Én tilgang til det hele. Store IT-organisationer Igangværende software-produktudvikling/solution delivery DAD er certificeret på fire niveauer: Disciplined Agilist, Certified Disciplined Agilist, Certified Disciplined Agile Practitioner, Certified Disciplined Agile Coach Disciplined Agile anvendes på enterprise-niveau Høj 29

Kræver agile projekter en projektleder? Scrum og flere andre agile rammeværk opererer uden projektlederrolle. Betyder det, at der fremover ikke bliver behov for projektledere? Der har eksisteret projektledere siden tidernes morgen. Selvom titlen ændrer navn, bliver der i al overskuelig fremtid behov for det arbejde, projektlederen udfører. Scrum fungerer uden projektleder, fordi rammeværket ikke beskriver alt. Fokus er på team-niveau. Et Scrum team vil dog altid eksistere i en større sammenhæng, fx som del af en linjeorganisation med ledere, eller som del af en projektorganisation med projektledere. Større agile projektmodeller som f.eks. DSDM har veldefinerede projektlederroller. Projektledere har altid justeret deres roller til nye krav og behov. For øjeblikket er kendskabet til agile arbejdsmetoder vigtigt. Agilt arbejde er allerede udbredt i en række brancher og vil fremover brede sig til mange flere. Den agile tilgang drejer sig om mennesker. Alle projekter, hvor mennesker er involveret, kan drage fordel af agile tilgange. Det er ikke sikkert, at projektleder-titlen eksisterer om ti år, men opgaverne vil fortsat være der. Derfor er vores anbefaling: ❶ Lær om agile metoder! ❷ Eksperimentér med agile metoder! ❸ Certificér dig i de agile metoder, der er relevante for dig! Læs mere om de agile certificeringer, du kan tage hos Metier her: https://www.metier.dk/kurser-projektledelse-forandringsledelse/ 30

Om forfatteren Jonas Högstrand Jonas har mere end 16 års praktisk erfaring som projektleder, konsulent og rådgiver i private og offentlige virksomheder i Danmark, Sverige, England og Tyskland. Blandt hans kunder tæller Leo Pharma, Post Nord, Rambøll Informatik, ISS, Novozymes m.fl. Hans særlige fokusområder er agil coaching og udvikling af kundespecifikke projektmodeller baseret på hhv. PRINCE2 og agile projektledelsesmetoder, design af projektakademier og gennemførelse af maturity assessments. Jonas er underviser, agile coach og seniorrådgiver i projektledelse. Han er certificeret underviser i PRINCE2, PRINCE2 Agile og SAFe, certificeret P3M3 Assessor og har været reviewer på den officielle PRINCE2 Agile -manual. Uddannelse MSc Business & Economics fra Uppsala Universitet, 1997 Certificeringer Et uddrag af Thomas certificeringer: 2017: SPC4 SAFe Program Consultant (Akkrediteret SAFe Trainer) 2016: Change Management Foundation 2015: Akkrediteret træner PRINCE2 Agile 2015: PRINCE2 Agile Practitioner 2015: SAFe Agilist 2015: EASI Certification (Persontypologi) 2014: MoP Foundation (Management of Portfolios) 2014: MSP Practitioner 2012: P3M3 Assessor 2010: P3O Foundation 2010: PPM Registered Consultant 2006: MSP Foundation 2003: Akkrediteret Trainer PRINCE2 (re-akkrediteret i 2015) 2003: PRINCE2 Foundation og Practitioner joh@metier.dk https://www.linkedin.com/in/jonas-hogstrand-92b1a5/ 31

FORANDRINGER ER VORES METIÉR I Metier arbejder vi for at skabe varige forandringer hos vores kunder ved at forbedre deres evne til at drive projekter og omsætte projekternes outputs til reel værdi for forretningen. Det gør vi ved at fokusere på mennesker, processer og teknologier. Metier blev grundlagt i Danmark i 1986. I de første mange år fokuserede man primært på tekniske systemer til styring af projekter. Siden hen har Metier udviklet sig fra at være ren systemudbyder til at være totalleverandør med fokus på: Kompetenceudvikling af projektorganisationer Rådgivning inden for projekt- og forandringsledelse Teknisk understøttelse af PPM-processer Vi arbejder for store og små virksomheder i Danmark og Skandinavien, der gerne vil effektivisere deres projektorganisation. Vi uddanner medarbejdere i de mest anerkendte metoder inden for projekt- og forandringsledelse. Vi rådgiver om effektive processer, metoder og modeller til projektstyring og hjælper med at forankre de forandringer, projekterne skal frembringe, i organisationen. Endelig implementerer og supporterer vi de bedste værktøjer til projektstyring, som understøtter jeres processer mest hensigtsmæssigt. KURSER I PROJEKT- OG FORANDRINGSLEDELSE Hos Metier giver vi dig certificeringer og kompetencer i projekt- og forandringsledelse på klassekurser, som 100% e-læring eller Blended Learning-forløb tilpasset din projektorganisation. Klassekurser: PRINCE2 Foundation og Practitioner PRINCE2 Agile Practitioner Change Management Foundation og Practitioner Leading SAFe SAFe Scrum Master SAFe Scrum Product Owner/Product Manager Prisbelønnede Onlinekurser: PRINCE2 Foundation og Practitioner PRINCE2 Agile Practitioner Blended Learning: PRINCE2 Foundation og Practitioner PRINCE2 Agile Practitioner METIER SCANDINAVIA A/S +45 7230 2035 info@metier.dk www.metier.dk