Inledning
”Scrum är en metodik för systemutveckling skapad av Jeff Sutherland och Ken Schwaber. Scrum har tillämpats sedan tidigt 1990-tal och formaliserades 1995. Scrum är ett kraftfullt sätt att fördela arbetsuppgifter i tiden med bibehållet fokus på levererad affärsnytta.”
- Wikipedia om Scrum.
Denna spännande projektmodell har jag alltså haft nöjet att få prova på när vi arrangerade vår klassfest. Till skillnad ifrån våra vanliga projektmodeller så var vi helt plötsligt i en mycket större symbios än tidigare även om det hela kändes mycket ostrukturerat. Just i vårt fall så kände jag även att det egna ansvaret var stort, nästan större än i vanliga projektgrupper eftersom projektledaren eller Scrum-mastern i detta fallet inte var så kontrollerande. I detta fallet så skulle vi som sagt arrangera en klassfest med allt vad det innebar. Scrum-modellen lämpade sig inte jättebra för detta eftersom vi var en liten grupp och det inte fanns några tydliga krav på leverans eller kvalité. När jag fick höra att Scrum är designad för större mjukvaruföretag så föll polletten ner, det är definitivt en projektmodell som lämpar sig för sådana företag. Jag har försökt att jämföra Scrum som projektmodell med den vanliga vattenfallsmetoden som jag vanligtvis arbetat i och sorterat dessa jämförelser under olika rubriker.
Transparens
Scrum är ett i sanning transparent arbetssätt. Till skillnad ifrån vanliga projektmodeller där man arbetar i stängda grupper med enskilda uppgifter så arbetar man sida vid sida med alla som deltar i projektet. Alla vet vad alla håller på med och man kan lätt se vad som behövs göras eftersom den allsmäktiga backloggen sitter på väggen och dikterar vad som behöver göras. Varje gång den förändras så syns det väldigt tydligt och man märker hur viktigt det är att backloggen sitter centralt så att alla har koll. En annan fördel med transparensen var att man kunde ta hjälp av den sammanlagda kompetensen som fanns i projektgruppen som stort. Man är inte på något sätt begränsad till en enskild projektgrupp och kan därmed alltid se till att man har ”rätt man på rätt plats” för att därmed öka produktiviteten och kvalitén.
Hierarkier
I Scrum så fungerar hierarkierna väldigt speciellt. Just i vårt fall så fann jag det svårt att definiera exakt vad Scrum-mastern skulle göra. Hierarkin var väldigt platt och alla deltog i arbetet tillsammans som i ett trevligt kollektiv. Backloggen satt på väggen och definierade prioriteringen och Scrum-mastern pratade med product ownern för att hela tiden hålla backloggen uppdaterad. När Scrum-mastern sedan kom tillbaka ifrån det dagliga mötet så hände inte så mycket eftersom arbetet redan var i full gång. Jag skulle känna mig tryggare om respektive Scrum-master hade haft ett stående möte med sin grupp för att alla skulle få bättre koll på vad som hände i respektive grupp, så att man verkligen utnyttjar den transparensen som finns medfött i Scrum-modellen.
Kommunikation
Kommunikationen skedde sporadiskt och utan scheman. Man rapporterade till Scrum-mastern men försökte ändå att hålla sig uppdaterad om vad som hände i de grupper som man arbetade bredvid. Det var väldigt skönt att hela tiden veta vad som hände runtomkring sig men jag känner fortfarande att jag skulle vilja ha mer struktur i kommunikationen. Det som är bra är att alla möten ska ske stående i Scrum eftersom de inte får ta så lång tid. Med detta i baktanken så behöver man inte vara rädd för att schemalägga möten, något som hade behövts för att hela tiden se till att alla i gruppen har koll på backloggen och vet hur prioriteringen ser ut och hur långt alla har kommit. Man kan se grupperna som hjul där Scrum-mastern är navet i hjulet istället för de vanliga projektgrupperna där projektledaren är toppen på en pyramid.
Leveranser
Detta skede av processen var också väldigt otydligt för mig när vi använde Scrum. Det kan som sagt bero på att jag inte var Scrum-master och därmed missade en hel del av själva överlämnandet. Eftersom vi inte heller arbeta med några produkter utan bara delar av ett arrangemang så var det svårt att leverera. När jag själv levererade så var det helt enkelt så att jag sa att min uppgift var fixad och så arrangerade vi om i backloggen. Vad som var positivt var att vi hela tiden kunde se hur det vi låg till i projektet eftersom backloggen hela tiden förändrades. Man kunde också se väldigt tydligt hur projektet hela tiden skrider framåt och vad som behöver göras.
Kvalité
Kvalitén på de saker vi levererade var väldigt svår att bestämma när vi arbetade eftersom det handlade om arrangerat av en fest och inte levererande av faktiska produkter. Festen i sig blev väldigt lyckad och många tyckte om det men det är fortfarande svårt att mäta kvalitén på festen då vi inte hade någon tydlig kravspecifikation. Jag tror att kvalitén på de produkter man tillverkar i en Scrum-process rimligtvis blir högre på grund utav transparensen. Man kan utnyttja vilken kompetens som helst i vilken grupp som helst för att se till att kvalitén alltid blir den bästa.
Slutsats
Scrum-modellen är en välutvecklad och genomtänkt projektmodell designad för större företag. Detta märks tydligt i hur arbetet förflöt och vilka problem som uppstod när 3 av 4 personer i en grupp var frånvarande. Arbetet förflöt hela tiden framåt och man kände verkligen att man fick saker gjort, speciellt eftersom man kunde skrida över projektgruppsgränserna för att utnyttja olika personers kompetenser. Jag skulle mer än gärna arbeta i Scrum igen, gärna i ett projekt där man framställer produkter eller delar av en produkt där man belyser leverans- och kvalité-aspekterna av projektet. Det hade varit kul att vara Scrum-master eller se hur en riktig Scrum-master arbetar för att kunna se de verkliga skillnaderna mellan projektmodellerna. Jag kan rekommendera alla som arbetar med projektledning att prova på Scrum för att aktivt jämföra med de projektmodeller som de vanligtvis använder och verkligen känna på de skillnader som finns. Många har sagt att när man en gång använt Scrum så kan man aldrig vända tillbaka men jag måste ändå accentuera att det inte är något fel på vattenfallsmodellen och att det i flera fall kan löna sig istället för att använda Scrum. Nyast är inte alltid bäst i alla fall.
