View Sidebar

Andre sites

Køb Scrum tilbehør og kurser on-line
ScrumMaster.dk shop

Login
 
 

Arkiv for kategori: Seneste Nyheder

Scrum Master kursus i Oslo

Scrum Master kursus i Oslo

ScrumMasterKursusOsloVi har nu i flere år holdt en lang række Certified Scrum Master kurser i samarbejde med Bouvet i Oslo og Stavanger, sidste kursus løb af stabelen her i august 2017. Der har været deltagere fra offentlige projekter, off-shore, den financielle sektor, web firmaer og generelle konsulenter.

Der er noget fælles skandinavisk over Scrum metoden. Den grundlæggende respekt for mennesker i organisationer og viljen til at give plads for individet er tilstede. Ind imellem er bagsiden af medaljen så, at vi ikke synes vi må stille krav til andre mennesker om “commitment”, vi har jo heller ikke et ord for det i vore sprog.

På billedet ses en koncentreret indsats på et af projekterne i undervisningen.

2017-08-22Se mere
Fra en ScrumMasters dagbog

Fra en ScrumMasters dagbog

We’re sorry this article has not been translated yet…marit_ween_brekken

En af de ScrumMastere, vi er i regelmæssig kontakt med, er Marit Ween Brekken fra Oslo. Marit havde behov for nogle ideer til at gennemføre retrospective i sit team på en ny måde. Vi genemgik “The Future Backwards” øvelsen og hun valgte at prøve den. Læs her, hvordan det gik…

jeg fikk testet “future backwards” øvelsen her før weekenden. Vi var et team på 8 personer som jeg delte inn i to grupper, og hadde 1,5 time til rådighet.TheFutureBackwards

Vi brukte 20 minutter på skrive lapper og diskutere “Hva er nåtilstand?”, så fikk begge teamene forklart og hengte opp lapper på tavlen. Deretter var det “Heaven” og ” Hendelse som kan føre til Heaven”. Det var veldig nyttig med grupper på 3-4 personer med forskjellig perspektiv (produkteier, utvikler, tester) og diskusjoner i gruppene. Tilbakemeldingene fra deltakerne var god, og vi klarte å holde bra engasjement igjennom 1,5 time fredag ettermiddag! Det gikk nesten 30 min til oppsummering og diskusjon over aksjonspunkter til slutt.

Lessons learned:
– små grupper passer for å engasjere alle
– man trenger minimum 15 min til diskusjon pr oppgave (Hva er nåtilstand)
– God tid på slutten til oppsummering og lage aksjonspunkter
– Konkrete aksjonspunkter og hvem som er ansvalig både pr teammedlem og for teamet

Jeg ser at det er veldig viktig både for teamet, og meg som scrum master å gjennomføre retrospectives på forskjellig måte, for at det skal være spennende, nyttig og engasjerende.

Takk for gode tips!

2014-03-03 Marit

2014-03-03Se mere
Scrum hos UnoMedical – Convatec Print

Scrum hos UnoMedical – Convatec Print

We’re sorry this article has not been translated yet…

LeneBecherJensenLene 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

UnoMedicalProductBacklog

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.

UnoMedicalSprintBoardSprint 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).

UnoMedicalWallOfFameWall 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

2013-12-22Se mere
Scrum på et Børnehjem i Tanzania

Scrum på et Børnehjem i Tanzania

SaraOgMiriamTZSara Brixen (højre) og Anne Miriam Bøytler er to certificerede ScrumMastere, der ikke er sådan at blæse af banen. I de sidste måneder har de arbejdet på at indføre Scrum i dagligdagen på et børnehjem i Tanzania. Der har været de forventelige op- og nedture, og de har måttet tilpasse Scrum mønstret til de ret specielle omstændigheder, men lige nu fungerer det godt. Her er deres historie:

Baggrund

Vi valgte at rejse til Tanzania med Brødremenighedens Danske Mission som volontører i august 2012 efter vores studentereksamen. De første 8 måneder, vi var i Tanzania, var vi på to forskellige projekter, men kendte godt til børnehjemmet Peter’s House. Det virkede som et sted, der havde brug for en hjælpende hånd i form af skemalægning og problemhåndtering. Den sidste aften inden vi rejste hjem, havde vi et møde med Knud Elmo Knudsen, som er missionær og bl.a. tilknyttet børnehjemmet. Vi fortalte ham om den lyst vi havde til at hjælpe børnehjemmet. Han var godt klar over, at vi gerne ville afsted igen og syntes det var en god idé at få os ind på Peters House.

I Danmark snakkede vi både med generalsekretæren og formanden for BDM omkring, hvad vores arbejdsopgave skulle være, da vi ikke skulle ud som almindelige volontører, men der rent faktisk var krav til det arbejde, vi skulle i gang med. Formanden Jørgen Bøytler anbefalede at vi kontaktede Kurt Nielsen som er ledelsesrådgiver og certificeret ScrumMaster og Scrum Trainer. Kurt tilbød os et kursus i Scrum, som ville kunne hjælpe os med arbejdet på Peters House og det takkede vi ja til. Vores første tanker omkring Scrum var, at det var et indviklet system, som ville være alt for kompliceret til et børnehjem, hvor man ikke er vant til at strukturere arbejdet på sådanne måder. Men i løbet af kurset fik vi nogle redskaber, som uden tvivl ville gavne Peters House. Det var især Sprint Backloggen og de Daily Scrum Meetings, som ville være meget brugbare. Det visuelle i Sprint Backloggen giver teamet en mere overskuelig plan over de ting, der skal gøres inden for det Sprint, de er i gang med, og derved kan de bedre estimere deres tid, også i forhold til børnene. Daily Scrum Meeting giver god kommunikation i teamet, der kan lederen Robert Manyika også få et indblik i, hvad teamet går og arbejder med og om de har nogle forhindringer.

Indførelse af Scrum

RobertMamaerneBørneneI august 2013 kom vi til Tanzania igen. Nu skulle vores Scrum eventyr virkelig begynde. Vi havde haft en masse tanker omkring hele forløbet, og hvordan medarbejderne på børnehjemmet ville tage i mod noget så nyt som Scrum tankegangen. Vores første indtryk var, at det i virkeligheden gik rigtig godt på Peters House, men efterhånden fandt vi ud af, at der var nogle problemer især med punktligheden i forhold til mad og børn. Derfor valgte vi at gå stille frem, et skridt af gangen og gik i første omgang i gang med Sprint backloggen. Hvis man sætter børnehjemmet i forhold til Dave Snowdens Cynefin Framework, som vi havde hørt om på Scrum kurset, befandt det sig i kaos området, hvilket ikke var sundt, hverken for medarbejdere eller børn. Vi måtte handle for at komme ud af kaos, vi bestemte i første omgang, hvad der skulle laves, og hvad der var det vigtigste at få gjort, så Peters House kunne komme væk fra kaos stadiet og op imellem det komplekse og kompliceret område. Det gjorde vi ved at være fastholdende i Daily Scrum Meetings, holde øje med Sprint Backloggen og have forskellige møder med lederen Robert Manyika. Hans første indtryk af Scrum var, at det virkede besværligt, men kunne godt se fordelene i det, hvis det kunne komme til at fungere. Robert Manyika var meget opsat på at få det til at køre, da han udmærket var klar over at Peters House stod med forskellige problemer.

PiterScrumTZVores Sprint Backlog var lidt anderledes end den normale. Vi havde en ekstra kolonne til daglige opgaver, som også var markeret med en anden farve. Vi havde lamineret vores Backlog og brugte forskellige farvede post-its som vi havde medbragt fra Danmark til netop dette formål. Vi placerede Backloggen et sted, hvor alle kunne følge med i de forskellige daglige og ugentlige processer. Det første Sprint Planning Meeting havde vi kun med Robert, hvor vi forklarede ham, hvordan man brugte den og fordelene ved dette. Han tilføjede nogle opgaver, men var positiv stemt i forhold til dette. Sprint Planning Meeting nummer 2 holdte vi sammen med alle medarbejderne, som består af to praktikanter, tre mamaer, en volontør mere samt lederen Robert. Robert gennemgik alle opgaverne med medarbejderne og forklarede hvordan man skulle flytte de forskellige post-its fra ”To Do” og ”Daily” til ”In Progress” og når de var færdige skulle den opgave flyttes til ”Done”. Medarbejderne tog godt i mod det, og var allerede på det tidspunkt, meget taknemmelige over, at vi havde overskueliggjort hverdagen. Derfra holdte vi de daglige møder hver dag kl. 8, hvor vi gennemgik dagens program og de problemer, de hver især mødte. Det hele gik meget godt, og de begyndte at kunne se fordelene ved at bruge denne teknik.

Vi rammer en mur

Efter en måned hvor det hele kørte på skinner, ramte vi en mur. Vi kunne ikke længere se fordelene ved Scrum, teamet flyttede sig ikke og de begyndte at gå tilbage til deres gamle vaner. Maden blev ikke lavet til tiden, børnene kom ikke i bad og om natten kom de små ikke op på toilet. Derudover fungerede vores Sprint Backlog heller ikke længere optimalt, da der var meget støv i luften, så de post-its vi brugte, ikke kunne klistre sig fast på Backloggen. Daily Scrum Meetings blev ikke overholdt, tidspunkter og aftaler gik i vasken. Så alt hvad der hed punktlighed, forsvandt lige så hurtigt, som det var kommet. De tider vi havde estimeret opgaverne til, passede heller ikke mere og derfor brugte de mindre og mindre Sprint Backloggen. Vi var endt tilbage til kaos situationen. For os som volontører, var det en nedtur at se, de var faldet tilbage i de gamle rutiner. Vi vidste, at nu måtte vi gøre en stor indsats, for at Scrum ville kunne komme til at fungere.

Vi satte os ned med Knud Knudsen, som er den missionær, vi er tilknyttet, og ham, der er den øverste leder for børnehjemmet. Vi gik i gang med at forklare Scrum til ham og vores idé med at give Robert mere ansvar og i sidste ende gøre ham til ScrumMaster. Knud Knudsen syntes det var en god idé, men kunne også se, at der skulle lægges noget arbejde og commitment i det. Sprint Backloggen fik også et nyt udseende i form af en metalplade med magneter, så opgaverne ikke mere skulle kunne falde af.

Vedholdende coaching

Derefter begyndte vi at have et par møder i ugen omkring Scrum og hele konceptet bag det. Vi prøvede at forklare Robert Scrum konceptet bedst muligt, udfra hvad vi selv havde lært på det kursus, vi havde været på. Han fik efterhånden vores Scrum materiale, hvilket hjalp ham meget med at forstå hele tankegangen bag Scrum. Han begyndte, at kunne se, hvordan Scrum fungerer, og hvordan han selv skulle agere som ScrumMaster. Han udviklede sig meget, igennem vores møder og det læsestof han havde fået. Han blev en helt anden leder, med en lyst for at få Scrum til at fungere på Peters House. Robert siger selv, at han som leder bliver nødt til at være der for sit team, give dem gode råd og hjælpe dem igennem deres problemer – også dem de har udover Peters House. Han støtter og passer på sit team, så de kan arbejde fokuseret og målrettet på deres forskellige opgaver. Efterhånden tog Robert over både med Daily Scrum Meetings og tilføjede flere og flere opgaver, da teamet udviklede sig i den positive retning og blev mere effektive. Robert kunne dog se at selve arbejdsfordelingen i mellem mamaerne skulle ændres, så han byttede rundt på de forskellige mamaers arbejdstider. Dette resulterede i at maden blev lavet til tiden, børnene var pæne og de arbejder nu også på at få børnene vænnet af med at tisse i sengen.

Det daglige fungerer, tid til Product Backloggen

Som tiden skred frem, valgte vi at indføre Product Backloggen til lidt mere strategisk planlægning, da selve Scrum konceptet i dagligdagen var kørt godt ind. Vi satte os endnu engang med Knud Knudsen og diskuterede, om vi kunne tilføje mere til vores Scrum forløb. Vi blev enige om at Product Backloggen var en god idé, da den også viser, at man skal tænke fremad. Først holdte vi møde med Robert Manyika, hvor vi planlagde de næste 3 Sprint på to ugers længde. Det var i realiteten meningen at Knud Knudsen skulle have været med til dette møde, da han er Product Owner. Pga. omstændighederne blev mødet kun afholdt af Sara, Robert og Miriam. Da vi havde lavet Product Backloggen, viste vi den til Knud, og han var enig i, at det var en realistisk plan. Den hænger nu og er synlig på kontoret og tingene bliver gjort. Sprint Backloggen og Product Backloggen følges nu ad, og det hele forløber planmæssigt.

RobertScrumTZRobert er så opsat på at det fortsat skal fungere, så nu skal børnene fra Peters House også til at være en del af Scrum. Han vil i december 2013 lave en Sprint Backlog for dem, da de har fri fra skole. Her vil de hver især komme i forskellige teams og have hver deres opgave. Han er meget taknemmelig for, at vi har introduceret ham fra Scrum, da han kan se at opgaverne bliver gjort hurtigere og bedre kan overskue de opgaver, der skal gøres og derved også vejlede sit team i den rigtige retning. Den måde, de gør det på er, at de daglige rutiner har faste tidspunkter. De starter et sted og arbejder sig igennem de forskellige opgaver, og ved slutningen af deres arbejdsdag har de derved også haft tid til børnene.

Konklusion

Hele forløbet igennem har vi haft op- og nedture. Det har været en stor udfordring og har til tider set sort ud. Kulturen og hele tankegangen med at få noget gjort, er så anderledes fra hvad vi kender hjemmefra, så det været en af de store udfordringer. Takket være Roberts commitment og lyst til at få Scrum til at fungere, kan vi nu i dag sige at Scrum også virker på et børnehjem i Tanzania.

Af Sara Brixen og Anne Miriam Bøytler, November 2013

2013-11-10Se mere
Indtryk fra papirfly øvelsen

Indtryk fra papirfly øvelsen

Indtryk fra Papirfly øvelsen

We’re sorry this article has not been translated yet…

RagnhildPapirFlyver

På andendagen af vores CSM kursus bruger vi ofte en øvelse i at producere papirfly. En af vore ScrumMastere fra Norge,  Ragnhild Holte Bøe, http://no.linkedin.com/pub/ragnhild-holte-b%C3%B8e/2/574/5b3/da, kommenterer her:

PaperFlyerTrainingsPictureDet var en ting jeg hadde lyst til å nevne ifm papirflybrettingen. Jeg skjønte ikke brettemetoden og fikk i starten ikke til å brette et eneste fly. Men da vi satte oss sammen to og to, og jeg kunne se på hva partneren min gjorde gikk det utrolig mye bedre. Vi brettet flere fly enn de andre to parene tilsammen.

Dette illustrerer et viktig poeng og en egenskap jeg tror mange har: at man fungerer bedre gjennom samarbeid! Man får rett og slett gjennomført mer. Eller, dvs at en “mindre flink” person, mestrer like bra som en “flink” person gjennom samarbeid med en annen. (veldig forenklet sagt)

Lykke til videre!, hilsen Ragnhild

2013-04-22Se mere
Steve Dennings nye bog

Steve Dennings nye bog

Steve Dennings nye bog

Stephen Dennings ny bog, The Leader’s Guide to Radical Management tager fat i nogle af de vigtigste principper i Lean, Agile og Scrum og kombinerer dem i en højst meningsfyldt syntese for ledelse i det 21. århundrede. Han beskriver 7 grundprincipper så som kundedrevne iterationer, selvorganiserende teams og gennemført synlighed, disse fremstår fra for eksempel Scrum og er fundamnetet for hans tænkning opmkring arbejde.

Formålet med bogen er at få læseren til at skifte fokus fra selve processen to kunden, processen er kun et middel til at nå et mål. Set på den måde bliver fokus “at begejstre kunden”, det skaber en hær af folk, der promoter produkter og dermed vækst. Igennem konstnat innovation og forbedring kan organisationen levere ny værdi til kunden i hver iteration.

På grund af den omsiggribende kompleksitet i verden omkring os, er virksomheder nødt til at skabe et miljø som er åbent og parat til at reagere hurtigt på ændringer. Lederens rolle bliver at udruste teams til at handle. Konstant forbedring er ikke kun ledderens ansvar, men det udførende team er selv den vigtigste bidragyder til denne process.

Når en virksomhed ledes ledes med “Radikal ledelse”, så er formålet ikke længere at producere varer eller services men at begejstre og tjene kunden.

En uddybende artikel kan downloades her

2011-10-27Se mere