I en vecka under höstterminen har vi i klassen provat att använda den sk. lättviktiga projektmodellen Scrum som är en agile-metod för systemutveckling och projektledning. Modellen skapad av Jeff Sutherland och Ken Schwaber och har sedan 1990-talet blivit mer och mer tillämpad. Idag är Scrum är mest känd bland företag i mjukvarubranschen men det finns goda poänger med att leka med Scrum även i andra världar.

Vad är då mest tydliga skillnader mellan Scrum och traditionella projektmodeller, såsom exempelvis vattenfallsmetoden? Med utgångspunkt av vårt i klassen genomförda projekt så går jag här igenom ett antal samlat i sex punkter. Transparens, hierarkier, kommunikation, leveranser, kvalitet och en slutsats. Ta dock i beaktning att detta inte blir någon djupdykning eftersom vi enbart arbetade med Scrum i ett fåtal dagar.

Wikipedia om Scrum:
Scrum is an iterative incremental process of software development commonly used with agile software development

Wikipedia om Vattenfallsmodellen (Waterfall model):
The waterfall model is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance.

 

Transparens

Jag har alltid varit en stark anhängare av motivation. Att vara motiverad inför sin uppgift, att vilja offra tid – alltså energi för att uppnå ett mål fungerar alltid bäst om du själv verkligen vill det. Vad som är din drivkraft är upp till dig – men det finns oftast något som sätter igång ens processer ordentligt. Här är Scrum är starkt. Medan vattenfallsmodellen leder framåt utan att alla projektmedlemmar förstår alla delmål så visar Scrum i dess backlogg hela tiden upp allt som behöver göras. 

Backloggen eller scrum-tavlan består av “stories” rangordande i prioritet. En typ av GTD (Getting Things Done). Sedan kommer “sprints” och “potentiellt leveransklara produkter”. Gruppen tar stories och kör sprints i som pågår i 24 timmar. Sprints upprepas sedan. Man använder också den rangordning som görs med stories för att veta vad man ska göra härnäst. De mest tidskrävande och resurskrävande ska bli avklarade först.

Här arbetar man inte heller i en enskild projektgrupp utan sida vid sida. Man kan snabbt omflyttas till en annan uppgift om ens förmågor är mer behövda någon annanstans.

Allt är öppet, tydligt och kan absolut vara motivationshöjande.

Hierarkier

I Scrum finns tre roller, Owner (projektägare), Scrum-master (projektledare) och team (projektmedlemmar). Dessa kallas för “Pig”-roller. Det finns även tre stycken “Chicken”-roller men dessa är roller som endast har yttre påverkansfaktor.

Ägaren (Owner) för hela projekten får rapporter från projektledare (Scrum-masters) som har egna projektgrupper (team). Owner tar beslut grundande på den feedback som Scrum-masters ger.

Till skillnad från vattenfallsmodellen där projektledaren arbetar med en stängd projektgrupp är Scrum uppbyggd som en platt hierarki. Här kan medlemmar flyttas runt enkelt mellan olika team beroende på behov. 
 

Kommunikation

I Scrum finns fasta och korta dagliga morgon-möten som styr upp ordningen och briefar upp alla Scrum-masters. Klokt rutin med korta möten, dessa ska också ske på stående fot så att det inte blir utrymme för “death by powerpoint”.

Man utnyttjar förstås också backloggen till fullo. Här blir allt överskådligt så att alla hela tiden kan ha kolla på vad som är i görningen. 

Leveranser

I Scrum så skjuter man upp leveransdatum om man inte lyckats uppnå målet på utsatt tid. Detta till skillnad från vattenfallsmodellen där man istället tar bort mindre viktiga delar för att inte bryta en deadline.

För att lyckas uppnå mål så arbetar man i Scrum starkt med uppföljningen. Owner har ju överblick av varje Sprint och ser man att något inte hinns med så får man skjuta till folk till gruppen.

Så snart man levererat så för man upp storien som klar på backloggen under “potentiellt leveransklara produkter” vilket gör att man till slut har en stor vägg av avklarade mål som verkligen gör att man kan känna att man når framåt.

Kvalitet

Det absolut viktigaste i Scrum är kvaliteten. Att produkten helt enkelt ska uppnå minst så höga krav som ställts på den. Till skillnad från vattenfallsmodellen uppnås detta genom att Scrum arbetar iterativt, alltså att man hela tiden kan arbeta om delar i projekten. I detta ingår att man följer upp feedback så att man kan genomföra förändringar. Iterativa designprocesser är otroligt kraftfulla och jag kan personligen säga att det är en arbetsmetod jag har svårt kunna gå ifrån. Saker stöts och blöts till det uppnått just den kvalitet de är målsatta att ha. Man skalar inte bort utan arbetar istället för att styra om resurser och i värsta fall förlänga deadlines.

Slutsats

I Scrum finns följande prioriteringsordning:

1. Kvalitén
2. Leveranstid
3. Omfattning

Scrum och agile är metoder jag nu jobbat lite med på olika sätt och det känns väldigt mycket mer flexibelt än klassiska projektledningssätt. Att man inte tummar kvaliteten känns också helt rätt. Med öppenhet som morot för motivationen så känns det hela också riktigt rätt i tiden.

Är scrum tillämpat i stor skala eller passar det bara mindre grupper? Det finns kritik mot att Scrum inte fungerar utanför mjukvarubranschen och speciellt inte på större företag. 

Svaret är kanske som Ken Schwaber säger “Det är inte Scrum det är fel på, det är arbetsprocesserna” (Kritiken mot Scrum växer).

Men det krävs också sitt för att kunna arbeta med Scrum. Som Henrik Kniberg, processmentor på konsultföretaget Crisp. “Scrum är som schack. Enkla regler, svårt att spela” (Scrum är som schack).

Andra bloggar om projekt, projektledning, project management, projektledare, scrum, agile, vattenfallsmetoden, projektmodeller, waterfall model