Köp Boken Scrumtips!

Om du vill ha alla scrumtipsen samlade i ett bekvämt format som fungerar i både läsplattan och på mobilen, så köp ett exemplar av min bok Scrumtips. Du sätter själv priset!

27 juli, 2008

Återblickslöshet får Scrum att stanna

Jag höll en tvådagars Certifierad Scrum Master-kurs åt ett större svenskt tjänsteföretag. Flera i gruppen var särskilt intresserade av större projekt, eftersom man jobbade tillsammans i ett sådant, och inte verkade helt nöjda med hur det gick. Jag berättade så gott jag kunde om mina erfarenheter av att använda Scrum för samordning av arbete i flera team och med flera samtidiga produkter, men jag märkte att mina svar inte var särskilt tillfredsställande.

För att få mer information om vad som egentligen eftersöktes vände jag på steken, och kastade ut en motfråga: vad pratade ni om på återblicken i er senaste sprint?

Svaret blev undvikande. Man hade inte haft någon återblick i den senaste sprinten. Jag modifierade frågan en smula: vad brukar ni prata om på era återblickar?

Nu blev svaret nästan lite skamset. Man hade aldrig haft en återblick i projektet. Definitivt inget de borde skämmas för, men lika säkert något de skulle kunna dra mycket nytta av att ändra på.

Scrum är inte bara ett arbetssätt, det är också ett ställningstagande. Med Scrum tar vi ställning för åsikten att den kompetens som behövs för att lösa våra organisationers problem finns ute i organisationen, hos alla oss som tillsammans gör jobbet, och vår gemensamma uppgift är att dra så mycket nytta av vår kollektiva kunskap som vi bara kan. Scrum är utformat för ge återkommande möjligheter att stanna upp, försöka förstå problem och formulera lösningar till dem.

Scrum Master, produktägare, team och andra kan förstås eliminera problem när som helst, men det extra stöd Scrum ger oss är återblicken. Återblicken är ett fokuserat moment i arbetet som återkommer sist i varje sprint. Under återblicken tittar vi tillbaks på arbetet, försöker förstå vad som hänt, och beslutar om justeringar framåt, så att vi ska bli mer effektiva och mer nöjda nästa sprint. Genom att göra återblicken till en inbyggd del i arbetsrutinen vill minska risken att vi hoppar över den. Det ska vara naturligt att stanna upp en stund i slutet av varje sprint och granska såväl produkt som utvecklingsprocess, och planera förbättringar av båda.

Återblicken är för Scrum vad bensin är för en bil: nödvändig för framfarten.

Att ta bort återblickarna ur Scrum och sedan undra varför man inte lyckas lösa sina problem visar på ett tydligt problem som måste lösas före alla andra: först måste förståelsen för Scrum som lärandemetod finnas. Innan den finns kommer vi att fortsätta leta efter färdigpaketerade lösningar till våra unika problem istället för att utnyttja idéerna som redan finns i vår egen organisation.

26 juli, 2008

Alla måste inte kunna allt

"Tvärfunktionella team låter så bra, men i vårt företag är det inte så enkelt. I Scrums utvecklingsteam förväntas ju alla kunna göra allt, men våra utvecklare är inte vana testare, och våra testare kan inte programmera. Hur ska vi kunna använda Scrum?"

Idéen om tvärfunktionella team kan vara provocerande. Personer från helt olika discipliner ska plötsligt arbeta tillsammans på daglig basis för att bygga en produkt av hög kvalitet. Få av oss har förstås varit helt skyddade från kontakter med personer från andra specialiteter, men oftast kanske kontakten har skett vid mer eller mindre formella "överlämningstillfällen". Fasbaserade utvecklingsmodeller går ju ut på att varje funktion i företaget gör sin del så noggrant som möjligt, för att vid en given tidpunkt kunna lämna över sitt arbetsresultat till nästa funktion i företaget, ungefär som de tävlande i ett stafettlopp springer var sin sträcka så fort som möjligt, och gör en tydlig överlämning till näste löpare.

I Scrum springer vi inte stafett, vi spelar rugby. Vi arbetar med små team som bygger kompletta inkrement av högkvalitativ produkt, i (typiskt) månadslånga iterationer. För att varje iterations arbete ska kunna resultera i produkt av tillräckligt hög kvalitet vill vi ha ett team som innehåller all den kompetens som behövs för att bygga klar produkt. I mjukvaruutveckling betyder det att vi vill ha testare, programmare, domänexperter, och ofta andra typer av specialister, med i teamet. Detta kallar vi ett tvärfunktionellt team, eftersom personerna ofta kommer från olika funktioner, eller avdelningar, inom ett företag.

Vi brukar säga att medlemmarna i ett scrumteam inte har några roller. Det har de förstås, om inte kring specialiteter så kring vem som leder gruppen vid vilket tillfälle, vem som är gruppens talman och vem som är den tystlåtne strategen, och så vidare. Men, det vi som lär ut Scrum menar med att scrumteam inte har några roller är att vi lägger större tonvikt på att teamet fungerar som helhet än på att upprätthålla gränserna mellan traditionella specialistroller. I varje väl fungerande team hjälper nämligen medlemmarna varandra att uppnå teamets mål, även om det betyder att man får sträcka sig utanför sitt specialistområde eller sin personliga komfortzon för en stund. En för alla, alla för en.

När man går in i ett scrumteam tar man alltså av sig experthatten, och sätter på sig teamhatten. Det betyder emellertid inte att alla i teamet ska kunna göra allting lika bra. Produktutveckling är komplicerat arbete, och vi behöver specialister för att lyckas - men vi behöver specialister som kan samarbeta.

Visst vore det underbart om "alla kunde göra allt", men tills den drömmen blir sann är det samarbetsförmåga som är den viktigare nyckelkompetensen för medlemmar i ett Scrumteam.

21 juli, 2008

God utvecklarpraxis är en del av Scrum

En vanlig missuppfattning, och ibland en källa till dispyt mellan Scrum- och XP-anhängare, är att Scrum inte lägger någon vikt vid god utvecklarpraxis. I XP är det ju så tydligt: parprogrammering, kontinuerliga byggen, enhetstestning eller till och med att man driver programmerandet med testfall. Scrum tycks lite fattigt i jämförelse, här finns ju inga tvingande regler om hur man ska göra på detaljnivå.

Att Scrum inte beskriver hur utvecklingsteamet ska göra sitt jobb är inget misstag. Scrum utelämnar detaljerna, eftersom de beror på sammanhanget. Parprogrammering är till exempel en lysande idé, om inte användningen i ett givet fall resulterar i så mycket konflikter att det hela kostar mer än det smakar.

Scrum är ett ramverk, en tom struktur vars detaljer behöver fyllas i av användaren. Tack vare detta kan vi lätt förklara essensen i Scrum för nya användare, och dessa kan själva fylla i med det som behövs i deras specifika situationer. En sidoeffekt av detta är att den som inte vet vad som behöver fyllas i står sig rätt slätt.

Avvägningen står alltså, i ytterligheterna, mellan att göra en mer utförlig projektmetod som beskriver exakt vad som ska göras i varje givet fall, och att göra ett enklare ramverk som bara beskriver den övergripande strukturen och överlåter till användaren att fylla i detaljerna.

Scrum går alltså på den senare linjen. Rationals Unified Process är ett exempel på den förra, och här ser vi också riskerna med den mer utförliga approachen. Trots, eller snarare på grund av, att RUP innehåller sida upp och sida ned med bra information om mjukvaruutveckling så blir metoden oöverblickbar. Många som använder RUP har helt missat att det är en iterativ och inkrementell arbetsmetod, kanske för att man redan spenderat all sin uppmärksamhet på alla detaljer.

Även om Scrum inte beskriver detaljerna krävs det alltså att vi själva kan fylla i dem. De flesta som är insatta i lättrörlig utveckling kan nog skriva under på att seriös enhetstestning, kontinuerliga designförbättringar och frekvent integration är tekniker som man inte vill vara utan om man vill lyckas med att utveckla iterativt, inkrementellt och lättrörligt.

Redan när jag lärde mig om Scrum från Ken Schwaber 2003 tryckte han på vikten av god utvecklarpraxis. Vi frågade till exempel vad man gör om man märker att organisationen saknar tillräckliga rutiner för konfigurationshantering. Kens svar: sätt in det som hög prioritet på produktbackloggen.

Filosofen Voltaire får avsluta, för han har redan beskrivit vad det handlar om så bra som man kan hoppas göra:

"What harm can a book do that costs a hundred crowns?
Twenty volumes folio will never cause a revolution;
it is the little portable volumes of thirty sous that are to be feared."

20 juli, 2008

Myers-Briggs Type Indicator

MBTI, eller Myers-Briggs Type Indicator är ett system för att identifiera sina personliga preferenser, till exempel för att se om man lättare får ny energi från att interagera med andra, eller om man bättre tankar batterierna genom tyst reflektion på egen hand. 

Varför skulle en Scrumanvändare vilja göra en sådan kartläggning? Dels för att man lär sig om sig själv, och självkännedom är aldrig dumt. Dels för att det gör interaktionen med personer som har andra preferenser mer begriplig, och därmed mer hanterlig. Båda dessa perspektiv är nyttiga för den som gillar Scrum. 

Praktisk nytta är ledordet här. Min första reaktion när jag hörde om MBTI var minst sagt skeptisk. Jag är ingen stor favorit av att sortera in människor i kategorier. Det var först när jag fick lära mig mer om MBTI på AYE-konferensen som nyttan började sjunka in. Steve och Don som förklarade grunderna var noga med att förklara att ens MBTI-typ inte är någon livstidsdom eller ödesbeskrivning, utan en bild av vilka preferenser man har. Att man har vissa preferenser betyder som bekant inte att man inte kan bete sig på ett helt annat sätt i praktiken. Det preferenserna lär oss är däremot vilken typ av beteenden som ligger närmast till hands för oss. Att agera utanför våra preferenser kräver mer ansträngning från oss.

Som vid all förändring är första steget för att dra nytta av MBTI att börja med sig själv. Man kan göra mer djupgående eller enklare typer av MBTI-analyser. Jag har vid två tillfällen gjort varianter av en enklare analys, som båda landade i samma resultat. (ENTP, om någon är intresserad, men ett svagt E, mitt på gränsen mellan extrovert och introvert).

Även om skeptikern i mig känner en viss lukt av horoskop kring MBTI och de många varianter av personlighetsanalyser som finns på marknaden, så tycker jag att verktygen är användbara, eftersom analysen ofta verkar resultera i att de som gör den börjar reflektera över vilka deras preferenser egentligen är, vilket i sin tur leder till en förståelse för människors olikheter. Den typen av förståelse är precis vad ett team behöver för att bli riktigt effektiva.

Jag tror att de mest effektiva teamen är komponerade av människor med varierande preferenser, som är helt medvetna om sina skillander - så att man aktivt kan dra nytta av dem. Man kompletterar varandra på ett sätt som gör att teamet som helhet blir mer heltäckande.

Videotips: Ken Schwaber på Google i september 2006

Ken Schwaber är den enskilda person som gjort mest för att sprida Scrum globalt. Han är en skicklig berättare och pedagog, och definitivt värd att lyssna på, som i den här videon där han talar i Googles TechTalk-serie i september 2006.

19 juli, 2008

Tyst brainstorming

Brainstorming är ett fascinerande koncept. Tanken är att en grupp tillsammans arbetar för att producera så många idéer som möjligt på ett tema. För att inte störa den kreativa processen finns en viktig förhållningsregel. Ingen kritik av idéer. Kritiken kommer senare. Min erfarenhet är att det är svårt att låta bli att kritisera under brainstormingen.

Möjligtvis, och jag skriver möjligtvis, kan det för personer med en extrovert läggning vara lättare att hantera kritik under brainstormingen. Är man bekväm med att tänka och prata samtidigt så är man förmodligen mer immun mot att folk avbryter och kritiserar under brainstormingen.

För personer med en mer introvert preferens kan utmaningen vara större. För det första kan brainstormingen i sig själv vara knepig för den som helst tänker för sig själv först, och sedan delar med sig av sina tankar. För det andra blir det inte bättre när någon avbryter den introverte, som äntligen uppmanat kraften att bidra med några idéer inför hela gruppen.


För att få en bättre balans mellan att tillfredsställa behoven hos personer med extrovert och introvert preferens brukar jag använda mig av tyst brainstorming.

I en tyst brainstorming får deltagarna under en känd tid tyst och på egen hand brainstorma idéer. Varje deltagare skriver själv ned sina idéer i en lista, eller direkt på post-its. När tiden är slut presenterar deltagarna sina idéer för varandra - använder man post-its klistrar man upp dem på till exempel en gemensam blädderblockslapp eller whiteboard. Behövs det kan man köra fler rundor på samma sätt.

Tyst brainstorming hjälper personer med introvert preferens att fokusera och förbereda sig under det tysta momentet, medan personer med extrovert preferens fortfarande har tillgång till den gemensamma presentationen och dialogen.

Effektiv användning av papper och penna

Jag har svurit ett heligt löfte att aldrig igen delta i ett arbetsmöte där någon stackare sitter och försöker skriva in det som sägs i ett Excelblad som projiceras på väggen. Det går vansinnigt långsamt, och hela gruppdynamiken förändras från dialog till något helt annat - något styltigt, okreativt och tråkigt. Så, tills dess att någon byggt en elektronisk whiteboard som är lika effektiv för samarbete som gamla goda analoga verktyg, så kommer Scrum för mig att vara synonymt med  whiteboards, blädderblock och post-its.

Det finns en hel del praktiska saker, billiga och kraftfulla, som gör arbetet med papper och penna mer effektivt. Är du Scrum Master kan du ta täten för att hjälpa övriga att lära sig detta.
  1. Skaffa rätt sorts pennor. De flesta konferensrum är laddade med whiteboardpennor samt bläck- eller blyertspennor. Inga av dessa är effektiva för saker som ska upp på väggen så att alla kan se dem. Tunna pennor ger för tunn och svårläst text. Whiteboardpennor resulterar i uppsvällda hopflytande tecken. Lösningen: köp mellantjocka pennor. Så enkelt, och så effektivt. Med rätt pennor kan fler läsa vad som faktiskt står på lapparna vi sätter upp, och dessutom - och detta är en grymt viktig bonus - dessutom går det bättre att se vad det står när man fotar av sitt arbete vid dagens slut.
  2. Texta stort och tydligt. Kan tyckas självklart, men de flesta av oss är mer vana att skriva i miniatyrskrivstil för oss själva på ett papper än med stora tydliga tecken på post-its som ska kunna läsas av alla i ett rum. Förklarar skillnaden genom att visa den. Skriv två lappar och sätt upp på väggen: ett bra exempel med stora tydliga tecken, och ett dåligt exempel med liten oläsbar text.
  3. Skriv koncist, men med hela meningar. Vi överskattar ofta både vår egen förmåga att minnas våra idéer och andras förmåga att förstå dem. Att skriva "Testning" på en röd lapp och posta på väggen under en återblick kan kännas effektivt när man skriver den, men det är mycket mer effektivt att unna sig några extra ordklasser på lappen. "Testarbetet börjar ofta sent i sprinten, och hinns inte med till fullo", är begripligt för fler än lappskrivaren. Och återigen, när man fotar eller skriver av sina resultat får man något som faktiskt är begripligt även utanför workshopen.
  4. Använd riktiga PostIts(TM) med extra starkt klister. Ibland får jag frågan om jag har generalagenturen för PostIts i Sverige, eftersom vi förbrukar så många i mina workshops. Det har jag tyvärr inte, men jag kanske borde ha det, eller åtminstone provision. Skämt åsido så är det otroligt kontraproduktivt att spara pengar på att köpa ful-post-its med dåligt klister för att spara några kronor på inköpssidan. Varje gång en klisterlapp lossnar och måste sättas upp kostar sekunderna workshopen står still lika mycket som ett paket riktiga Super Sticky PostIts.
  5. Riv av post-its horisontellt. Det här är ett tips som jag fick lära mig av en kursdeltagare för länge sedan. När jag helt aningslös rev av en post-it och satte upp den på väggen hördes plötsligt ett rop i kurslokalen: - "Nej, nej, så där kan du inte göra". Han som ropat visade mig hur post-it-lappen, om man river av den från traven horisontellt, sitter mycket mer plant mot väggen när man klistrar upp den. Typiskt är annars att man rycker av lappen genom att ta tag i nederkanten, och dra av den i riktning upp mot klistringen, vilket gör att lappen böjer sig och pekar ut från väggen. Kan tyckas helt irrelevant, tills man inser att lappar som pekar mot taket är rätt svåra att läsa för de som deltar i workshoppen sittande.
  6. Våga makulera. Det här är förmodligen en rest från skoltiden. Många har oerhört svårt för att makulera skrivna lappar. Istället för att bara riva sönder en lapp som blev dålig försöker man sudda, skriva över och skriva runt. Resultatet: en post-it sparad, till priset av att det blir helt omöjligt för övriga att läsa vad som står på lappen. Så vad är viktigast: att spara en bit papper eller komma överens om vad den där kniviga användarberättelsen egentligen gick ut på? Jag brukar be alla deltagare att ta en tom post-it, skriva ned någon godtycklig, men inte för kort, text. Därefter får alla hålla fram sina lappar för varandra. Jag förklarar sedan att lapparna inte blev så bra, så därför ska vi riva sönder dem. Jag ber samtliga att strimla sina lappar. Det har hänt att folk vägrat. 
  7. Ha en upptejpningsassistent. Som Scrum Master är man ofta den som leder workshops av olika slag, till exempel planering- och återblicksmöten. För att få lite flyt i arbetet är det bra att dela med sig av sysslorna. Låt inte tempot i workshopen gå ned medan du ensam river och tejpar upp blädderblockslappar ni skrivit på. Be en deltagare att kliva in som upptejpningsassistent, och kanske någon annan som avrivningsexpert. 

Om bloggen

Den här bloggen är till för dig som redan kan en del om Scrum och vill använda arbetssättet för att nå din organisation eller ditt teams fulla potential.

Det finns en hel del skrivet om Scrum, men det allra mesta är på engelska. Den här bloggen är på svenska, och här kommer det att finnas praktiska tips för dig som Scrum-användare, tillsammans med förklaringar kring varför tipsen ser ut som de gör.

Just varför-biten är viktig. Styrkan med Scrum är att man snabbt kan komma igång, och sedan förbättra gradvis. Det är också svårigheten med Scrum. Scrum är ingen manual som förklarar bästa praxis. Tvärtom. Scrum utgår från att vad som är bäst beror på sammanhanget. Svaret "det beror på" är tyvärr inte till så stor hjälp för den som vill lösa ett specifikt problem. Om vi däremot tar en titt på vad det beror på, så har vi ofta ett användbart tips. Det är min ambition när det gäller tips kring lite mer luddiga frågor på den här bloggen.

Jag som skriver bloggen heter Tobias Fors. Jag har arbetat med att använda, införa och lära ut Scrum sedan jag lärde mig arbetssättet av Ken Schwaber 2003.