Er du på Scrum?
En regning og et suk. Kender du den situation? Hvis du har prøvet at bestille noget it, så kan du sikkert også nikke genkendende til følgende situation: Du siger: 'Jeg vil gerne kunne sådan og sådan, og det skal virke sammen med vores andre webapplikationer eller systemer'. Når du så får overdraget resultatet af din leverandørs slid og slæb, så er det alligevel ikke helt det, du forventede. Men hvad nu, hvis regningen først kommer, når du er tilfreds? Det stræber Scrum efter. Måske skulle du prøve at komme Scrum. En ny og anderledes måde at udvikle IT projekter på. Scrum giver dig nemlig en unik mulighed for at følge og kontrollere tilblivelsen af din ide. Bliver Scrum en del af udviklerens hverdag, så er chancen for at stå med et slutprodukt, der rammer plet ved premieren, meget højere, da det er blevet ordentligt tilpasset , afprøvet og justeret undervejs.
af Elisabeth Tejlmand
Scrum er et sæt spilleregler for en proces
I teams, der arbejder efter Scrum-metoden, har bestiller, udviklere og testere hver deres rolle og samarbejder på en måde, hvor man hele tiden inspicerer og tilpasser. I kontrast til dette står it-projekter, hvor det bestilte og hele udviklingsprocessen nøje beskrives, inden selve kodearbejdet begynder.
Som bestiller får du titel af ProduktOwner. Og din opgave er at opdatere en liste, der indeholder ønsker, fejl og mangler ved det produkt, du har bestilt. Listen kaldes en backlog. Ønsker, fejl og mangler på backloggen kalder man userstories (stories). Stories skriver man ud fra følgende skabelon:
Som [bruger] ønsker jeg mig [ønske] for dermed at [værdi]. Et eksempel fra min hverdag kunne være:
'som håndboldspiller skal jeg kunne fremsøge klubber nær mit hjem, hvor jeg kan dyrke min sport for at sikre implementering af strategi 2012.'
Inden kodningen på en story begynder, skal den estimeres. Det foregår på møder, hvor alle parter i teamet samles for at tale story’en (opgaven) igennem. Udviklerne taler om, hvordan opgaven kan løses, og man får som bestiller en forståelse for opgavens egentlige it-mæssige omfang. Og så starter selve kodearbejdet – uden yderligere skriftlighed. Hver dag samles teamet til et møde, hvor man taler om den foregående dags arbejde, eventuelle forhindringer, og hvad den følgende arbejdsdag skal gå med.
Mange udviklere – Scrumtilhængere – mener, at Scrum øger produktiviteten. Jeg er ikke stødt på egentlig dokumentation for dette, i mine øjne må det dog tale til Scrums fordel, at man som kunde qua den dybe involvering entydigt definerer, hvornår det bestilte er færdigt. Det skaber tilfredshed, og tilfredse kunder har det med at komme igen.
Scrums ’far’ hedder Jeff Sutherland. Han har en blog om fænomenet Scrum og agil software udvikling som er det overordnede paraply begreb bag Scrum – altså hvor udviklingsarbejdet er præget af høj grad af tilpasning undervejs. Han var i 80’erne medforfatter på the Agile Manifesto, der gjorde op med de nøje beskrevne it-projekter, hvor tunge dokumentationskrav var med til at forsinke udviklingsarbejdet – uden at sikre kunden fuld tilfredshed. Udviklere over hele verden har taget tanken om den tætte kundedialog og fleksible tilgang til udviklingsprocessen til sig. Denne video uddyber agil softwareudvikling. (8 min. video)
Scrum - forklaret på under ti minutter (engelsk)
Foruden produktejer-rollen definerede Jeff Sutherland to andre roller:
Scrummaster:
Denne person er it-uddannet og som oftest en erfaren udvikler. Han/hun er først og fremmest teamets beskytter. Scrummaster sikrer, at opgaverne ikke vokser i omfang og tid, men skal også være i stand til at identificere muligheder, der opstår undervejs, og som kan bidrage positivt til produktet. Han/hun planlægger møder og afvikler dem med behørig hensyntagen til ferie, sygdom etc. Han/hun rydder eventuelle tekniske forhindringer af vejen og sikrer fremdrift og synlighed omkring det.
Webopgaverne kommer bedst gennem produktionsforløbet, hvis der er tæt dialog mellem ProductOwner og Scrummaster. På min arbejdsplads taler vi ofte ideer og ønsker igennem, lang tid før de estimeres af teamet. Vi kigger på skitser og identificerer spørgsmål, som vi har brug for svar på. De største webopgaver skaber Scrummaster tid til, at der udvikles testudgaver på.
I Scrums oprindelige form er Scrummasteren den eneste udvikler med kontakt til ProduktOwner. Scrummaster agerer indad i teamet som coach og planlægger og skriver ikke kode selv. Hos os sad ’den erfarne udvikler’ førhen ofte alene med ideudvikling og eksekvering. Han opbyggede en stor, special viden om, hvordan lige netop vores systemer skal håndteres, mens de andre var stort set blanke, når han holdt ferie etc. Med Scrum sker der en stor vidensdeling.
Teamet:
Holdet af udviklere. Medlemmerne af teamet bør komplementere hinanden fagligt, så det spænder vidt fra informationsarkitekter og systemudviklere til frontendudviklere og testere. Når et team arbejder efter Scrum-metoden, er deres arbejde opdelt i sprints (fx lig med en måned). Inden for dette sprint afvikles en række møder med hver sin agenda og dertilhørende spørgsmål, der skal sikres svar på. Ifølge de udviklere, jeg har min daglige gang op ad, er det her, Scrum virkelig gør en afgørende forskel. Hardcore interesserede kan finde links nederst.
Jeg er Scrum-tilhænger, fordi:
1. Scrum bringer mig helt tæt på maskinrummet uden at skulle sidde lårene af udviklerne for at forstå, hvad jeg er ved at sende ud i verden (det er effektivt).
2. Scrum gør mig i stand til - med et minimum af it-viden - at give udviklerne de svar, de har brug for. (det er begavet).
3. Scrum skaber åbenhed, når ideen ikke holder hele vejen igennem, og forståelse omkring, hvordan ideen må skæres til, fordi alle involveres i beslutningerne (det er empowerment).
4. Scrum gør mig i stand til at forklare min omverden, hvor meget tid der er nødvendig, for at jeg kan komme i mål med en handlingsplan eller en strategiplan (det er praktisk).
5. Samme synliggørelse (punkt 4) er et godt udgangspunkt for arbejdet med strategi og handlingsplaner (det er rart, hvis man er alene om at se webs forretningsstrategiske muligheder).
Hvornår virker Scrum ikke?
Dette spørgsmål læste jeg en ivrig scrumblogger besvare fornylig. Han oplister følgende tre scenarier:
1. Når teamet ikke er i stand til at føre en meningsfuld dialog med omverdenen. De kan måske ikke forklare sig - eller de nægter at bidrage kreativt.
2. Når teamets samlede faglige ressourcer er skæve i forhold til, hvad deres arbejdsgiver vil.
3. Når opgaven omhandler dybereliggende systemproblematikker.
Jeg vil tilføje endnu et punkt:
4. Hvis ansvaret for teknikken ikke entydigt er placeret i it-afdelingen. Det er alles ansvar, at vi er bevidste om konsekvenserne af vores arbejde, men der er tekniske sammenhænge, som jeg ikke har nogen chance for at kunne identificere. Så når dagen er omme, er det stadig it-afdelingens ansvar, at teknikken spiller.
Udviklerne har kastet handsken
Med Scrum har udviklerne kastet handsken for fødderne af salg, marketing og kommunikation. For organisationer med inhouse udviklere er der i mine øjne god mening i at samle handsken op. Men det ligger fast, at man får mulighed for at opnå en høj grad af beslutningskompetence, engagement og ansvarlighed. Åbenhed omkring processer og resultater samt en tæt involvering gør det nemt for opgavestilleren at følge arbejdet og rette til, så slutproduktet skaber en følelsen af ’we did this’ i stedet for møder om, hvorfor det gik, som det gik.
Om dette også gælder for udviklingsarbejde, der kører hos en ekstern partner, er jeg ikke afklaret om. Jeg vil heller ikke slå på tromme for, at salg, marketing og kommunikation kækt opgiver alle krav om dokumentation og så at sige stiller en konto til rådighed for it-afdelingen eller leverandøren. Men jeg vil opfordre til, at chefer med udstrakt trang til skriftlighed ned i detaljerne i al stilfærdighed prikker deres netværk på skulderen og spørger til deres erfaringer med agil softwareudvikling.
Links:
Scrum - forklaret på under ti minutter (engelsk)
http://www.youtube.com/watch?v=Q5k7a9YEoUI
Vores seneste webprojekt - program Landsstævne 2009 (vi arbejder stadig på den)
http://www.l2009.dk/foralle/fredag/Staevnecentrum.aspx
For de ekstremt interesserede
http://www.agile-software-development.com/
(blog om projektledelse inden for agil software udvikling)
I teams, der arbejder efter Scrum-metoden, har bestiller, udviklere og testere hver deres rolle og samarbejder på en måde, hvor man hele tiden inspicerer og tilpasser. I kontrast til dette står it-projekter, hvor det bestilte og hele udviklingsprocessen nøje beskrives, inden selve kodearbejdet begynder.
Som bestiller får du titel af ProduktOwner. Og din opgave er at opdatere en liste, der indeholder ønsker, fejl og mangler ved det produkt, du har bestilt. Listen kaldes en backlog. Ønsker, fejl og mangler på backloggen kalder man userstories (stories). Stories skriver man ud fra følgende skabelon:
Som [bruger] ønsker jeg mig [ønske] for dermed at [værdi]. Et eksempel fra min hverdag kunne være:
'som håndboldspiller skal jeg kunne fremsøge klubber nær mit hjem, hvor jeg kan dyrke min sport for at sikre implementering af strategi 2012.'
Inden kodningen på en story begynder, skal den estimeres. Det foregår på møder, hvor alle parter i teamet samles for at tale story’en (opgaven) igennem. Udviklerne taler om, hvordan opgaven kan løses, og man får som bestiller en forståelse for opgavens egentlige it-mæssige omfang. Og så starter selve kodearbejdet – uden yderligere skriftlighed. Hver dag samles teamet til et møde, hvor man taler om den foregående dags arbejde, eventuelle forhindringer, og hvad den følgende arbejdsdag skal gå med.
Mange udviklere – Scrumtilhængere – mener, at Scrum øger produktiviteten. Jeg er ikke stødt på egentlig dokumentation for dette, i mine øjne må det dog tale til Scrums fordel, at man som kunde qua den dybe involvering entydigt definerer, hvornår det bestilte er færdigt. Det skaber tilfredshed, og tilfredse kunder har det med at komme igen.
Scrums ’far’ hedder Jeff Sutherland. Han har en blog om fænomenet Scrum og agil software udvikling som er det overordnede paraply begreb bag Scrum – altså hvor udviklingsarbejdet er præget af høj grad af tilpasning undervejs. Han var i 80’erne medforfatter på the Agile Manifesto, der gjorde op med de nøje beskrevne it-projekter, hvor tunge dokumentationskrav var med til at forsinke udviklingsarbejdet – uden at sikre kunden fuld tilfredshed. Udviklere over hele verden har taget tanken om den tætte kundedialog og fleksible tilgang til udviklingsprocessen til sig. Denne video uddyber agil softwareudvikling. (8 min. video)
Scrum - forklaret på under ti minutter (engelsk)
Foruden produktejer-rollen definerede Jeff Sutherland to andre roller:
Scrummaster:
Denne person er it-uddannet og som oftest en erfaren udvikler. Han/hun er først og fremmest teamets beskytter. Scrummaster sikrer, at opgaverne ikke vokser i omfang og tid, men skal også være i stand til at identificere muligheder, der opstår undervejs, og som kan bidrage positivt til produktet. Han/hun planlægger møder og afvikler dem med behørig hensyntagen til ferie, sygdom etc. Han/hun rydder eventuelle tekniske forhindringer af vejen og sikrer fremdrift og synlighed omkring det.
Webopgaverne kommer bedst gennem produktionsforløbet, hvis der er tæt dialog mellem ProductOwner og Scrummaster. På min arbejdsplads taler vi ofte ideer og ønsker igennem, lang tid før de estimeres af teamet. Vi kigger på skitser og identificerer spørgsmål, som vi har brug for svar på. De største webopgaver skaber Scrummaster tid til, at der udvikles testudgaver på.
I Scrums oprindelige form er Scrummasteren den eneste udvikler med kontakt til ProduktOwner. Scrummaster agerer indad i teamet som coach og planlægger og skriver ikke kode selv. Hos os sad ’den erfarne udvikler’ førhen ofte alene med ideudvikling og eksekvering. Han opbyggede en stor, special viden om, hvordan lige netop vores systemer skal håndteres, mens de andre var stort set blanke, når han holdt ferie etc. Med Scrum sker der en stor vidensdeling.
Teamet:
Holdet af udviklere. Medlemmerne af teamet bør komplementere hinanden fagligt, så det spænder vidt fra informationsarkitekter og systemudviklere til frontendudviklere og testere. Når et team arbejder efter Scrum-metoden, er deres arbejde opdelt i sprints (fx lig med en måned). Inden for dette sprint afvikles en række møder med hver sin agenda og dertilhørende spørgsmål, der skal sikres svar på. Ifølge de udviklere, jeg har min daglige gang op ad, er det her, Scrum virkelig gør en afgørende forskel. Hardcore interesserede kan finde links nederst.
Jeg er Scrum-tilhænger, fordi:
1. Scrum bringer mig helt tæt på maskinrummet uden at skulle sidde lårene af udviklerne for at forstå, hvad jeg er ved at sende ud i verden (det er effektivt).
2. Scrum gør mig i stand til - med et minimum af it-viden - at give udviklerne de svar, de har brug for. (det er begavet).
3. Scrum skaber åbenhed, når ideen ikke holder hele vejen igennem, og forståelse omkring, hvordan ideen må skæres til, fordi alle involveres i beslutningerne (det er empowerment).
4. Scrum gør mig i stand til at forklare min omverden, hvor meget tid der er nødvendig, for at jeg kan komme i mål med en handlingsplan eller en strategiplan (det er praktisk).
5. Samme synliggørelse (punkt 4) er et godt udgangspunkt for arbejdet med strategi og handlingsplaner (det er rart, hvis man er alene om at se webs forretningsstrategiske muligheder).
Hvornår virker Scrum ikke?
Dette spørgsmål læste jeg en ivrig scrumblogger besvare fornylig. Han oplister følgende tre scenarier:
1. Når teamet ikke er i stand til at føre en meningsfuld dialog med omverdenen. De kan måske ikke forklare sig - eller de nægter at bidrage kreativt.
2. Når teamets samlede faglige ressourcer er skæve i forhold til, hvad deres arbejdsgiver vil.
3. Når opgaven omhandler dybereliggende systemproblematikker.
Jeg vil tilføje endnu et punkt:
4. Hvis ansvaret for teknikken ikke entydigt er placeret i it-afdelingen. Det er alles ansvar, at vi er bevidste om konsekvenserne af vores arbejde, men der er tekniske sammenhænge, som jeg ikke har nogen chance for at kunne identificere. Så når dagen er omme, er det stadig it-afdelingens ansvar, at teknikken spiller.
Udviklerne har kastet handsken
Med Scrum har udviklerne kastet handsken for fødderne af salg, marketing og kommunikation. For organisationer med inhouse udviklere er der i mine øjne god mening i at samle handsken op. Men det ligger fast, at man får mulighed for at opnå en høj grad af beslutningskompetence, engagement og ansvarlighed. Åbenhed omkring processer og resultater samt en tæt involvering gør det nemt for opgavestilleren at følge arbejdet og rette til, så slutproduktet skaber en følelsen af ’we did this’ i stedet for møder om, hvorfor det gik, som det gik.
Om dette også gælder for udviklingsarbejde, der kører hos en ekstern partner, er jeg ikke afklaret om. Jeg vil heller ikke slå på tromme for, at salg, marketing og kommunikation kækt opgiver alle krav om dokumentation og så at sige stiller en konto til rådighed for it-afdelingen eller leverandøren. Men jeg vil opfordre til, at chefer med udstrakt trang til skriftlighed ned i detaljerne i al stilfærdighed prikker deres netværk på skulderen og spørger til deres erfaringer med agil softwareudvikling.
Agile Project Management with Scrum
View more presentations from aditya.internet.
Links:
Scrum - forklaret på under ti minutter (engelsk)
http://www.youtube.com/watch?v=Q5k7a9YEoUI
Vores seneste webprojekt - program Landsstævne 2009 (vi arbejder stadig på den)
http://www.l2009.dk/foralle/fredag/Staevnecentrum.aspx
For de ekstremt interesserede
http://www.agile-software-development.com/
(blog om projektledelse inden for agil software udvikling)
