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!

30 september, 2009

Scrum-pub i Uppsala, 8:e oktober, 18.00

Jag (Tobias Fors) och Henrik Hindbeck har dragit igång ett evenemang i Uppsala som ska bli återkommande. Vi kallar det för Scrum-pub, och är en helt informell träff den andra torsdagen i varje jämn månad. Mer info finns på Scrum User Group-gruppen på Google.

Nästa träff är alltså: 8 oktober klockan 18.00.

29 september, 2009

Boktips: Wisdom of Teams

Teamarbete är kärnan i Scrum. Ett effektivt team kan slå världen med häpnad, och är ett team vars medlemmar trivs tillsammans, strävar mot eftersträvansvärda mål tillsammans, och faktiskt når dem.

Min favoritbok om team är Katzenbach och Smiths "The Wisdom of Teams". Den innehåller bland annat en ofta citerad modell för effektiva team, som passar utmärkt för tvärfunktionella utvecklingsteam.

Vad inspirerar ditt tänkande om teamarbete? Om inte en bok, så kanske någon eller något från sportens värld? Vad specifikt är det som inspirerar dig? Låter du inspirationen ge avtryck i ditt arbete med team?

28 september, 2009

Lider ni av otydligt klarkriterium?

Har du varit med om följande? Ni samlas för att planera upp en sprint, men kör snabbt fast i en diskussion om hur lång tid saker och ting kommer att ta. Till slut lyckas ni med möda få ihop en plan för sprinten, men när väl sprintgranskningen kommer visar det sig - alldeles för sent - att ni inte alls är överens om att ni är klara. Produktinkrementet har ojämn kvalitet. Några saker är väl testade, andra håller knappt ihop för demo.

Ni kan lida av otydligt klarkriterium. Många gör det.

Vad kan orsaka otydligt klarkriterium? Här är några möjliga orsaker:
  • Det känns så självklart vad "klart" betyder att det känns onödigt att prata om det
  • Ni förstår att ett försök att definiera vad klar betyder kommer att visa hur icke-överens ni är, vilket gör att ni skickligt undviker ämnet
  • Ni har inte sett behovet av att definiera "klar", eftersom ni ännu inte upplevt några problem av att inte ha en gemensam definition
Klarkriteriet hjälper teamet att samarbeta. Utan ett gemensamt klarkriterium kan man egentligen inte veta vilket slutmål man siktar på. Såväl estimering och planering som genomförande blir lidande. Där någon tänker "if it compiles, ship it", tänker en annan sig att automatiserade tester, uppdaterade byggscript och granskning av koden krävs för att en ny funktion ska anses klar. Det blir en källa till konflikter.

Ett kännetecken hos ett effektivt team är att man har en gemensam överenskommelse om hur man arbetar tillsammans. Klarkriteriet är en del av en sådan överenskommelse för effektiva scrumteam.

Är ert klarkriterium tillräckligt tydligt? Samla ditt team och be alla deltagare att, utan att prata med varandra, skriva ned sin definition av "klart" som en punktlista på ett indexkort. När alla är klara, visa korten för varandra och berätta vad ni skrivit? Är era kort ganska lika eller ganska olika? Vad kan ni lära er av de skillnader som finns?

12 augusti, 2009

Scrum-guide

Som en del av Scrum Alliance plan att införa ett flervalsprov som en del av Scrum Master-certifieringen, har Ken Schwaber skrivit ett "officiellt" dokument som beskriver Scrum. Det är en OK sammanfattning, och kan säkert funka bra för den som vill kolla sin egen kunskap om de olika begrepp som definieras i Scrum.

Du kan ladda ned Ken Schwaber's Scrum Guide från Scrum Alliance webbplats.

04 juli, 2009

Skapa ett teamrum

Jag var scrum master för ett litet team som bestod av ett par utvecklare och en testare. Utvecklarna satt sedan länge bredvid varandra i samma rum, men vår testare satt i ett annat rum med flera andra testare från andra projekt. Jag förklarade för vår testare att jag gärna skulle se att hon flyttade in i samma rum som oss andra. Jag förklarade också att jag absolut inte tänkte tvinga henne, men att jag verkligen trodde att det skulle gynna både henne och teamet. Efter en tids tvekan rullade hon över sin stol och dator till oss andra. När vi några månader senare under ett retrospektiv utvärderade hur olika viktiga faktorer utvecklats kom vi in på frågan om teamsamarbete. Utvecklarna indikerade att situationen förändrats svagt till det positiva sedan jag kom in i projektet. Vår testare gav däremot utvecklingen högsta betyg. Jag frågade vad det berodde på. Hon sa att det framför allt berodde på att hon nu satt tillsammans med utvecklarna. Äntligen, sa hon, kände hon sig riktigt delaktig i utvecklingsarbetet.

Den placering som först användes var att ha utvecklarna på ett ställe och testarna på ett annat. En sån placering återspeglar den organisation som fanns i företaget: funktionellt uppdelad med grupper för utvecklare respektive testare. Det föll sig helt naturligt att sitta var och en på sitt hörn, för att kunna samordna arbetet inom specialistgrupperna.

Scrum kan användas i funktionella organisationer, men bygger på tvärfunktionella team. Dessa team som sätts ihop av specialister från olika funktioner inom företaget, till exempel marknad, R&D och QA. Resultatet blir team som innehåller all kompetens som behövs för att bygga klar produkt varje sprint.

När man jobbar i ett tvärfunktionellt team är ens dagliga samarbetspartners inte bara experter från den egna disciplinen, utan alla de andra teammedlemmarna som kallats in från olika områden. Målet är en frekvent och effektiv kommunikation över expertgränserna, så att vi snabbt kan nå verkliga resultat.

Tvärfunktionella team kan drabbas av en hel del konflikter, vilket är helt naturligt. En orsak är att medlemmarna har helt olika bakgrund och helt olika syn på de problem man brottas med. Innan teamet lärt sig uppskatta och utnyttja dessa skillnader tar de sig uttryck som konflikter.

Om vi vill snabba upp teamets utveckling mot att bli högpresterande är teamrum ett attraktivt alternativ. Att sitta på samma plats är ingen garanti för att man pratar med varandra, men det ökar åtminstone sannolikheten, och att prata med varandra ofta är en förutsättning för att snabbt reda ut konflikter.

Många har dåliga erfarenheter av att sitta i öppna kontorslandskap. Att försöka samlokalisera team behöver inte handla om kontorslandskap. Ett eget teamrum ger teamet möjligheten att jobba tillsammans, samtidigt som man slipper det störande i att sitta i stora öppna landskap. Om kontorslandskap är det bästa som går att få kan man ändå förbättra situationen genom att avgränsa en teamyta med hjälp av skiljeväggar och växter.

Somliga har dåliga erfarenheter av att inte ha sitt eget kontorsrum. Min erfarenhet är att det är mest störande att sitta tillsammans med personer som tillhör andra team. Om man å andra sidan sitter tillsammans med personer i det egna teamet kan man vara säker på att de samtal som uppstår handlar om saker man är intresserad av.

Även om man har ett teamrum kan för mycket prat och avbrott bli kontraproduktivt. Vem som helst kan därför ta initiativ till att sammanställa teamets gemensamma regler för att man ska kunna arbeta effektivt. Syftet med att sitta i samma rum är ju att underlätta kommunikationen, men det måste också finnas en möjlighet att jobba fokuserat ensam.

Väggarna i ett teamrum ska vara användbara. Det betyder minst en eller två whiteboards i rummet, och möjlighet att klistra upp stora blädderblocksark på övriga väggar. Allra minst vill jag ha upp sprintbackloggen, alltså planen för den innevarande iterationen, på väggen. Där vill jag kunna se vilka uppgifter som valts ut från produktbackloggen, och hur de brytits ned i aktiviteter. Jag vill också kunna se vem som jobbar med vad, hur mycket tid som återstår, och en klarkurva (burndown chart).

På väggen vill jag också ha upp aktuella hinder, vilka som ingår i teamet och deras kontaktinformation, tidplaner från resten av organisationen och annat som är viktigt för teamets arbete. Ingen ska behöva leta efter väsentlig information.

På dörren till teamets rum vill jag kunna läsa vilket team som finns i rummet: vad teamet kallar sig och vad man jobbar med. Det kan verka uppenbart för de som deltar i teamet men, särskilt i större organisationer, är det otroligt givande för andra som råkar gå förbi att snabbt kunna se vilka som finns i rummet och vad de gör. Att posta en liten affisch på dörren är ett enkelt sätt för teamet att marknadsföra sig.

Somliga väljer att införa teamrum genom att göra ett kontorsrum tillgängligt för teamet, som teammedlemmarna kan använda om de vill. Alla behåller sina individuella platser, men om man vill sitta tillsammans kan man göra det i teamrummet.

När jag berättar om tanken om teamrum blir somliga provocerade. Så mycket lediga lokaler har man minsann inte på sitt kontor. Så kanske det är, men är inte kostnaden för mer ändamålsenliga lokaler försvarlig om det ökar chansen att projektet lyckas?

De flesta skulle säga att det är värt att satsa på bra lokaler, men sen är det kanske ändå en lokalchef som bestämmer hur det blir i slutänden. Att låta en så viktig framgångsfaktor som teammedlemmarnas lokaler avgöras av någon som inte har ansvar för projektets framgång är en suboptimering som finns i alltför många företag. Som scrum master är ditt jobb att verka för att även lokalerna blir en faktor som hanteras på ett medvetet sätt i era utvecklingsprojekt.

04 mars, 2009

Ny workshop: Effektiva återblickar (1 dag)

Jag arbetar på en ny workshop för att hjälpa den växande skaran scrumanvändare att växla upp sina återblickar till en ny nivå. Läs mer om endagsworkshopen Effektiva återblickar på Citerus webbplats.

25 februari, 2009

Nästa CSM-kurs: 6-7 maj

Min nästa öppna kurs Certifierad Scrum Master går av stapeln den 6-7 maj i centrala Stockholm. Det är en lysande möjlighet att fördjupa din förståelse av varför Scrum ser ut som det gör, och hur man gör i praktiken. Jag tror att betygssnittet på kursen under de tre år vi kört den ligger strax under 8 på en 9-gradig skala. Rätt ok!

Sprintbacklog på väggen, produktbacklog elektroniskt

En artikel på InfoQ om för- och nackdelar med att sätta upp sina planer och sin information på väggen fick mig precis att komma ihåg att jag har några tips att dela med mig av.

Sprintbackloggen är, som du redan vet, utvecklingsteamets eget verktyg för att hantera sitt åtagande i sprinten. Med hjälp av sprintbackloggen kan teamet granska och anpassa sitt arbeta på daglig basis. Detta är viktigt, eftersom utvecklingsteamet är själva motorn i Scrum. För att sprintbackloggen ska vara relevant och användbar måste den vara aktuell. Det kommer den att vara givet att två förutsättningar är uppfyllda.

Den första förutsättningen är att teamet verkligen tagit på sig ansvaret att planera och följa upp sitt eget arbete, eftersom man ser nyttan med att göra det och därför vill göra det.

Den andra förutsättningen är att det är extremt enkelt att hålla sprintbackloggen uppdaterad. Vanliga orsaker till att det inte är enkelt är att man lagrar sprintbackloggen i ett verktyg som alla inte behärskar till fullo och att dokumentet den ligger i inte är åtkomligt eller redigerbart.

Jag känner inte till något billigare, enklare och effektivare sätt att hantera sprintbackloggen än att sätta upp den på väggen. En whiteboard är bra, men inte alls nödvändigt. Jag har själv kört med en radda upptejpade stora blädderblocksark, och det fungerar nästan lika bra. Rekommenderas för övrigt även om man har en whiteboard - då kan man ju använda whiteboarden till att modellera och problemlösa.

När sprintbackloggen, komplett med utvalda saker från produktbackloggen, aktiviteter, status på aktiviteter och timmar kvar, sprintmål och klarkurva (burndown) sitter på väggen händer flera saker. Först och främst är planen nu synlig för alla som vill se den. Helst sitter den förstås i teamets eget arbetsrum.

Med planen ständigt synlig, och givet att teamet accepterat ansvaret för den, blir det enkelt och naturligt att hålla den uppdaterad. Allt som behövs är en snabb justering av återstående tid på en aktivitet, kanske en lappflytt och en uppdatering av klarkurvan. Några minuter per dag och person. Kostnadseffektivt med andra ord.

Att lagra sprintbackloggen elektroniskt ser jag inte som särskilt intressant. Det som är intressant är vilka saker från produktbackloggen som valts ut för sprinten, och vilka som blivit klara enligt vårt klarkriterium. Den exakta aktivitetsföljden inuti sprinten är teamets jobb. Om vi vill granska om teamet jobbar så effektivt som möjligt kan vi titta på hur mycket faktiska resultat som åstadkoms, kvalitetsnivån och på dokumentationen från sprintåterblickarna.

Produktbackloggen ser jag som mer naturlig att ha i elektroniskt format. Den är ett officiellt dokument som ska vara brett tillgängligt i organisationen, för att sprida förståelse för vad som händer med produkten. Man kan vilja versionshantera den, och definitivt skicka ut den, eller en länk till den, till personer som behöver titta på den.

Det finns en uppsjö av verktyg för hantering av både sprint- och produktbackloggen idag. Mitt tips är att skippa sprintbacklogghanteringen i dem om du inte måste köra även sprintbackloggen elektroniskt (t.ex. om ditt team inte går att samlokalisera, vilket ju är vanligt), och fokusera på hantering av produktbackloggen. Även där är det emellertid värt att komma ihåg en vanlig fallgrop: att man blir kidnappad av verktyget.

Jag har jobbat med flera organisationer som beskrivit sitt verktyg ungefär så här: "Det är bra och så, men det funkar ju inte riktigt som vi vill. T.ex. kan vi inte [fyll i med bra förbättring de skulle vilja göra], men eftersom det inte går gör vi som verktyget föreskriver". Inte så kostnadseffektivt, men lätt hänt. De mer avancerade verktygen stödjer förstås långtgående anpassningar, men kostnaden för den typen av produktanpassning är inte riktigt samma sak som att stuva om i ett Excelark - ett verktyg som ofta bespottas men som är märkligt kraftfullt och dynamiskt.

Mitt tips när det gäller verktyg är därför: börja så enkelt som möjligt (Excel, t.ex.) och jobba så tills antingen a) du inser att det faktiskt räcker, eller b) du har förstått typ av stöd ni behöver så att ni kan fatta kloka beslut om verktygsval och anpassning.

27 januari, 2009

Ifrågasätt Scrum

Ingen lösning är så bra att den inte orsakar problem för någon. Här kommer dagens hjärngymnastik.

  1. Välj ut en regel från Scrum som du gillar. Kanske väljer du vanan att ha dagliga morgonmöten, kanske något helt annat. Välj den regel du tycker känns mest självklar och mer eller mindre okränkbar.
  2. Skriv ned minst tre, och helst fler, exempel på problem den regel du valt kan orsaka för någon i din organisation.
  3. Om du inte kan hitta minst tre exempel har du inte tänkt tillräckligt länge än, så gå tillbaks till steg två. Annars, reflektera över om regeln fortfarande känns självklar.
  4. Posta gärna dina reflektioner som en kommentar här nedan!

Örebrovändningen

Hos ett företag som jag arbetade med under en längre tid träffade jag en mycket trevlig örebroare. Han berättade för mig att han i Närkes Allehanda sett en insändare som beklagade sig över gnälligheten i Örebro (härlig ironi, jag vet) och tyckte att man "borde sätta upp en staty av stor rostig spik" i centrum som symbol för denna jobbiga attityd. Några dagar senare kom en motinsändare som hävdade att Örebro inte alls var så gnälligt som påstods, utan att tvärtom Västerås skulle ses som centrum i det så kallade gnällbältet. Jag höll förstås inte med, eftersom jag är uppväxt i Västerås.

Det är sen länge känt att alla som är från Örebro har ett favoritmotto. Detta talesätt som man kan dra fram när en förändring kommer på tal består av tre enkla ord. Kanske hör du dem uttalas på örebromål när du läser dem:
"Det går aldrig".
Sådär till vardags i företag hör man kanske inte orden "det går aldrig" särskilt ofta - men de finns där och lurar. Även om vi inte säger det rakt ut är det svårt att låta bli att tänka dem då och då. Ibland säger vi orden, fast de kommer ut som helt andra ord. Som när vi säger "det tror jag blir svårt". Det låter kanske mildare, men konsekvensen blir ofta densamma - att tysta den som kommit med ett förslag.

Jag har en metod som jag använder ibland för att hjälpa mig själv och andra att arbeta runt "det går aldrig"-reaktionen. Den använder jag för att minska risken att vi räknar ut goda idéer för tidigt.

Nyckeln till att hantera "det går aldrig"-problemet är att komma ihåg att mottot oftast är osant. De flesta idéer vi får på jobbet går faktiskt att realisera, frågan är bara vad de kommer att kosta i tid, pengar och energi. Därför börjar vi med att konvertera mottot till en fråga. Frågan lyder:
Vad skulle det krävas för att det här skulle gå?
Det är svårt att envist fortsätta att hävda att något aldrig skulle gå att göra, samtidigt som någon ställer en uppriktig fråga om vad som skulle krävas för att få detta något att hända. Genom att göra om den instinktiva reaktionen till en datafråga kan vi därför förvandla situationen från en återvändsgränd till något som till och med kan göra oss lite nyfikna. Jobbet som nu ligger framför oss är att försöka skapa en så bra bild som möjligt av vad som skulle krävas för att uppnå det vi önskar oss.

Ibland visar det sig att det vi vill uppnå är så gott som omöjligt, eftersom insatsen skulle vara för hög. Då är det så, och nu vet vi varför. Ibland visar det sig å andra sidan att det hela inte alls var omöjligt, utan genomförbart med en rimlig insats. Då kan vi ta ställning till om vi vill investera i förbättringen baserat på en faktisk analys av problemet, snarare än baserat på ett känslomässigt avfärdande. Oavsett utkomsten har vi lärt oss mer än om vi stoppat processen baserat på vår instinktiva magkänsla.

19 januari, 2009

Populäraste scrumtipsen, januari 2009

Scrumtipsbloggen fyller ungefär ett halvt år, och följande topp 3-lista räknar upp till det populäraste inlägget hittills.

#3 - Återblickslöshet får Scrum att stanna. Om hur synd det är att så många faller ifrån när det gäller att lära sig genom aktiv reflektion i återblickar i grupp.

#2 - Scrumtips: Både Scrum Master och teammedlem? Om utmaningarna man ställs inför när man kombinerar rollen som stöttande ledare och utvecklare.

Samt (trumvirvel), det populäraste inlägget hittills på Scrumtips:

#1 - Pragmatisk eller dogmatisk? Progmatisk! Om hur man kan göra för att våga göra anpassningar i sitt arbetssätt på ett lite säkrare sätt än att "bara ändra".