Scrumtips - Tips om Scrum!

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 bar

"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

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 ve

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 pre

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.

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 grupp

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. 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 ho

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