We’re sorry this article has not been translated yet…
Lene Becher Jensen er Über ScrumMaster, livredder og kystvagt hos Unomedical – en division af Convatec – i Osted sydvest for København. Hun har i de sidste snart mange måneder arbejdet på at indføre Scrum i hverdagen i et projektorienteret firma i medicinalindustrien. Det har været process der har taget tid, den startede i 2011. De har måttet tilpasse Scrum mønstret til deres hverdag. Lige nu er Unomedical på et platau, hvor tingene fungerer rigtig godt. Her fortæller Lene deres historie:
Baggrund
Frem til 2011 havde vi i Unomedical som i mange andre virksomheder meget fokus på projekter, ledelse og gennemførelse. Vi var rigtig gode til at igangsætte, dårlige til at afslutte og meget dårlige til at stoppe projekter, der ikke længere var rentable.
Projekter var forankret i de enkelte afdelinger, men tog ofte udgangspunkt i de samme ressourcer, som så endte som ”Tordenskjolds soldater”. Vi kunne have personer som var estimeret til 20% ressourcer i 5-6 projekter, samtidig med at de skulle varetage daglig drift.
Det siger sig selv, at det var en daglig kamp at holde de planlagte ressourcer på opgaven, og det medførte en del frustrationer på alle planer, både hos det enkelte team medlem, der blev hevet i fra højre og venstre, projektlederen, der gentagende gange måtte udskyde sin deadline, og hos ledelsen, der kunne se, at vi blev dårligere og dårligere til at effektuere vores projekter, både de interne, men også de eksterne og kunderelaterede projekter.
I sommeren 2011 valgte vi derfor at prøve at ændre vores projektkultur, så alle projekter skulle udføres i forskellige porteføljer. Alle projekter bliver vurderet og indstillet til en Portefølje i samråd med de enkelte Project Portfolio Manager (PPM) og bliver efterfølgende prioriteret i teamet i forhold til igangværende projekter og opgaver.
I denne periode kom vi i forbindelse med Scrum konceptet og blev lidt nysgerrige på, om det kunne bruges i en virksomhed som vores, da konceptet jo var udviklet til IT og softwarebranchen.
Scrum indføres
Vi var to personer, der tog på et ScrumMaster kursus og gennemførte efterfølgende et pilotprojekt, hvor vi fik tilpasset et ScrumMaster kursus til at blive afholdt internt. Dette Pilot projekt viste klart, at det for os ville være en fordel at benytte Scrum konceptet som et projektstyringsværktøj, dog kombineret med den udviklings- og ændringsmodel, der nu en gang er nødvendig for gennemførelsen af projekter inden for medicinalindustrien.
Vi valgte efterfølgende i efteråret 2011 i Danmark og vinteren 2012 i Mexico at få alle personer med tilknytning til vores faste teams på ScrumMaster kursus. Disse blev afholdt internt med fokus på vores behov. I samme periode blev vores PPMér også uddannet som Product Ownere.
Alle teams har derefter brugt Scrum som et værktøj i deres portefølje, med en indkøringsperiode frem til Sommeren 2012, derefter som et fuldt integreret projekt- og porteføljestyrings værktøj, og med en ScrumMaster til at styre de daglige møder.
Implementering af Scrum konceptet
Den nedenstående beskrivelse tager udgangspunkt i PPM rollen for Change/transfer teamet. Implementering af Scrum er lige til, bare man er tro mod konceptet, og man sikrer at alle er indforståede og enige om opgaven.
Team organisation og roller
Vi har hos os valgt at afholde alle projekter fra hele organisationen i en fælles teamstruktur:
• Capacity team: Der tager sig af alt kapacitets relateret projekter, nye maskiner, nye teknologier, cap. Udvidelser, ect (kopi af gamle linier).
• Change/transfer team: Der tager sig at ændringer på eksisterende produkter, materiale skift, leverandør skifte, ect.
• R/D udviklings team: Der tager sig at produktudvikling.
• Lable & Artwork: Der tager sig af branding, ændringer at etiketter, pakke materiale layout, ect.
Alle opgaver tildeles det enkelte team via Change Review board, eller EG board. Alle opgaver prioriteres i samarbejde med de enkelte teams. Alle teams er opbygget efter samme model, med de variationer der ligger i porteføljen. Change/transfer teamet udgøres for eksempel af:
• Project Portfolio Manager (PPM)
• Product Owner: her bruger vi projektleder, 2 personer, disser er dog også ressource i hinandens projekter
• ScrumMaster: Er hos os også dokumentationsansvarlig.
• Team members: Quality Engineer, Process Engineer, Logistic/purchase, R/D- mould Engineer, Test Manager and, Documentation responsible, Design Engineer.
Det er vigtigt for Scrum processen at man har en fast gruppe, der sammen repræsenterer de faglige ressourcer, der er brug for til den pågældende Projekt portefølje (type af opgaver).
Vi har i perioder arbejdet med deleressourcer men aldrig under 50 %. som vi finder er smertegrænsen for hvornår tilhørsforhold forsvinder og prioriteringer bliver svært. Samtidig bruges der en masse unødig tid på de faste ritualer, der er i Scrum. Sprint planlægning, daglig scrum, sprint retrospective, som jo bliver x2 når man er fordelt på to team.
Det er vores erfaring at det ikke fungere med 25 % ressourcer som ingen tilhørsforhold opnår, de bliver aldrig rigtig produktive i den type opgaver, vi arbejder med.
Roller
Vi har også brugt en del tid på at tale roller, dog mere i den omkringliggende organisation end i teamet. Det har været svært at skulle omstille sig fra at være projektleder med ressourcer inddraget fra mange områder i organisationen med en lav ressource tildeling pr. person, til pludselig kun at skulle arbejde med en lille gruppe med en stor ressource tildeling.
I teamet har vi brugt god tid på at tale om, hvem der dækker hvad, fagligt men også som person. Men janteloven råder, det er rigtig svært at fortælle om det, vi er dygtige til. Det ligger så grundelæggende i os, at vi ikke må/skal prale. Det er egentligt synd, det er jo kendskab til hinandens styrker og begrænsninger, der gør teamet stærkt og smidigt – så vi øver os stadig.
Sprint regler
Det er vigtigt at man taler spillereglerne godt igennem, vi har brugt rigtig meget tid på at genbesøge disse. Nedenfor ses de aktuelle regler, der gælder for Change/transfer teamet. De kan ændre sig fra team til team men også over tid.
• Alle opgaver på tavlen opgøres i timer og af en varighed af max 7 timer.
• Alt, der ikke var planlagt, noteres på røde sedler ved efterfølgende Scrum møde.
• Sedler, som ikke bevæger sig fra daglig scrum møde til næste grundet anden prioritering markeres med rød prik.
• Alle deltager i daglig Scrum møde 09:15.
• Alle noterer mødeaktiviteter i forbindelse med Change teamet aktiviteter enten ved sedler på tavlene eller i lommebog, som så skrives på tavlen ved sprint afslutning – møder undtaget herfor er: Daglig scrum, sprint planlægning og retrospective.
Eksempler på regler
Hvad mener man med at have en opgave i Blocked? – hos os betyder det en udefra kommende blokering, som man ikke selv er herre over – men det behøver ikke være en ”Impediment”.
Vi har også været nødt til at oprette en kolonne til Approval, og har ofte et loop tilbage for opdatering af dokumenter, inden hele opgaven kan sættes i “Done”.
Vi sætter røde prikker (med tusch) på de Tasks, der ikke bliver flyttet fra dag til dag som vores regler foreskriver. Denne regel blev indført, fordi det for os var rigtig svært at nedbryde Tasks til max 7 timer. Vi var alle vant til at have mindst en uge til at løse vores task (opgaver), og det er svært at ændre tankegang. Men det er nu lykkedes, og vi nedbryder nu til timer og kan derfor have flere Task i gang fra dag til dag. Det giver os en stor fleksibilitet i vores indbyrdes afhængigheder.
Tasks, der bliver på boardet i blocked eller approval kolonnen ved sprint afslutning, bliver ligeledes mærket, så vi kan se, at de faktisk er overført fra sidste sprint, og når de sommetider bliver overført gentagende gange, bliver det pludselig meget synligt at noget ikke flytter sig i den retning, som vi ønsker.
Timeestimering og registrering
Vi har opsat lidt regneregler i forhold til time estimering:
Da alle jo tilhører en afdeling og har en linjeleder. Selv om de er en 100 % ressource i Change/transfer teamet, har de brug for at kunne bruge nogle timer til at sikre de interesser eller små opgaver, der ligger i linje organisationen. Til dette har vi afsat 10 timer pr. mand pr. uge. Derudover bruger alle i teamet 7 timer pr. sprint til planlægning, 15 min til daglig Scrum,(2 timer 45min. pr. sprint periode) og 2 timer pr. sprint til retrospective.
Dertil kommer andre planlagte events i sprintperioden, samt ferie, fri, kurser ect. Disse trækkes ligeledes fra ved sprintplanlægningen. Dette svarer til 30-35 % af vores samlede ressourcer.
Sprint Planlægning
Grov Planlægning udføres af Porteføljeleder og de 2 projektledere. Dette foregår den 3. og sidste uge af igangværende sprint. Her estimerer vi i hele ”Mand” dage pr. person for det kommende sprint. Vi overestimerer en smule, så vi sikrer opgaver nok på alle faggrupper. Noget fravælges så ved finplanlægning om nødvendigt.
Planlægning med gruppen: Teamet finplanlægger den prioriterede Backlog, for det kommende sprint og disse nedbrydes med time estimat. Når sprintet er planlagt tælles alles timer sammen og det sikres at ingen er overestimeret, skulle dette være tilfældet, bliver de enkelte opgaver prioriteret, således at vi sikrer, det er de for teamet vigtigste opgaver, der udføres først. Det er tilladt at sætte de resterende opgaver tilbage på Backloggen og overføre disse til næste sprint om nødvendig.
Uplanlagte tasks
Vi har som regel brugt 20-35 timer på uplanlagte tasks når vi afslutter sprintet. Det ønsker vi at ændre på, ved at optimere vores planlægning, både grov og finplanlægningen, da de uplanlagte jo skubber allerede prioriterede opgaver ud til næste sprint, og giver os en vis usikkerhed på vores effektuering (Dette er et målepunkt for 2014).
Projekt portefølje
Vi har gennemsnitlig en 18-25 åbne projekter (godkendt af styregrupe), hvoraf vi har 10 aktive og 5-6 projekter i sprint. Vores absolutte max. er 7 projekter i sprints, da det er svært at holde så mange projekter adskilt i tanker og handling.
Ud over de projekter i sprint har vi som ofte 3-4 projekter under det, vi kalder “Diverse Opgaver”, opgaver man kan arbejde på, hvis man skulle have timer i overskud. Disse er ofte planlagt under teamets finplanlægning, basseret på Backlog kort, dette sker for at sikre, at der er opgaver til at konsumere de til rådighed værende timer på de enkelte teammedlemmer.
Den optimale portefølje indeholder et godt mix af store projekter og små opgaver, eller et mix af deadline forpligtede opgaver og ikke forpligtede. Det gør det lettere at udnytte alle ressourcer optimalt.
Opbygning af artefakts
Product Backlog tavlen udtrykker portefølje prioriteringer. Den bruges til grov planlægning og Styregruppe præsentationer, for angivelse af projekt prioriteringer og estimeret afslutning. Vi har ikke længere brug for at udsende status rapport før de enkelte Styregruppe møder, der udarbejdes ej heller præsentationer, da vi bruger vores tavler til at tale ud fra. Dette sparer forberedelses tid, for den enkelte PPM.
Sprint Backlog tavlen er temmelig standard, dog med en enkelt kolonne tilføjelse ”Approval”. Tavlen er opdelt i projekter med prioritet 1 øverst. Så den enkelte skal prioritere sine task fra toppen og ned hvilke gør det let overskueligt.
Vi bruger gule sedler med standart inddeling og informationer, for alle planlagte task. Dette gør sedlerne let genkendelige for alle. Vi har haft mange og lange diskussioner om disse tasksedler: Skulle vi have hver sin farve sedler? hver sin farve tusch? ect, men enedes om, at vi alle har samme opdeling af informationer på taskseddel, så ved man hvor man skal lede efter sit navn. Dette sammen med, at man selv placerer sine task på boardet gør det let at genfinde sine opgaver.
Tekst på taskseddel:
Backlog kort nr. #
Opgavetekst
Estimerede timer
Initialer
Røde sedler: For uplanlagte tasks, der kommer på i løbet af sprintet (samme opdeling).
Wall of fame er vores status tavle, der viser hvor mange projekter, vi har i vores portefølje, hvor mange projekter, vi har afsluttet men som venter på implementering, og hvor mange projekter, der er helt afsluttede og arkiveret. Det samme gælder status på vores CAPA opgaver (Corrective And Preventive Actions, de haster altid).
Vi følger også udviklingen på nogle få udvalgte besparelses projekter, for at se om vi holder det forventede efter implementering. Vi kan ligeledes se timer til rådighed i indeværende Sprint, de estimerede timer for samme periode, og om vi har ressourcer, der er estimerede som overbelagt – ”rød smiley”. Der ud over kan vi se resultatet at sidste sprints ”udnyttelsesgrad”.
Status ved årskifte 2013/2014
Vi har brugt 22 Sprints af 3 ugers varighed på at komme frem til det, vi har i dag. Jeg mener selv, at vi nu er helt og fuldt udannede inden for brugen af Scrum konceptet.
Vi har et klart overblik over hvilke projekter, der ligger i vores Portefølje, og hvilken prioritet, de har. Prioriteter kan skifte, men da dette altid afklares i forbindelse med Styregruppe møde, og inden næste sprintplanlægning, er det blevet en naturlig del af vores hverdag, som sikrer den flexibilitet, som er nødvendig op imod omverdenens skiftende behov.
Der er ikke længere konflikter på ressourcer, da teammedlemmer hører til i faste Teams, og selv planlægger og estimerer deres timeforbrug for det kommende Spint. Ved deleressourcer aftales det fra Sprint til Sprint, hvor mange arbejdestimer, der må lægges på personen, fra det enkelte team.
Vi kender Teamets fremdrift og kan derfor langt bedre estimere gennemløbstider for de projekttyper, vi kender.
I foråret 2013 blev der afholdt en teamevaluering og -undersøgelse, hvor Scrum indgik som et delelement. Vi fik rigtig gode tilbagemeldinger, både på den nye teamstruktur og på at bruge Scrum i de enkelte Teams.
Scrum konceptet har givet os den ro og det overblik, der skal til for at sikre, at vi afslutter vores projekter til den aftalte tid, og i den prioriterede rækkefølge.
Change/transfer Teamet har i 2013 afsluttet 39 Change projekter. Men da det ikke tidligere har været muligt, ej heller ønsket, at måle på hvor mange projekter de enkelte afdelinger afsluttede pr. år, har vi ikke et tal, vi kan måle os op imod. Og da projekter kan variere meget i størrelse og varighed/gennemløbstid er antal gennemførte projekter ikke et mål i sig selv.
I 2014 vil vi tage udgangspunkt i vores erfaring fra 2013, og fastsætte mål på gennemførsel i henhold til aftalte deadline (planlagte mod faktiske).
Af Lene Becher Jensen, december 2013
