Scrum är en större och mer omfattande metod än Kanban. Scrumish är ett känt begrepp för Scrum-inspirerade metoder – dvs när man inte följer alla Scrums regler.

Här tänker jag bara presentera kärnan av Scrum och hur man kan enkelt uppgradera sin Kanbanprocess till något som kan vara början till ett mer omfattande Agilt arbete i din verksamhet.

Teamet

Enligt min erfarenhet så fungerar Kanban bra på individnivå, i mindre eller större grupper där individerna kan jobba oberoende av varandra. Scrum däremot är rekommenderat för grupper som arbetar nära ihop, eller tvärfunktionella grupper (team) av cirka sju personer. I praktiken så stämmer det väldigt bra.

Jag har lyckats med scrum i team med bara fyra personer men risken är stor att de administrativa kostnaderna blir för höga. Det kan vara mer produktivt att använda Kanban istället under de omständigheterna. För många personer i teamet är inte heller bra eftersom det blir svårt för alla att hålla koll på allt. Hellre flera mindre team med sju personer som jobbar parallellt, än en stor.

Sprinten

Det tydligaste skillnaden mellan Scrum och Kanban är att Scrum bryter ner det vardagliga projektarbetet i korta etapper (sprinter) av fast längd. En sprint är normalt mellan två och fyra veckor lång, men man kan även köra kortare eller längre vid behov – så länge man vet varför man gör det. Med tanke på de timmar man behöver lägga ner för att förbereda och sedan städa upp efteråt, så är det oftast mest effektivt att hålla sig till sprinter som är minst en vecka långa.

Målet

Varje sprint börjar med ett planeringsmöte som enligt min erfarenhet oftast tar cirka fyra timmar. Alla inblandade i projektet ska vara med på mötet som alltid inleds med att bestämma ett mål för sprinten.

Målet ska helst vara något som ger ett tydligt värde till produkten, projektet eller företaget. Det ska vara så kort att man kan skriva upp det på en tavla så att alla kan ta del av det under sprintens gång. Målet används för att kunna bedöma om sprinten har lyckats eller inte – men det hjälper också till att fokusera teamet i det dagliga arbetet under sprinten. Det är därför bra att göra målet synligt på kontoret.

När alla är överens om målet så kan teamet börja definiera vilka uppgifter (stories) de ska jobba med för att nå sprintmålet. Man kartlägger vilka resurser man har tillgängliga under sprinten, samt gör en enkel uppskattning av ungefär hur lång tid det kommer att ta för att genomföra varje story.  Det är viktigt i det här mötet att alla har förstått vad det är som ska göras och att det inte saknas en viktig resurs. Det kan vara bra att fokusera på vad som ska göras i varje story istället för hur - så att man inte gräver ner sig för djupt i uppgiften under mötet.

Mötet är klart när teamet är överens om vad som ska göras och känner att de har resurserna (och tiden) för att nå målet under sprinten. Ett sätt att se på det är att teamet binder sig till ett slags avtal eller överenskommelse: “Vi lovar att leverera just de här sakerna till det här datumet.”

Vid mötets slut bokar teamet in en demosession samt avslutningsmöte som ska ske i direkt anslutning till sista dagen för sprinten.

Scrummötet

Efter planeringsmötet är teamet redo för att börja jobba på riktigt. Nu gäller det att leverera och teamet måste få jobba i fred utan störningsmoment.

Börja varje dag under sprinten med ett scrummöte där teamet samlas stående för ett kort möte (inte längre än 15 minuter).

Under mötet ska alla rapportera bara tre saker: vad de jobbade med igår, vad de tänker jobba med idag, och om det finns ett hinder som gör det svårt att genomföra uppgifterna. Det är viktigt att dessa scrummöten inte drar ut och blir en längre diskussion – ta det i så fall i ett separat möte istället. Det dagliga scrummötet används enbart för att stämma av pulsen i projektet och se till att teamet är överens om att de kommer klara sprintmålet i tid.

Scrumreglerna säger att teamet ska få jobba oavbrutet på sprintet och inget annat - ingen får ändra på de stories och mål som definierades under planeringen. Vill man som chef ändra på något, då har man brutit avtalet med teamet och teamet kan inte längre lova att leverera. Är det så pass viktigt att ändra på något (vilket händer) ska man istället avbryta sprinten och planera en ny.

Demon

När sprinten är över är det dags för demo och retrospektiv. Demomötet är en kort möte där teamet får möjlighet att visa upp det de har gjort under sprinten. Vem som helst som har intresse i projektet kan delta och syftet med mötet är att bedöma om teamet har lyckats med sprintmålet eller inte.

Mötet har också en dold agenda – om teamet har lyckats så kan de känna sig stolta men har de misslyckats så blir det tydligt för alla inblandade i det här mötet.

Retrospektiv

Efter demon är det dags att sammanfatta sprinten. Det kallas för retrospective på engelska och det ger teamet tid att reflektera över själva sprinten. Vad fungerade bra? Vad fungerade dåligt? Vad skulle ni kunna göra bättre i nästa sprint? Ett förslag är att välja tre saker som teamet ska försöka göra bättre eller annorlunda nästa gång.

Det är lätt att hoppa över en retrospektiv som oviktig. Men jag hävdar att det är just detta möte som är själen i scrum. Man får bryta alla andra scrumregler, men inte den här. Utan en retrospektiv där alla får höras så kan man aldrig förbättra och anpassa metoden till just det team och företag man jobbar i.

Slutsats

Jag tror att det finns två anledningar till att scrum fungerar så bra och har blivit så populärt. Genom att bryta ner större projekt i ett antal mindre sprinter så kan företaget anpassa sig snabbt efter föränderliga mål.

Men min erfarenhet är att det viktigaste är att teamet själv tar ansvar för arbetet. Om man låter teamet ta ansvar och lämnar dem i fred under sprinten så presterar teamet helt enkelt bättre.