Scrumtips - Tips om Scrum!

När jag började hålla kurser för använde jag alltid projektor och en enorm hög med presentationsbilder. Idag har jag gått ifrån dessa helt. Jag tycker att de minskar mängden dialog och ökar mängden sömn i rummet. Istället använder jag vanliga blädderblock och illustrerar efter behov. Här är några konkreta tips kring effektiv användning av blädderblock. Användbara på kurser, workshops och arbetsmöten. Ha alltid en tom punkt redo. När du skriver upp listor med saker som andra deltagare redovisar, se alltid till att avsluta med en extra tom punkt längst ned i listan. Det blir en tydlig signal att fler synpunkter är välkomna. Växla mellan två färger varannan rad. Om du använder till exempel svart för jämna rader i en lista, och rött för ojämna, så blir det lättare för de som läser att skilja raderna från varandra.  Anlita en tejpnisse. Om någon hjälper dig att tejpa upp fyllda ark på väggen finns du fortfarande tillgänglig för att fortsätta skriva upp bidrag från deltagarna. Köp supertjock

Hur mäter man egentligen hur effektiv en verksamhet är? Det är ingen lätt fråga, och många aldrig så välmenta försök har gått snett. De flesta som utvecklar mjukvara håller idag med om att det inte är så lyckat att använda antal rader kod som ett mått på hur mycket man åstadkommit. Ett team som anses effektivare om de skriver många rader programkod löper stor risk att börja driva mot uppsvälld klipp-och-klistra kod, särskilt om någon skulle få för sig att koppla ett ekonomiskt incitament till modellen. Vår bransch är inte ensam om att ha problem med att styra med mätmål. Svenska polisen har blivit omskriven för hur fokuset på antalet gjorda utblåsningstest leder till att man maximerar antalet test, men minimerar antalet stoppade rattfyllerister . Risken när man väljer att mäta, följa upp och belöna en specifik sak är alltså att man får precis det man ber om: ett totalt fokus på den och bara den saken.  Dagens scrumtips är därför: var försiktig med vad du mäter, du kan få det .

Dagens scrumtips är ett boktips:  Dialogen och konsten att tänka tillsammans, av William Isaacs, översatt till svenska år 2000 av Bookhouse Publishing AB. Scrum handlar om lärande, alltså om att bygga ny kunskap och ny kapacitet. Vi har tvärfunktionella team för att belysa de komplexa problem vi arbetar med ur så många perspektiv som möjligt. Varje person som bidrar med ett nytt perspektiv tillför fler kontrollerbara variabler, alltså saker vi kan justera för att hitta en lösning på problemet. Styrkan med ett tvärfunktionellt team är dess förmåga att hitta lösningar som ett team av specialister från samma disciplin helt enkelt inte kan nå, eftersom de inte kan manipulera alla de variabler som behöver manipuleras för att lösning ska kunna uppstå. Ett team som inser detta samtalar med varandra för att förstå varandras perspektiv. Man accepterar att alla bidrar med sin del av lösningen och att det enda sättet att lösa hela problemet är att lära sig se det i sin helhet. Denna typ av utfors

Några saker sticker ut från när jag lärde mig Scrum från Ken Schwaber i slutet av 2003. En av dem är insikten om hur avgörande rätt arbetsmängd är. Ken beskrev Scrum som fokuserat på "workload management", till skillnad från ett mer tradtionellt fokus på "work management". Scrum Masterns jobb är att hjälpa teamet att ta sig an rätt mängd arbete i sprinten, inte att styra det arbete teamet tar på sig. Några av fördelarna med att ett team tar på sig rätt mängd arbete: De kan göra ett starkt åtagande. Ett starkt åtagande betyder att teamet tror på och äger sin egen plan. Man har tagit på sig en utmanande mängd arbete, men inte för mycket. Man kan med gott självförtroende säga att man kommer att leverera det man tagit på sig. Man kan leverera med kvalitet. Ett team som har för mycket att göra måste hitta någon sorts ventil att ventilera genom. Den allra vanligaste ventilen är produktens kvalitet. Man sänker helt enkelt kvalitetsambitionerna. Det funkar på kort sik

En missuppfattning som lever kvar kring lättrörliga metoder är att de inte har tillräckligt med planering. Det är precis tvärtom, vi gör massor av planering. Dels gör vi så mycket planering som behövs när vi ska starta ett nytt projekt, dels gör vi granskning och revidering av planerna med en regelbunden rytm. Eftersom vi planerar så mycket behöver vi vara mycket effektiva planerare. Varje sprint i Scrum börjar med en planeringsworkshop där produktägaren och teamet tillsammans väljer ut rätt mängd viktigt arbete för sprinten. Planeringsarbete kan lätt dra ut på tiden, särskilt när vi eftersträvar precision. Just därför är sprintplaneringen i Scrum begränsad till max en arbetsdag: sprintens första dag. Vissa team märker efter några sprintar att man inte ens behöver hela dagen för att göra en bra plan. En effektiv sprintplanering kräver att samtliga inblandade kommer väl förberedda. Då kan planeringen genomföras inom tidsramen, och sluta med ett genuint åtagande från samtliga inblandade

Ibland möter jag team och organisationer som har, eller tror sig kommer att få, stora svårigheter med att engagera de personer som de helst skulle vilja ha som produktägare. Deras försök till lösning kan ibland vara att ducka för problemet, och tillsätta en mindre lämplig person som produktägare. Det kanske vanligaste exemplet är nog det här. En utvecklingsavdelning på ett företag är övertygad om att man aldrig kommer att lyckas övertyga sina produktchefer att ta på sig rollen som produktägare, så man utnämner istället representanter från tekniksidan som mellanproduktägare, eller som man ibland hör, produktägar-proxies. Tanken med en produktägarproxy är att kunna fortsätta kalla den formellt ansvarige för utvecklingsarbetet för produktägare, men samtidigt acceptera att denne inte kommer kunna leva upp till sin roll. Till en början kan detta verka som en lämplig strategi. Utvecklingsteamet får ju i proxyproduktägaren någon man kan gå till för såväl dagliga frågor som för planering

Efter att ha läst om arbetsgrupper där medlemmarna jobbar lite för separerat från varandra för dra nytta av ett teams sanna potential  frågar en anonym läsare: "Det vore intressant att läsa lite tips på hur man når dit. Om man nu är en grupp där man är lite för specialiserade. Vad gör man för att sprida kunskaperna på ett bra sätt?" Här är några handfasta tekniker som gör att kunskap i ett mjukvaruutvecklingsteam sprids. Men först lite kort om själva förändringen i sig. Grunden i all förändring är att behovet av förändring är känt. Så, om inte alla i teamet känner till att och varför det är en bra idé att jobba tajtare tillsammans måste ni prata om det. Hur skulle ni veta om ni jobbade bättre tillsammans? Vilka faktiska aktiviteter skulle ni göra? Hur skulle det kännas? På vilket sätt skulle resultatet bli bättre? Vilka nackdeler skulle ni se? Hur skulle ni hantera dem? Så, några konkreta saker ni kan göra. Planera aldrig ensam.  Klyschan är sann: planen är inget, plan

Som en kommentar till det jag skrev om motstånd mot dagliga morgonmöten i "Pragmatisk eller dogmatisk? Progmatisk!", skriver Magnus Ljadas: "En anledning till motstånd till morgonmöten, enligt min erfarenhet, kan vara att arbetet i projektet bedrivs väldigt specialiserat. Jag gör bara sånt som har med utskrifter att göra; du sysslar bara med webbformulär; och ingen av oss rör någonsin nånting som har med databasen att göra, för det är Staffans baby. Vi har liksom väldigt få naturliga beröringspunkter. Stor fråga kanske, men hur tar man sig ur/bryter en sån situation?" Verkligen en stor fråga, men vi prövar ett sätt att närma sig den. En bra teknik är att utgå från att människor vars beteende man inte håller med om eller förstår sig på faktiskt beter sig så rationellt som möjligt, men självklart med utgångspunkt från deras egna aktuella modeller av hur verkligheten fungerar. Tänker man så kan man i det här fallet fråga sig vilken modell av verkligheten man behöver h

Scrum är ett enkelt ramverk. Några få regler bildar tillsammans ett system av aktiviteter som kan användas för att styra komplext arbete. Att ta bort en väsentlig del ur ett fungerande system påverkar alltid systemet som helhet. Tar man till exempel bort återblickarna ur Scrum minskar sannolikheten för framgång omedelbart. Man får lika stora problem, om inte större, om man försöker applicera Scrum dogmatiskt. Den som aldrig kan tänka sig att kompromissa kommer inte att ha någon framgång när det gäller att driva förändring. Har du själv jobbat med någon som aldrig kan kompromissa förstår du varför. Så hur ska man göra? Följa Scrum dogmatiskt för att inte förstöra arbetsmetodens effektivitet, eller vara pragmatisk för att inte alienera sig från andra människor? Jag föreslår en kompromiss. Låt oss kalla den en progmatisk hållning . Den progmatiska hållningen fungerar så här. Vi är å ena sidan aldrig rädda för att tänka själva och göra förändringar i Scrum, men å andra sidan gör vi

En vanlig fråga som jag brukar få har att göra med vad som händer när en person bemannar två roller i Scrum. Frågan lyder: kan man vara både Scrum Master och medlem i utvecklingsteamet? Först lite bakgrund till svaret. Mitt standardsvar på alla frågor som börjar med orden "kan man" eller "får man" är ett rungande ja. Självklart kan man göra som man vill, och självklart får man själv (eller snarare tillsammans med sina kollegor) bestämma hur man ska göra. Man behöver inte tillstånd från en expert eller en arbetsmetod. Det kan tyckas som en detalj, men språket styr tanken. Därför tycker jag det är mer hjälpsamt att börja frågan på ett annat sätt. Så här: Vad kan konsekvenserna av att vara både Scrum Master och teammedlem bli? För mig är det lättast att hitta till ett begripligt svar om jag börjar med att fråga mig själv vad syftet är med att dela på Scrum Master och teammedlemsrollen. En anledning till uppdelningen är att redan i förväg bygga en beredskap för fra

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